Α λ έ ξ α ν δ ρ ο υ Π ί ν ο

Transcript

1 ΕΘΝΙΚΟ ΚΑΙ ΚΑΠΟΔΙΣΤΡΙΑΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ ΤΗΛΕΠΙΚΟΙΝΩΝΙΩΝ ΜΕΤΑΠΤΥΧΙΑΚΟ ΠΡΟΓΡΑΜΜΑ ΣΠΟΥΔΩΝ ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ Α λ έ ξ α ν δ ρ ο υ Π ί ν ο Α Μ : Μ «Πλαίσιο Ανάπτυξης Εφαρμογών με Βάση την Επαναχρησιμοποίηση Συστατικών Λογισμικού και τον Αντικειμενοστραφή Σχεδιασμό: Εφαρμογή στον τομέα των Αρθρωτών Βοηθημάτων Διαπροσωπικής Επικοινωνίας» Επιβλέπων: Γεώργιος Κουρουπέτρογλου ΑΘΗΝΑ Φεβρουάριος 2003

2 Περιεχόμενα Περιεχόμενα... 2 Περίληψη ΜΕΡΟΣ Α: Σχεδιασμός του Πλαισίου Εισαγωγή Το Πλαίσιο «ΟΔΥΣΣΕΑΣ» Το πρόβλημα Η προτεινόμενη λύση Πλαίσια ανάπτυξης εφαρμογών Γεννήτριες εφαρμογών Τυποποιήσεις, οδηγίες και τεχνικές προγραμματισμού Γενικά Χαρακτηριστικά του "ΟΔΥΣΣΕΑ" Μεθοδολογία Ανάπτυξης του ΟΔΥΣΣΕΑ Τυποποιήσεις Οδηγίες Λογισμικό υποβοήθησης υλοποίησης συστατικών Λογισμικό σύνδεσης συστατικών Ολοκλήρωση user interface Υποστήριξη Διαδικτύου Επικοινωνία μεταξύ Διεργασιών Clipboard COM Dynamic Data Exchange (DDE) File Mapping Mailslots Σωληνώσεις (Pipes) RPC Windows Sockets WM_COPYDATA COM (Component Object Model) Περιγραφή Αντικείμενα και Διεπαφές του COM Διεπαφές και υλοποιήσεις διεπαφών Επαναχρησιμοποίηση αντικειμένων Containment/Delegation Aggregation Η βιβλιοθήκη COM Σελίδα 2 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

3 4.5. Το μοντέλο Client/Server του COM DCOM και CORBA Εισαγωγή Κορυφαίο Επίπεδο: Βασική Αρχιτεκτονική Προγραμματισμού Μεσαίο Επίπεδο: Αρχιτεκτονική Απομακρυσμένων Διαδικασιών Χαμηλό Επίπεδο: Αρχιτεκτονική Πρωτοκόλλου Επικοινωνίας Συμπέρασμα COM+ (Component Services) Εισαγωγή Ανασκόπηση Γιατί COM+; Επικοινωνία με γεγονότα (events) Έκδοση (Publishing) και Συνδρομή (Subscribing) Υπηρεσίες γεγονότων του COM Συνδρομές Λεπτομερής Σχεδιασμός Ομάδες Χρηστών του ΟΔΥΣΣΕΑ Προγραμματιστές Πωλητές Κύκλος ζωής του Βοηθήματος Επικοινωνίας Συστατικά Βοηθήματος Επικοινωνίας Πρωτόκολλο επικοινωνίας των συστατικών Διεπαφή επικοινωνίας των συστατικών Πρόγραμμα εκκίνησης του Βοηθήματος Επικοινωνίας Διαδικασία εγκατάστασης Βοηθήματος Επικοινωνίας Δοκιμαστικά συστατικά ελέγχου και αναφοράς Ο ΟΔΥΣΣΕΑΣ στο Διαδίκτυο ΜΕΡΟΣ Β: Υλοποίηση του Πλαισίου Εισαγωγή Ο ΟΔΥΣΣΕΑΣ για τους Προγραμματιστές Γενικές Τυποποιήσεις Τυποποίηση για Εφαρμογές των Windows Τυποποίηση Μοντέλου Αντικειμένων και Συστατικών (COM) Επέκταση τυποποίησης Μοντέλου Αντικειμένων και Συστατικών (COM+) Ειδικές Οδηγίες του ΟΔΥΣΣΕΑ Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 3 από 163

4 Μορφή Συστατικών DLL Διεπαφή χρήσης η κλάση Activate Μοντέλο νημάτων Single Threaded Βιβλιοθήκη διεπαφής Interface.dll Διεπαφής Χρήσης θέση και μέγεθος παραθύρων Κώδικας Προγράμματος Εκκίνησης Βοηθημάτων Διαπροσωπικής Επικοινωνίας Ο ΟΔΥΣΣΕΑΣ για τους Πωλητές Προετοιμασία του συστήματος Εγκατάσταση του Εκτελέσιμου Προγράμματος Εκκίνησης του Βοηθήματος Διαπροσωπικής Επικοινωνίας Διαδικασία Εγκατάστασης των Συστατικών Βοηθήματος Διαπροσωπικής Επικοινωνίας Συγχρονισμός και Φιλτράρισμα Υλοποίηση Δοκιμαστικών Συστατικών Δοκιμαστικό Συστατικό Εισόδου Δοκιμαστικό Συστατικό Εξόδου Δοκιμαστικό Ενδιάμεσο Συστατικό Συμπεράσματα ΑΝΑΦΟΡΕΣ Σελίδα 4 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

5 Περίληψη Στην παρούσα διπλωματική εργασία παρουσιάζεται ένα νέο πλαίσιο ανάπτυξης εφαρμογών σχεδιασμένο για τον τομέα των βοηθημάτων επικοινωνίας που βασίζονται σε ηλεκτρονικό υπολογιστή. Οι χρήστες της τεχνολογίας που προτείνεται είναι οι κατασκευαστές και οι πωλητές των βοηθημάτων διαπροσωπικής επικοινωνίας, ενώ οι τελικοί ωφελούμενοι είναι τα Άτομα με Αναπηρίες (ΑμεΑ) και το περιβάλλον τους. Το βασισμένο σε συστατικά (component-based) πλαίσιο που προτείνεται θα ονομάζεται για συντομία «ΟΔΥΣΣΕΑΣ» και έχει ως στόχο να απλοποιήσει τη διαδικασία ολοκλήρωσης συστατικών που προέρχονται από διαφορετικούς κατασκευαστές σε εφαρμογές χαμηλού κόστους που εκμεταλλεύονται τα πλεονεκτήματα που προσφέρει η αρθρωτή σχεδίαση και η επαναχρησιμοποίηση κώδικα. Στόχος είναι επίσης η βελτίωση του κύκλου ζωής των συγκεκριμένων προϊόντων και του τρόπου διάδοσης της τεχνολογίας στον εν λόγω τομέα. Ακολουθώντας την προσέγγιση του ΟΔΥΣΣΕΑ μπορεί κάποιος να κατασκευάσει μεγάλες και αξιόπιστες εφαρμογές, οι οποίες να μπορούν να προσαρμοστούν σε διαφορετικές ανάγκες χρηστών. Για τους κατασκευαστές (developers) συστατικών βοηθημάτων Εναλλακτικής και Επαυξητικής Επικοινωνίας (ΕΕΕ), ο ΟΔΥΣΣΕΑΣ παρέχει ένα περιβάλλον προσανατολισμένο στην επαναχρησιμοποίηση συστατικών (engineering-forreuse) δίνοντας οδηγίες, κατευθυντήριες γραμμές και εργαλεία για την κατασκευή συστατικών λογισμικού, τα οποία μπορούν να λειτουργούν αποδοτικά και να αλληλεπιδρούν μεταξύ τους με διαφάνεια, χωρίς να γνωρίζουν καν το ένα την ύπαρξη του άλλου. Τέλος, το πλαίσιο προσφέρει στους κατασκευαστές το κεντρικό συστατικό που συγχρονίζει την εφαρμογή, τις διεπαφές μετάδοσης δεδομένων μεταξύ συστατικών, δοκιμαστικά συστατικά για διενέργεια ελέγχων συμβατότητας των συστατικών που κατασκευάζουν και βοηθητικό κώδικα. Επίσης, ο ΟΔΥΣΣΕΑΣ θεσπίζει διαδικασίες βασισμένες στην επαναχρησιμοποίηση έτοιμων συστατικών (engineering-with-reuse) για τους πωλητές (integrators) συστημάτων ΕΕΕ για την επιλογή συστατικών ανάλογα με τις ανάγκες κάθε χρήστη και τη συναρμολόγηση εφαρμογών από τμήματα κατασκευασμένα ανεξάρτητα. Με το πλαίσιο που προτείνεται τόσο ο συγχρονισμός και συνδυασμός τμημάτων λογισμικού, όσο και η προσθήκη ή αφαίρεση χαρακτηριστικών και λειτουργιών από το τελικό προϊόν γίνεται μια εύκολη διαδικασία για πωλητές συστημάτων ΕΕΕ. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 5 από 163

6 -ΜΕΡΟΣ Α: Σχεδιασμός του Πλαισίου- Σελίδα 6 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

7 1. Εισαγωγή Το Πλαίσιο (Framework) Σχεδιασμού και Ανάπτυξης Εφαρμογών που θα εφαρμοστεί στον τομέα Βοηθημάτων Διαπροσωπικής Επικοινωνίας [ 1] και θα περιγραφεί εδώ, έχει ως στόχο την μελέτη και ανάπτυξη μιας νέας σταθερής πλατφόρμας για την γρήγορη και με μικρό κόστος υλοποίηση από διάφορους κατασκευαστές, ευέλικτων και βελτιωμένων επικοινωνιακών βοηθημάτων που βασίζονται σε ηλεκτρονικό υπολογιστή. Αυτό θα επιτευχθεί με την υιοθέτηση συγκεκριμένων τυποποιήσεων, τη θέσπιση αυστηρών προδιαγραφών και την ανάπτυξη μιας αρθρωτής αρχιτεκτονικής και των σχετικών βοηθητικών εργαλείων ανάπτυξης λογισμικού. Σύμφωνα με τον Booch [39] ένα πλαίσιο είναι «ένα σχέδιο αρχιτεκτονικής λογισμικού που προσφέρει μια φόρμα ή ένα περίγραμμα για εφαρμογές σε έναν συγκεκριμένο τομέα ενδιαφέροντος». Όλα όσα αναφέρονται στην σύντομη παρουσίαση του πλαισίου στην εισαγωγή αυτή, αναλύονται με λεπτομέρεια στα επιμέρους κεφάλαια της παρούσας διπλωματικής εργασίας. Τα Συστήματα Εναλλακτικής και Επαυξητικής Επικοινωνίας ή Βοηθήματα Διαπροσωπικής Επικοινωνίας απευθύνονται σε χρήστες Άτομα Με Αναπηρίες (ΑΜΑ) [2]. Τα Βοηθήματα Διαπροσωπικής Επικοινωνίας που μας απασχολούν στην παρούσα εργασία βασίζονται σε ηλεκτρονικούς υπολογιστές και είναι συχνά πολύπλοκα συστήματα που πολλές φορές έχουν σαν έξοδο φωνή και επικεντρώνονται στις ανάγκες κάποιου συγκεκριμένου χρήστη. Μετά από μια αρχική εκτίμηση των επικοινωνιακών αναγκών του κάθε χρήστη και λαμβάνοντας υπόψη την κατάσταση των νευρολογικών του λειτουργιών, τις δυνατότητες κίνησής του καθώς και τις γλωσσικές του ικανότητες, καταρτίζεται συνήθως ένα πρόγραμμα επανένταξης το οποίο συχνά περιλαμβάνει τη χρήση εξοπλισμού. Ο εξοπλισμός αυτός δεν είναι ευρέως διαδεδομένος στη χώρα μας και τα συστήματα της αγοράς του εξωτερικού παρουσιάζουν δυο βασικά μειονεκτήματα: έχουν μεγάλο κόστος και δεν υποστηρίζουν την Ελληνική γλώσσα. Τα βοηθήματα αυτά πρέπει να παρουσιάζουν μεγάλη ευελιξία και προσαρμοστικότητα γιατί συνήθως πριν ολοκληρωθεί το πρόγραμμα επανένταξης πρέπει να μεταβάλλουν τα χαρακτηριστικά τους για να ικανοποιήσουν τις αυξημένες επικοινωνιακές ανάγκες του χρήστη. Για εκείνους που δεν μπορούν να χρησιμοποιήσουν το πληκτρολόγιο υπάρχουν εναλλακτικές μέθοδοι πρόσβασης στον υπολογιστή, όπως η χρήση του ποδιού, του κεφαλιού ή ακόμα και της κίνησης των βλεφάρων μέσω ειδικών συσκευών και διακοπτών. Το επικοινωνιακό βοήθημα θα πρέπει να παρέχει άμεση επικοινωνία με φράσεις ζωτικές για την ικανοποίηση καθημερινών αναγκών καθώς και με φράσεις χρήσιμες σε καθημερινούς διαλόγους. Ένας από τους σημαντικούς παράγοντες σε ένα σύστημα επικοινωνίας είναι η ταχύτητα επικοινωνίας που μπορεί να επιτευχθεί με αυτό. Θα πρέπει να τονίσουμε από την αρχή ότι το πλαίσιο που περιγράφεται εδώ δεν είναι ένα Βοήθημα Επικοινωνίας, αλλά υποστηρίζει την ανάπτυξη τέτοιων εφαρμογών. Το μονοπάτι της πληροφορίας ανάμεσα στον άνθρωπο και τον υπολογιστή που είναι από τη φύση του χαμηλού ρυθμού επιβραδύνεται ακόμα περισσότερο από την αναπηρία του χρήστη. Αυτό είναι ίσως και το σημαντικότερο τεχνικό πρόβλημα στην ανάπτυξη της συνεργασίας του ανθρώπου με τη μηχανή μιας συνεργασίας αρκετά καλής, ώστε να μπορέσει να αποδώσει αρκετά, με στόχο ο χρήστης με δυσκολίες στην ομιλία να μπορεί να πάρει μέρος σε μια συζήτηση. Χρειάζεται εντατική έρευνα για να μπορέσει να βελτιωθεί ή διεπαφή του χρήστη ώστε να μειωθεί στο ελάχιστο ή απαιτούμενη ροή πληροφορίας ανάμεσα στον άνθρωπο και τη μηχανή, καθώς και για τη δημιουργία εναλλακτικών Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 7 από 163

8 καναλιών επικοινωνίας ανθρώπου-μηχανής, τα οποία θα δώσουν στον χρήστη τη δυνατότητα να κωδικοποιεί την πληροφορία πιο εύκολα και γρήγορα. Ένα ευέλικτο πλαίσιο ανάπτυξης εφαρμογών δίνει μεγάλες δυνατότητες στους μελετητές-ερευνητέςπρογραμματιστές να πειραματιστούν χωρίς να κάνουν περιττό κόπο, απασχολούμενοι κάθε φορά μόνο με το κομμάτι της εφαρμογής που μελετούν (για παράδειγμα τη διεπαφή χρήστη). Ένα αρθρωτό επικοινωνιακό βοήθημα πρέπει να μπορεί να αντιμετωπίσει επαρκώς χρήστες με προβλήματα κίνησης, ομιλίας και αντίληψης. Όταν δημιουργείται μια ειδική λύση πρέπει να αντιμετωπιστούν τα ειδικά προβλήματα του ατόμου, ενώ παράλληλα το επικοινωνιακό βοήθημα που χρησιμοποιείται θα πρέπει να ταιριάζει με την διανοητική ικανότητα του ατόμου που το χρησιμοποιεί. Είναι λοιπόν αδύνατο να χρησιμοποιηθούν συγκεκριμένοι απλοί κανόνες στην διαδικασία αυτή. Απαιτείται συχνά η χρησιμοποίηση μιας μεθόδου δοκιμής και σφάλματος και έτσι η χρησιμοποιούμενη τεχνολογία πρέπει να επιτρέπει τις γρήγορες αλλαγές. Χρειάζονται πολλά διαφορετικά χαρακτηριστικά για να ικανοποιηθούν οι φυσικές ανάγκες, τα νοητικά και γλωσσικά επίπεδα και οι επικοινωνιακές ανάγκες των ανθρώπων που χρησιμοποιούν αυτά τα βοηθήματα. Επιπλέον, οι χρήστες υποβοηθητικής τεχνολογίας (assistive technology) συχνά κριτικάρουν την έλλειψη συμβατότητας και ολοκλήρωσης των διαφόρων συσκευών. Η χρήση ενός συνδυασμού από συσκευές οδηγεί σε μεγάλες δυσκολίες στην καθημερινή χρήση. Η σχεδίαση και ανάπτυξη των ήδη υπαρχόντων επικοινωνιακών βοηθημάτων πάσχει από την έλλειψη μιας γενικής τεχνικής λύσης που θα βοηθούσε την ανάπτυξη προσαρμοσμένων στο χρήστη και λειτουργικά ευέλικτων συστημάτων με βάση γενικά κριτήρια και εργαλεία. Η ιδανική τεχνολογική λύση θα ήταν αυτή που θα μπορούσε να επικεντρώσει στον συγκεκριμένο χρήστη, χρησιμοποιώντας τις ειδικές του ικανότητες στο μέγιστο και παράλληλα να έχει μόνο τα ειδικά χαρακτηριστικά, τα οποία εκείνος χρειάζεται. Όμως δεν είναι πρακτικό για τους προγραμματιστές να αναπτύσσουν πολλά, ειδικά για τον κάθε χρήστη συστήματα. Έτσι μπορούν να ακολουθηθούν οι εξής δρόμοι: 1. Η κατασκευή περιορισμένων συστημάτων τα οποία ικανοποιούν ανάγκες συγκεκριμένων ομάδων χρηστών. 2. Η ανάπτυξη παραμετρικών συστημάτων για όλες τις περιπτώσεις, στις παραμέτρους των οποίων δίδονται τιμές ώστε να καλύψουν τις συγκεκριμένες ανάγκες κάποιου χρήστη. 3. Η ανάπτυξη αρθρωτής αρχιτεκτονικής η οποία υποστηρίζει εξειδικευμένα τμήματα συστατικά (components) για μικρότερες ομάδες πιθανών χρηστών. Η πρώτη προσέγγιση είναι η πιο εύκολη να υλοποιηθεί τεχνικά, ενώ επιτυγχάνεται ευκολία χρήσης και αποτελεσματικότητα. Η απαιτήσεις μπορούν να ικανοποιηθούν και να επανεπεξεργαστούν όπως συνήθως χρειάζεται, μέσα από μια διαρκή διαδικασία αξιολόγησης με κάποια ομάδα σταθερών «πελατών». Το πρόβλημα είναι ότι παράγονται ακριβά προϊόντα λόγω των μικρών αριθμών παραγωγής. Επίσης, θα υπάρχουν πάντα μερικοί πελάτες οι οποίοι παραβλέπονται λόγω τις ειδικότητας των αναγκών τους. Οι τελευταίες δύο προσεγγίσεις έχουν τη δυνατότητα να καλύψουν μεγαλύτερες ομάδες χρηστών. Η κάθε μια από αυτές έχει τα δικά της πλεονεκτήματα και μειονεκτήματα. Στην δεύτερη προσέγγιση ο υπεύθυνος για την ανάπτυξη μπορεί να διατηρήσει τον έλεγχο για όλα τα θέματα που αφορούν το σύστημα και έτσι να εγγυηθεί τον έλεγχο της ποιότητας. Παραταύτα, ένα τέτοιο σύστημα τείνει να γίνει πολύπλοκο και ο πελάτης πρέπει να Σελίδα 8 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

9 αγοράσει όλο το πακέτο. Ο μεγάλος αριθμός παραμέτρων προσαρμογής επίσης μπορεί να οδηγήσει τον πελάτη σε αδιέξοδο μιας και θα είναι δύσκολο γι αυτόν να καταλάβει πως ακριβώς θα πρέπει να ρυθμιστεί κάθε παράμετρος. Η αρθρωτή προσέγγιση είναι η καλύτερη για να ακολουθηθεί για πολλούς λόγους. Ο πιο σημαντικός είναι το γεγονός ότι οι χρήστες θα μπορούν στις περισσότερες περιπτώσεις να αγοράσουν μόνο τις λειτουργίες εκείνες που τους είναι απαραίτητες. Αυτό θα μπορούσε να μεταφραστεί σε μικρότερο κόστος γιατί είναι ευκολότερο να αναπτυχθούν πολλά μικρά τμήματα λογισμικού και υλικού με εξειδικευμένες δυνατότητες. Επίσης, η δυσκολία και το κόστος προσαρμογής είναι μικρότερο γιατί μόνο σχετικοί με το χρήστη παράμετροι πρέπει να κατανοηθούν και να ρυθμιστούν. Αφού οι χρήστες δεν έχουν πρόσβαση σε χαρακτηριστικά που δεν τους είναι γνωστά, είναι λιγότερο πιθανό να μπερδευτούν από αυτά. Μια αξιόπιστη αρθρωτή σχεδίαση θα μπορούσε να λύσει το πρόβλημα των αναγκών του χρήστη καθώς αυτές αλλάζουν με τον χρόνο. Δυστυχώς, τα αρθρωτά συστήματα δεν είναι εύκολο να υλοποιηθούν. Αυτό συμβαίνει γιατί οι υπεύθυνοι ανάπτυξης δεν μπορούν να γνωρίζουν πώς διάφορα τμήματα μπορούν να συνδυαστούν ή ακόμα μπορεί και να μην είναι γνωστή σε αυτούς η ύπαρξη κάποιου ήδη έτοιμου τμήματος. Έτσι τα διάφορα τμήματα θα πρέπει να καταγραφούν και να χωριστούν σε κατηγορίες με κοινούς στόχους και λειτουργικότητα. Σε κάθε τέτοιο συστατικό (component) ή τμήμα ενός βοηθήματος χρειάζεται μια λογική ισορροπία ανάμεσα στην ευελιξία και στα τυποποιημένα χαρακτηριστικά. Ονομάζουμε το πλαίσιο που περιγράφουμε «ΟΔΥΣΣΕΑ» για να μπορούμε να αναφερόμαστε εύκολα σε αυτό. Ο ΟΔΥΣΣΕΑΣ φιλοδοξεί λοιπόν να δώσει λύσεις στα εξής σημαντικά προβλήματα Βοηθημάτων Επικοινωνίας που σχετίζονται με: Την έλλειψη ποικιλίας σε Βοηθήματα Επικοινωνίας στην αγορά, ιδιαίτερα την Ελληνική Την υψηλή τιμή αγοράς τέτοιων προϊόντων. Τις μεγάλες ανάγκες παραμετροποίησης. Τις μεταβαλλόμενες απαιτήσεις των χρηστών. Τις γρήγορες αλλαγές στην τεχνολογία λογισμικού και υλικού. Την έλλειψη επαναχρησιμοποίησης κώδικα και συστατικών. Τον κατακερματισμό της αγοράς. Την έλλειψη συμβατότητας μεταξύ των διαφόρων συστατικών ενός Βοηθήματος Επικοινωνίας όταν αυτά προέρχονται από διαφορετικούς κατασκευαστές. Την αδυναμία συνεργασίας των κατασκευαστών. Την έλλειψη βοηθημάτων που να υποστηρίζουν την Ελληνική γλώσσα. Το πλαίσιο ΟΔΥΣΣΕΑΣ δεν είναι η πρώτη προσπάθεια για την αντιμετώπιση των προβλημάτων της αγοράς λογισμικού Βοηθημάτων Διαπροσωπικής Επικοινωνίας, μέσω της καθιέρωσης νέων κατάλληλων αρχιτεκτονικών και τυποποιήσεων. Γενικά για τον τομέα της τεχνολογίας λογισμικού έχουν υπάρξει προτάσεις και λύσεις όπως μοντέλα αντικειμενοστραφούς προγραμματισμού - OMT [4], [5], μοντέλα προγραμματισμού με Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 9 από 163

10 συστατικά - COM [6], [7], [8] και συνδυασμοί, επεκτάσεις ή παραλλαγές των προηγουμένων με εφαρμογή στον κατανεμημένο προγραμματισμό - DCOM [9], [10], CORBA [10], [11]. Αυτά τα μοντέλα και οι αρχιτεκτονικές θα μελετηθούν στο πλαίσιο της ανάπτυξης του ΟΔΥΣΣΕΑ, και θα συγκριθούν μεταξύ τους. Ιδιαίτερη έμφαση στην ανάλυση αυτή, θα δοθεί στο τεχνολογικά νεώτερο, αλλά και αρτιότερο μοντέλο, δηλαδή το COM+ [12], [13], [14]. Συγκεκριμένα για το χώρο των Βοηθημάτων Επικοινωνίας υπήρξαν προτάσεις στο παρελθόν, όπως αυτές του έργου ACCESS, το οποίο χρηματοδοτήθηκε από το Πρόγραμμα TIDE της Ευρωπαϊκής Ένωσης, και της αρχιτεκτονικής ATIC που προέκυψε από αυτό [15], [16], [17], [18], [19], [20], [21], [22], [38]. Στα πλαίσια αυτού του έργου αναπτύχθηκε ένα πλαίσιο που περιελάμβανε μια αυτοσχέδια (proprietary) αρχιτεκτονική, πρωτόκολλο επικοινωνίας μεταξύ συστατικών και έναν αυτοσχέδιο διαχειριστή (broker) των συστατικών και των μηνυμάτων που έπρεπε να ανταλλάσσονται μεταξύ τους. Όλα αυτά μαζί κάλυπταν τις ανάγκες για μια νέα προσέγγιση στην τυποποίηση και υποβοήθηση της δημιουργίας Βοηθημάτων Επικοινωνίας με βάση τις τότε (1995) δυνατότητες της τεχνολογίας λογισμικού. Ο ΟΔΥΣΣΕΑΣ δεν απορρίπτει τα επιτεύγματα τέτοιων παλαιότερων προσπαθειών, αλλά προχωρά ένα βήμα παραπάνω. Προσαρμόζει τις βασικές αρχές τους στη σημερινή τεχνολογία, εξελίσσει και απλοποιεί τις αρχιτεκτονικές και τις τυποποιήσεις που προτάθηκαν. Μια επίσης σημαντική προσπάθεια του παρελθόντος που μελετήθηκε στα πλαίσια ανάπτυξης του ΟΔΥΣΣΕΑ είναι και το πλαίσιο COMSPEC [23], [24]. Επρόκειτο για μια διαφορετική προσέγγιση που βασιζόταν στην φιλοσοφία της γεννήτριας εφαρμογών, ενός πακέτου λογισμικού που προσφέρει ένα πλήρες περιβάλλον ανάπτυξης Βοηθημάτων Επικοινωνίας με κατάλληλα εργαλεία και μεθοδολογίες. Αυτή η προσέγγιση θεωρήθηκε πολύ περιοριστική ως προς τις δυνατότητές της, μια και παρήγαγε πολύ συγκεκριμένους τύπους Βοηθημάτων και πολύ πολύπλοκη και χρονοβόρα για την δημιουργία μιας παρεμφερούς υποδομής. Προτιμήθηκε να αφεθεί μεγαλύτερη ελευθερία στους κατασκευαστές που σε τελική ανάλυση πρέπει να πεισθούν για την αποτελεσματικότητα, τις δυνατότητες και την ευκολία χρήσης ενός πλαισίου ανάπτυξης Βοηθημάτων Επικοινωνίας. Ο ΟΔΥΣΣΕΑΣ βασίζεται στις νέες τεχνολογίες. Το πλαίσιο «ΟΔΥΣΣΕΑΣ» αναπτύχθηκε έτσι, ώστε να υποστηρίζει τις νέες τεχνολογίες αιχμής που κυριαρχούν στον τομέα της τεχνολογίας λογισμικού. Επιλέχτηκε να υποστηρίζει την πλατφόρμα των προσωπικών υπολογιστών που είναι εφοδιασμένοι με το λειτουργικό σύστημα Windows Σχεδιάστηκε ώστε να εκμεταλλεύεται πλήρως τις τεχνολογικές καινοτομίες που προσφέρει αυτό το λειτουργικό σύστημα σε όλες του τις εκδόσεις, όπως το COM+ [26], [27] και τα Component Services. Θα πρέπει να ενθαρρύνει την ανάπτυξη συστατικών σε μοντέρνα εργαλεία ή γλώσσες προγραμματισμού όπως η Microsoft Visual Basic [28], η Microsoft Visual C++ και η Java. Σημαντικό είναι το γεγονός ότι το πλαίσιο προτείνει τη χρησιμοποίηση μοντέρνων και ευρέως διαδεδομένων τεχνικών προγραμματισμού όπως ο αντικειμενοστραφής προγραμματισμός [4], [5] ο προγραμματισμός που βασίζεται σε συστατικά [28] και ο κατανεμημένος προγραμματισμός [9]. Κυρίως όμως, είναι έτσι σχεδιασμένο ώστε να έχει ως εγγενές χαρακτηριστικό του την υποστήριξη του Διαδικτύου και των υπηρεσιών του. Ο ΟΔΥΣΣΕΑΣ επικεντρώνεται στην Τεχνολογία Λογισμικού. Το πλαίσιο ΟΔΥΣΣΕΑΣ στην πραγματικότητα θα προτείνει μια σειρά από οδηγίες που απευθύνονται στους κατασκευαστές Βοηθημάτων Επικοινωνίας ή τμημάτων τέτοιων Σελίδα 10 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

11 εφαρμογών, ώστε να κατασκευάζονται αποδοτικά, διαδραστικά, αρθρωτά, επεκτάσιμα και επαναχρησιμοποιούμενα τμήματα λογισμικού. Επίσης, προσφέρει υλοποιημένα τμήματα λογισμικού για τη δοκιμή των προτεινόμενων τεχνολογιών και αρχιτεκτονικών, τα οποία χρησιμεύουν και ως πρότυπα υποδείγματα για τον τρόπο που θα πρέπει να κατασκευάζονται τμήματα Βοηθημάτων Επικοινωνίας. Το πλαίσιο περιλαμβάνει πλήρη περιγραφή των τεχνικών προγραμματισμού και των τυποποιήσεων που πρέπει να ακολουθηθούν, ώστε να παραχθούν από ανεξάρτητους κατασκευαστές τμήματα λογισμικού που θα μπορούν να συνεργάζονται μεταξύ τους με σκοπό να ολοκληρώνονται σε ένα ενιαίο και λειτουργικό Βοήθημα Επικοινωνίας. Αυτά τα τμήματα λογισμικού λέγονται συστατικά (components) [30]. Σύμφωνα με τον Booch [39] το συστατικό είναι ένα «φυσικό και αντικαταστήσιμο τμήμα ενός συστήματος που υλοποιεί και συμμορφώνεται σε ένα σύνολο διεπαφών». Επίσης, σύμφωνα με το Hopkins [40] ένα συστατικό λογισμικού είναι «ένα φυσικό πακετάρισμα εκτελέσιμου λογισμικού με καλά ορισμένη και δημοσιοποιημένη διεπαφή». Τέλος, ο ΟΔΥΣΣΕΑΣ προσφέρει ένα εκτελέσιμο πρόγραμμα το οποίο χρησιμεύει για την εκκίνηση του βοηθήματος Διαπροσωπικής Επικοινωνίας και τον συγχρονισμό και την ταξινόμηση των συστατικών που το αποτελούν. Όλα αυτά που αναφέρθηκαν και θα περιγραφούν με λεπτομέρεια στα επόμενα κεφάλαια, αφορούν την κύρια ομάδα χρηστών στην οποία απευθύνεται το «πλαίσιο ΟΔΥΣΣΕΑΣ» και είναι οι προγραμματιστές ή οι κατασκευαστές λογισμικού. Υπάρχει όμως και μια δεύτερη ομάδα χρηστών στην οποία απευθύνεται το πλαίσιο και αυτή είναι οι πωλητές ή ολοκληρωτές Βοηθημάτων Διαπροσωπικής Επικοινωνίας. Για αυτή την ομάδα χρηστών, το πλαίσιο ΟΔΥΣΣΕΑΣ προσφέρει ένα «Εγχειρίδιο Χρήσης», όπου περιγράφονται με λεπτομέρεια οι διαδικασίες που πρέπει να ακολουθηθούν για την σύνθεση και το συγχρονισμό των έτοιμων συστατικών ενός Βοηθήματος Επικοινωνίας, καθώς και όλες οι διαχειριστικές ενέργειες που πρέπει να γίνουν για τη σωστή του λειτουργία στο στάδιο της εγκατάστασής του στον ηλεκτρονικό υπολογιστή του χρήστη ΑΜΑ. Ο ΟΔΥΣΣΕΑΣ και το Διαδίκτυο Η σχέση του πλαισίου ΟΔΥΣΣΕΑΣ με το Διαδίκτυο δεν περιορίζεται στην εγγενή υποστήριξη του Διαδικτύου από την αρχιτεκτονική του. Το πλαίσιο προτείνει τη χρήση του Διαδικτύου ως ένα πολύτιμο εργαλείο. Τα προϊόντα της υλοποίησης του ΟΔΥΣΣΕΑ, πρέπει να βρίσκονται διαθέσιμα στο Διαδίκτυο για να χρησιμοποιούνται από τους κατασκευαστές και τους πωλητές Βοηθημάτων Διαπροσωπικής Επικοινωνίας. Συγκεκριμένα θα πρέπει να διανέμονται ελεύθερα από το Διαδίκτυο τμήματα λογισμικού (βιβλιοθήκες, έτοιμα συστατικά δοκιμών και συστατικά αναφοράς) που αναπτύχθηκαν και έχουν σκοπό: την τυποποίηση της επικοινωνίας μεταξύ των συστατικών τον έλεγχο της συμβατότητας των συστατικών (υλοποιημένα συστατικά εισόδου, εξόδου και ενδιάμεσα συστατικά) την υποβοήθηση συγγραφής κώδικα για συστατικά την εκκίνηση ενός βοηθήματος Διαπροσωπικής Επικοινωνίας και των συστατικών του Φυσικά τα συστατικά και οι βιβλιοθήκες που αναφέρθηκαν θα είναι διαθέσιμα και ως δυαδικά αρχεία, αλλά και ως κώδικας. Δεν είναι όμως μόνο αυτό. Διαθέσιμες στο Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 11 από 163

12 Διαδίκτυο θα πρέπει να βρίσκονται και όλες οι τυποποιήσεις και οι οδηγίες που δίνει ο ΟΔΥΣΣΕΑΣ προς του κατασκευαστές, αλλά και το εγχειρίδιο χρήσης για την Εγκατάσταση Βοηθημάτων Διαπροσωπικής Επικοινωνίας που βασίζονται στο πλαίσιο ΟΔΥΣΣΕΑΣ. Τέλος ο ρόλος του Διαδικτύου είναι σημαντικότατος γιατί εκεί προτείνεται να συγκεντρώνεται κάθε νέα πληροφορία για νέα διαθέσιμα συστατικά Βοηθημάτων Διαπροσωπικής Επικοινωνίας που κατασκευάζονται ανεξάρτητα, από τρίτους κατασκευαστές. Θα είναι η πηγή για τους πωλητές και για κάθε ενδιαφερόμενο, όπου θα φαίνεται τι υπάρχει διαθέσιμο για τη σύνθεση ενός πλήρους βοηθήματος, αλλά και ο τρόπος που θα γίνει η σύνθεση αυτή. Η δομή της παρούσας μελέτης Στο πρώτο μέρος της εργασίας θα περιγράψουμε τι είναι το πλαίσιο ΟΔΥΣΣΕΑΣ, και θα εκθέσουμε τις προδιαγραφές και τα χαρακτηριστικά του. Επιπλέον, θα παρουσιαστεί η διαδικασία έρευνας και μελέτης που ακολουθήθηκε ή τουλάχιστο μέρος αυτής για να καταλήξουμε στη λύση που προτείνουμε. Επίσης, περιγράφονται λεπτομερώς οι τεχνολογίες που προτείνονται και αναπτύσσονται οι λόγοι μας έκαναν να τις επιλέξουμε. Το πρώτο αυτό μέρος που αφορά το σχεδιασμό του πλαισίου αποτελείται από επτά κεφάλαια, των οποίων το πρώτο αποτελεί την παρούσα Εισαγωγή. Στο δεύτερο κεφάλαιο αναλύεται το πρόβλημα που φιλοδοξεί να αντιμετωπίσει το Πλαίσιο Σχεδιασμού και Ανάπτυξης Βοηθημάτων Διαπροσωπικής Επικοινωνίας ΟΔΥΣΣΕΑΣ. Επίσης, δίδεται μια γενική περιγραφή της λύσης που προτείνεται και των προδιαγραφών του πλαισίου. Στη συνέχεια αναλύονται τα περιεχόμενα, οι προτάσεις και τα χαρακτηριστικά του ΟΔΥΣΣΕΑ σε έξι διαφορετικούς άξονες: Τυποποιήσεις και οδηγίες Λογισμικό υποβοήθησης υλοποίησης συστατικών Λογισμικό ελέγχου συμβατότητας συστατικών Λογισμικό διασύνδεσης συστατικών Ολοκλήρωση του πλαισίου Υποστήριξη Διαδικτύου Στο τρίτο κεφάλαιο παρουσιάζονται διάφορες προσεγγίσεις για ένα βασικό πρόβλημα Τεχνολογίας Λογισμικού που αφορά το πλαίσιο ΟΔΥΣΣΕΑΣ και είναι αυτό τις Επικοινωνίας μεταξύ Διεργασιών [34] που έχει άμεση σχέση με την επικοινωνία μεταξύ των συστατικών. Αναφέρονται τεχνικές όπως η χρησιμοποίηση του Clipboard των Windows [32], του OLE που βασίζεται στο COM, της τεχνολογίας Dynamic Data Exchange (DDE) [31], [32], του File Mapping, των Mailslots, των Σωληνώσεων (pipes) [33], των Remote Procedure Calls κλπ. Όλα αυτά αναλύονται ως λύσεις για την επικοινωνία μεταξύ των συστατικών και ως μια αναφορά για τους τρόπους επίτευξης αυτής της επικοινωνίας που χρησιμοποιούνταν πριν τον ΟΔΥΣΣΕΑ. Επιλέγεται ως καταλληλότερη για τις ανάγκες του έργου η τεχνολογία που βασίζεται σε COM και αναλύεται στο επόμενο κεφάλαιο με λεπτομέρεια. Το τέταρτο κεφάλαιο παρουσιάζει με λεπτομέρεια το Μοντέλο Συστατικών και Αντικειμένων (Component Object Model COM) [27], [35], το οποίο αποτελούσε την ευρύτερα διαδεδομένη τεχνολογία στο χώρο των μοντέλων, τεχνικών και αρχιτεκτονικών προγραμματισμού, όταν ξεκίνησε η μελέτη για το πλαίσιο ΟΔΥΣΣΕΑΣ. Είναι το μοντέλο Σελίδα 12 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

13 που χρησιμοποιείται από τους περισσότερους προγραμματιστές σήμερα και ικανοποιεί κατά μεγάλο μέρος τις απαιτήσεις του ΟΔΥΣΣΕΑ. Πραγματεύεται τις έννοιες των αντικειμένων και των πολύ σημαντικών για τον ΟΔΥΣΣΕΑ διεπαφών, την επαναχρησιμοποίηση των αντικειμένων και το μοντέλο πελάτη/εξυπηρέτη (client/server) για την επικοινωνία. Αυτό το μοντέλο και η ενσωματωμένη υποδομή που παρέχει στο λειτουργικό σύστημα των Windows 95 και 98 θα μας ήταν αρκετό, αν δεν είχαμε την επιθυμία για εγγενή υποστήριξη απομακρυσμένων διεργασιών και του Διαδικτύου και ιδιαίτερα για προηγμένη φιλοσοφία επικοινωνίας των συστατικών. Στο επόμενο λοιπόν κεφάλαιο εξετάζουμε την επέκτασή του μοντέλου δηλαδή το DCOM. Το πέμπτο κεφάλαιο ασχολείται με την αρχιτεκτονική και τα χαρακτηριστικά της «δικτυακής» επέκτασης του COM που ονομάζεται Κατανεμημένο Μοντέλο Συστατικών και Αντικειμένων (Distributed Component Object Model DCOM). Υπάρχει ένας βασικός αντίπαλος αυτού του μοντέλου που ονομάζεται CORBA [10], [11] και ήταν επιβεβλημένη η λεπτομερής σύγκριση των δύο για να καταλήξουμε ότι το πρώτο είναι αυτό που ταιριάζει καλύτερα στις απαιτήσεις του ΟΔΥΣΣΕΑ. Η σύγκριση έγινε σε τρία επίπεδα που περιγράφονται λεπτομερώς και είναι τα εξής: Κορυφαίο Επίπεδο: Βασική Αρχιτεκτονική Προγραμματισμού Μεσαίο Επίπεδο: Αρχιτεκτονική Απομακρυσμένων Διαδικασιών Χαμηλό Επίπεδο: Αρχιτεκτονική Πρωτοκόλλου Επικοινωνίας Επίσης, και στο σημείο αυτό, θα μας ήταν αρκετά όσα μελετήσαμε και αξιολογήσαμε μέχρι τώρα ως υποδομή για το πλαίσιο ΟΔΥΣΣΕΑΣ, αν δεν μας προλάβαινε πάλι η τεχνολογία, και τις λίγες ελλείψεις που υπήρχαν δεν τις κάλυπτε μια νέα αρχιτεκτονική που εδραιώθηκε κατά τη διάρκεια της μελέτης. Αποτέλεσμα της εφαρμογής της νέας φιλοσοφίας και των τεχνολογικών αλλαγών ήταν το COM+ που περιγράφεται στο επόμενο κεφάλαιο. Το έκτο κεφάλαιο ασχολείται με την «ψυχή» του πλαισίου «ΟΔΥΣΣΕΑΣ». Πρόκειται για τη νεότερη τεχνολογία στο χώρο των μοντέλων προγραμματισμού και ονομάζεται COM+ Component Services (Υπηρεσίες Συστατικών). Είναι μια αρχιτεκτονική που καλύπτει όλα τα κενά και τις αδυναμίες που είχαν οι προηγούμενες προσεγγίσεις που αντιμετώπιζαν τα προβλήματα που φιλοδοξεί να λύσει ο ΟΔΥΣΣΕΑΣ. Στην ουσία αποτελεί μια εξέλιξη όλων των προηγούμενων μοντέλων που περιγράφτηκαν και επιλέχτηκαν, δηλαδή του COM και του DCOM σε συνδυασμό με ένα σύνολο από πολύτιμες λειτουργίες και υπηρεσίες ενσωματωμένες στο λειτουργικό σύστημα των Windows Ενσωματώνει επίσης και την εξέλιξη του Microsoft Transaction Server, μιας υπηρεσίας που προσφερόταν μέχρι τώρα στα λειτουργικά συστήματα με τεχνολογία ΝΤ (Windows NT) και εξυπηρετούσε πολλαπλές ανάγκες επικοινωνίας μεταξύ διεργασιών ανεξάρτητα με το που βρίσκονται (στο ίδιο μηχάνημα, στο δίκτυο ή στο Διαδίκτυο). Το νέο μοντέλο δεν καταργεί ό τι έχει εδραιωθεί μέχρι τώρα, αλλά το βελτιώνει και το απλοποιεί. Παρουσιάζεται μια ανασκόπηση για την εξέλιξη του μοντέλου, όπου φαίνεται και η σχέση του με τα προηγούμενα και στη συνέχεια αναλύονται λεπτομερώς οι επιμέρους υπηρεσίες που προσφέρει το μοντέλο και συγκεκριμένα αυτές στις οποίες στηρίζεται το πλαίσιο ΟΔΥΣΣΕΑΣ. Το κεφάλαιο 7 ασχολείται με λεπτομέρειες και αποσαφηνίσεις του σχεδιασμού του ΟΔΥΣΣΕΑ, όπως αυτός περιγράφηκε γενικά στο κεφάλαιο 2. Συγκεκριμενοποιούνται οι ομάδες χρηστών του πλαισίου και αναφέρεται τι προσφέρει η υλοποίηση του ΟΔΥΣΣΕΑ σε αυτούς τους χρήστες, όπως επίσης περιγράφεται και ο σχεδιασμός του πρωτοκόλλου Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 13 από 163

14 επικοινωνίας μεταξύ των συστατικών ενός Βοηθήματος Επικοινωνίας και της διεπαφής που χρησιμοποιεί ο ΟΔΥΣΣΕΑΣ για την επικοινωνία αυτή. Στο έβδομο κεφάλαιο περιλαμβάνεται επίσης ο σχεδιασμός όλων των προγραμμάτων που αναπτύχθηκαν στα πλαίσια του ΟΔΥΣΣΕΑ και παρουσιάζονται οι προδιαγραφές και τα χαρακτηριστικά τους. Παρουσιάζονται τα συστατικά δοκιμών και το πρόγραμμα εκκίνησης του Βοηθήματος Διαπροσωπικής επικοινωνίας. Επειδή δεν πρόκειται για ολοκληρωμένες εφαρμογές αλλά για μικρά τμήματα ενός συστήματος, δεν θα ακολουθηθεί η παραδοσιακή διαδικασία παρουσίασης του σχεδιασμού με ειδικές γλώσσες μοντελοποίησης όπως η Ενοποιημένη Γλώσσα Μοντελοποίησης (Unified Modeling Language UML) [36], ούτε θα χρησιμοποιηθούν πολύπλοκα εργαλεία όπως το Microsoft Visual Modeler [37]. Όλα αυτά χρησιμοποιούνται συνήθως σε μοντελοποιήσεις εφαρμογών και συστημάτων μεγαλύτερης κλίμακας από αυτά που θα σχεδιαστούν στο κεφάλαιο 7. Έτσι προτιμήθηκε η προσέγγιση των κατατοπιστικών γραφικών απεικονίσεων και σχημάτων για την περιγραφή των συστατικών. Επίσης, σε αυτό το κεφάλαιο περιλαμβάνεται και ο σχεδιασμός της αλληλεπίδρασης των πωλητών Βοηθημάτων Επικοινωνίας με το διαχειριστικό περιβάλλον με το οποίο τους φέρνει σε επαφή ο ΟΔΥΣΣΕΑΣ. Η σύνθεση όλων των αποτελεσμάτων της μελέτης των μοντέλων που αναφέρθηκαν και η κατασκευή του πλαισίου ΟΔΥΣΣΕΑΣ είναι το αντικείμενο του δεύτερου μέρους της παρούσας μελέτης που αναφέρεται στην υλοποίηση του πλαισίου. Σε αυτό περιλαμβάνεται ο κώδικας βάσει του οποίου υλοποιήθηκαν τα συστατικά του ΟΔΥΣΣΕΑ. Επίσης, περιλαμβάνονται οι τυποποιήσεις και οι οδηγίες που απευθύνονται στους προγραμματιστές συστατικών, καθώς και το πλήρες εγχειρίδιο χρήσης που απευθύνεται στους πωλητές Βοηθημάτων Διαπροσωπικής Επικοινωνίας. Σελίδα 14 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

15 2. Το Πλαίσιο «ΟΔΥΣΣΕΑΣ» Ξεκινώντας την περιγραφή του Πλαισίου Σχεδιασμού και Ανάπτυξης Βοηθημάτων Διαπροσωπικής Επικοινωνίας «ΟΔΥΣΣΕΑΣ» παρουσιάζουμε τα προβλήματα που φιλοδοξεί να λύσει αυτό το πλαίσιο. Στη συνέχεια δίνεται μια πρώτη περιγραφή της λύσης που προτείνεται για τα προβλήματα αυτά. Το επόμενο βήμα είναι να γίνει μια γενική περιγραφή του τι είναι ένα πλαίσιο ανάπτυξης εφαρμογών και να επιλεχτεί η κατεύθυνση που θα ακολουθηθεί κατά το σχεδιασμό του ΟΔΥΣΣΕΑ. Το παρόν κεφάλαιο θα ολοκληρωθεί με την ανάλυση της μεθοδολογίας ανάπτυξης του ΟΔΥΣΣΕΑ και με τη λεπτομερή περιγραφή του πλαισίου στους άξονες που σχεδιάστηκε Το πρόβλημα Το πρόβλημα επικοινωνίας που έχουν αρκετά Άτομα Με Αναπηρίες (ΑΜΑ) είναι σοβαρότατο [2]. Στη χώρα μας υπάρχουν πολλοί άνθρωποι που αδυνατούν να ζήσουν μια φυσιολογική ζωή, λόγω κινητικών ή και νοητικών προβλημάτων. Βοηθήματα Επαυξητικής και Εναλλακτικής Επικοινωνίας (ΕΕΕ) μπορούν να δώσουν λύση σε αυτό το πρόβλημα και η τεχνολογία είναι σε θέση να βελτιώσει δραματικά την ποιότητα ζωής και την ένταξη στην κοινωνία των ατόμων με ειδικές επικοινωνιακές ανάγκες [25], [38]. Σήμερα, αν και υπάρχουν παγκοσμίως πολλές μεμονωμένες λύσεις για βοηθήματα επικοινωνίας που απευθύνονται σε ΑΜΑ [22], είναι έντονο το πρόβλημα της διαθεσιμότητας των βοηθημάτων αυτών στους Έλληνες χρήστες από τη μία, αλλά και της συμβατότητας των προϊόντων των διάφορων εταιριών μεταξύ τους. Ένα ΑΜΑ στην Ελλάδα είναι πολύ πιθανό να μην γνωρίζει ή να μην έχει πρόσβαση σε πληροφορίες που θα μπορούσαν να του προσφέρουν μία έτοιμη λύση για το επικοινωνιακό του πρόβλημα. Βέβαια θα περίμενε κανείς οι θεραπευτές του ατόμου αυτού να είναι σε θέση και να έχουν τα εφόδια ώστε να ψάξουν και να βρουν στην παγκόσμια αγορά κάποιο προϊόν που θα έκανε την καθημερινή ζωή του πιο εύκολη στον τομέα της επικοινωνίας του. Οποιοσδήποτε ενδιαφερόμενος θα μπορούσε διενεργώντας μια σχετικά σύντομη έρευνα στον Παγκόσμιο Ιστό, να βρει κάποια λύση βασισμένη στην τεχνολογία των υπολογιστών, η οποία θα προσφέρει στο ΑΜΑ νέες δυνατότητες διαπροσωπικής επικοινωνίας. Δυστυχώς, ακόμη και οι θεραπευτές ή οι άνθρωποι που βοηθούν τα ΑΜΑ στην καθημερινή τους ζωή δεν βρίσκουν εύκολη τη διαδικασία αυτή, και είναι πολύ πιθανό να μη γνωρίζουν την ύπαρξη στην αγορά προϊόντων που οι ίδιοι και τα ΑΜΑ έχουν φανταστεί τη λειτουργικότητά τους και εύχονται να ήταν διαθέσιμα σε αυτούς. Σε αυτές τις δυσκολίες θα πρέπει να προσθέσουμε και το γεγονός ότι το σύνολο σχεδόν των Διαδικτυακών τόπων που ασχολούνται με τέτοια θέματα είναι ξενόγλωσσοι. Επίσης, ξενόγλωσσα είναι και τα περισσότερα σχετικά προϊόντα που κυκλοφορούν στην αγορά, και το ίδιο φυσικά ισχύει και για τα εγχειρίδια χρήσης τους. Οι εταιρίες κατασκευής τέτοιων προϊόντων από την άλλη πλευρά, ίσως προσφέρουν ανακούφιση και βελτίωση της ποιότητας ζωής στις χώρες που εδρεύουν ή στις συγκεκριμένες τοπικές αγορές που απευθύνονται, αλλά δεν διαχέουν την τεχνογνωσία τους όσο θα έπρεπε στην παγκόσμια κοινότητα των ΑΜΑ και η διασπορά των προϊόντων τους κάνει δύσκολο τον εντοπισμό τους. Ακόμη, όσον αφορά στα προϊόντα που βασίζονται στην τεχνολογία των ηλεκτρονικών υπολογιστών, μια καλύτερη διαχείρισή τους ή ένας βελτιωμένος τρόπος ανάπτυξης και διανομής τους, θα μπορούσε να μειώσει δραματικά την Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 15 από 163

16 τιμή τους και συγχρόνως να αυξήσει τους αγοραστές τους. Η αγορά Βοηθημάτων Διαπροσωπικής Επικοινωνίας είναι κατακερματισμένη. Οι εταιρίες αναπτύσσουν τα προϊόντα τους «κατά βούληση» και ανεξάρτητα η μία από την άλλη με αποτέλεσμα η κάθε εταιρία να μην είναι σε θέση να καλύψει τον αριθμό των περιπτώσεων επικοινωνιακών αναγκών που θα ήθελε στον χρόνο που θα έπρεπε, αλλά και να υπάρχει μεγάλη επικάλυψη στη διαδικασία ανάπτυξης βοηθημάτων επικοινωνίας με επιβαρυντικές επιπτώσεις στο χρόνο ανάπτυξης και στην τελική τιμή του προϊόντος. Τέλος, αναπτύσσονται πολύ εξειδικευμένες λύσεις βοηθημάτων επικοινωνίας με καμία συμβατότητα μεταξύ τους, οι οποίες δεν υπακούουν σε μια κοινά αποδεκτή τυποποίηση ή σε κάποιους κανόνες ανάπτυξης και τυποποιημένες προδιαγραφές των βοηθημάτων. Οι εξειδικευμένες αυτές λύσεις είναι ακριβές και δύσκολα προσαρμόσιμες σε διαφορετικές επικοινωνιακές ανάγκες από αυτές για τις οποίες σχεδιάστηκαν και υλοποιήθηκαν. Αναγκαστικά λοιπόν μένει μερίδα της αγοράς των ΑΜΑ έξω από τα ενδιαφέροντα των εταιριών, μια και το εξειδικευμένο προϊόν που θα απευθυνόταν σε μικρή αγορά θα κατέληγε να είναι πανάκριβο για τους τελικούς χρήστες και ασύμφορο για τους κατασκευαστές. Από την άλλη πλευρά, αν η διαδικασία ανάπτυξης και σχεδιασμού των βοηθημάτων βασιζόταν στη φιλοσοφία ότι το τελικό προϊόν θα πρέπει να απευθύνεται στο μεγαλύτερο δυνατό κομμάτι της αγοράς ή των επικοινωνιακών αναγκών, να είναι πλήρως παραμετροποιήσιμο και προσαρμόσιμο, αυτό ίσως να οδηγούσε πάλι σε μεγάλο χρόνο και κόπο ανάπτυξης, αλλά και σε υψηλή τιμή του προϊόντος. Παρατηρείται στην αγορά ότι αν και υπάρχουν «κομμάτια» ενός βοηθήματος επικοινωνίας διαθέσιμα και φτηνά, αυτά τα «κομμάτια» αναπτύσσονται εκ νέου στα πλαίσια ενός «ολοκληρωμένου» βοηθήματος. Αν η μία εταιρία, για παράδειγμα, δραστηριοποιείται στο χώρο της σύνθεσης ομιλίας και έχει έτοιμα προϊόντα (συνθέτες ομιλίας) και η άλλη εταιρία κατασκευάζει ένα βοήθημα επικοινωνίας που κάνει χρήση συνθέτη ομιλίας, το πιθανότερο είναι η δεύτερη εταιρία να αναπτύξει από την αρχή το δικό της συνθέτη. Αυτό φαίνεται σαν διπλός κόπος με συνέπεια διπλό χρόνο και διπλό κόστος ανάπτυξης. Επίσης, όσον αφορά την ποιότητα του τελικού προϊόντος, είναι πιο πιθανό το αποτέλεσμα να ήταν καλύτερο αν για παράδειγμα στην ανάπτυξη ενός υπολογιστικού συστήματος που αποτελεί βοήθημα επικοινωνίας, μπορούσαν να συνεισφέρουν στον τομέα της σύνθεσης ομιλίας οι ειδικοί όπως επίσης και στον τομέα της εργονομίας και τέλος στον τομέα της πρόβλεψης λέξεων για τη γρηγορότερη επικοινωνία, πάλι οι ειδικοί του χώρου αυτού. Μεγάλο πρόβλημα θεωρείται και η αδυναμία υποστήριξης των μεταβαλλόμενων αναγκών των χρηστών Βοηθημάτων Διαπροσωπικής Επικοινωνίας. Αυτό το στοιχείο δημιουργεί την απαίτηση για βοηθήματα πλήρως παραμετροποιήσιμα, εύκολα τροποποιήσιμα, με δυνατότητες προσθαφαίρεσης σε αυτά λειτουργικοτήτων και υπηρεσιών. Με τους παραδοσιακούς τρόπους κατασκευής Βοηθημάτων, τέτοιες δυνατότητες θεωρούνται «εξωτικές». Μιλώντας πιο συγκεκριμένα για την τεχνολογία των υπολογιστών και της πληροφορικής, η συνεχείς καινοτομίες στο hardware και το software έχουν φέρει στις επιφάνειες εργασίας και τα δίκτυα των χρηστών μια πλειάδα δυνατών και σύγχρονων εφαρμογών. Όμως αυτή η ανάπτυξη έχει φέρει και τα ανάλογα προβλήματα στους προγραμματιστές, τους πωλητές λογισμικού και τους χρήστες: Σελίδα 16 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

17 Οι σημερινές εφαρμογές είναι μεγάλες και πολύπλοκες. Παίρνουν πολύ χρόνο για την ανάπτυξή τους, είναι δύσκολη και ακριβή η συντήρησή τους και η επέκτασή τους με πρόσθετες λειτουργίες. Οι εφαρμογές είναι μονολιθικές. Έρχονται πακεταρισμένες με μεγάλη ποικιλία χαρακτηριστικών, αλλά τα πιο πολλά χαρακτηριστικά δεν μπορούν να αφαιρεθούν, να αναβαθμιστούν ανεξάρτητα, ή να αντικατασταθούν από άλλα εναλλακτικά. Οι εφαρμογές δεν ολοκληρώνονται εύκολα. Τα δεδομένα και η λειτουργικότητα μιας εφαρμογής δεν είναι εύκολα προσβάσιμα από άλλες εφαρμογές, ακόμη κι αν οι εφαρμογές είναι γραμμένες στην ίδια γλώσσα προγραμματισμού και τρέχουν στον ίδιο υπολογιστή. Τα λειτουργικά συστήματα έχουν επίσης τα σχετικά προβλήματα. Δεν είναι αρκετά αρθρωτά και είναι δύσκολο να παρακαμφθούν, να αναβαθμιστούν, ή να αντικατασταθούν οι λειτουργίες που παρέχουν με έναν καθαρό και ευέλικτο τρόπο. Τα μοντέλα προγραμματισμού είναι ασυνεπή χωρίς να υπάρχει ιδιαίτερος λόγος. Ακόμα και όταν οι εφαρμογές έχουν τη δυνατότητα συνεργασίας, οι υπηρεσίες τους προσφέρονται σε άλλες εφαρμογές με διαφορετικό τρόπο από τις υπηρεσίες που προσφέρονται από το λειτουργικό σύστημα ή το δίκτυο. Ακόμα, τα προγραμματιστικά μοντέλα διαφέρουν πολύ ανάλογα με το αν η υπηρεσία προέρχεται από κάποιον εξυπηρέτη (server process) στον ίδιο χώρο διευθύνσεων με αυτόν του προγράμματος πελάτη (client process), με δυναμική σύνδεση dynamic linking, από μια ξεχωριστή διεργασία στον ίδιον υπολογιστή, από το λειτουργικό σύστημα, ή από έναν παροχέα που τρέχει σε διαφορετικό υπολογιστή (ή μια ομάδα ξεχωριστών υπολογιστών) στο δίκτυο. Επιπροσθέτως, ως αποτέλεσμα των τάσεων για μείωση του μεγέθους του hardware και αύξησης της πολυπλοκότητας του software, δημιουργείται η ανάγκη για ένα νέο στυλ προγραμματισμού που είναι αρθρωτό και βασίζεται στην αρχιτεκτονική πελάτη/εξυπηρέτη (client/server) και στα συστατικά (components) [41], [42]. Αυτό το στυλ απαιτεί: Δυνατότητες για την εύρεση και χρήση των παροχέων υπηρεσιών (server processes), για τη διαπραγμάτευση των υπηρεσιών με αυτούς και για την επέκταση και βελτίωση των παροχέων με ένα τρόπο που δεν θα αχρηστεύει τις ήδη υπάρχουσες Εκδόσεις των υπηρεσιών που μπορεί να έχουν οι καταναλωτές (client processes). Χρήση αντικειμενοστραφούς (object-oriented) αρχιτεκτονικής των υπηρεσιών και του συστήματος, για να ταιριάζουν καλύτερα με τα εργαλεία object-oriented ανάπτυξης νέας γενιάς, για να αντιμετωπίζεται η αυξανόμενη πολυπλοκότητα του λογισμικού μέσω της αύξησης της δυνατότητας άρθρωσης (modularity), για να επαναχρησιμοποιούνται ήδη υπάρχουσες λύσεις και για να διευκολύνεται η σχεδίαση πιο αυτόνομων συστατικών (components) λογισμικού. Κατανεμημένο σχεδιασμό για να παρέχεται μια μοναδική και διαφανής εικόνα στους χρήστες και τις εφαρμογές και για να επιτρέπεται η χρήση των υπηρεσιών σε ένα δικτυωμένο περιβάλλον ανεξάρτητα από την θέση, την αρχιτεκτονική ή το περιβάλλον υλοποίησης. Σαν παράδειγμα για την επεξήγηση των θεμάτων αυτών, μπορούμε να θεωρήσουμε το πρόβλημα της δημιουργίας ενός API (Application Programming Interface) μιας υπηρεσίας του συστήματος που λειτουργεί με πολλαπλούς παροχείς με έναν «πολυμορφικό» τρόπο. Αυτό σημαίνει ότι ένας πελάτης της υπηρεσίας μπορεί με διαφάνεια να χρησιμοποιήσει Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 17 από 163

18 οποιονδήποτε παροχέα της υπηρεσίας χωρίς να γνωρίζει ποιος συγκεκριμένος παροχέας ή υλοποίηση χρησιμοποιείται. Στα παραδοσιακά συστήματα υπάρχει ένα κεντρικό τμήμα κώδικα το οποίο καλείται από όλες τις εφαρμογές για να προσπελάσουν λειτουργίες όπως η επιλογή ενός αντικειμένου και η σύνδεση με αυτό. Στην ουσία ο διαχειριστής υπηρεσιών είναι ένα είδος «διαχειριστή αντικειμένων». Όμως, αφού οι εφαρμογές έχουν χρησιμοποιήσει αυτές τις λειτουργίες του διαχειριστή αντικειμένων και είναι συνδεδεμένες σε έναν παροχέα υπηρεσιών, ο διαχειριστής αντικειμένων απλά παραμένει ενεργός και επιβάλλει επιβάρυνση σε όλες τις εφαρμογές όπως φαίνεται στο Σχήμα 1. Δείκτης στη Διεπαφή Function1( ) { } Δείκτης Πίνακας διεπαφών των Συναρτήσεων (Functions) Δείκτης στην Function1 Δείκτης στην Function2 Δείκτης στην Function3 Function2( ) { } Function3( ) { } Σχήμα 1: Τα παραδοσιακά APIs υπηρεσιών συστήματος απαιτούν από όλες τις υπηρεσίες να επικοινωνούν μέσω ενός κεντρικού διαχειριστή με την αντίστοιχη επιβάρυνση (overhead). Εκτός από την επιβάρυνση που περιγράφηκε, ένα άλλο σημαντικό πρόβλημα με τα παραδοσιακά μοντέλα υπηρεσιών είναι ότι είναι αδύνατο για τον παροχέα να γνωστοποιήσει νέες, βελτιωμένες δυνατότητες στους πιθανούς χρήστες με έναν τυποποιημένο τρόπο. Μια καλά σχεδιασμένη παραδοσιακή αρχιτεκτονική υπηρεσίας μπορεί να παρέχει την έννοια των διαφορετικών επιπέδων υπηρεσίας (το Microsoft Open Database Connectivity (ODBC) είναι τέτοιο API). Οι εφαρμογές μπορούν να υπολογίζουν στο ελάχιστο επίπεδο υπηρεσίας και μπορούν να διαπιστώσουν κατά τη διάρκεια της εκτέλεσης αν ο παροχέας υποστηρίζει υψηλότερα επίπεδα υπηρεσίας, αλλά οι παροχείς είναι αναγκασμένοι να παρέχουν τα επίπεδα υπηρεσιών που καθορίζονται από το API. Δεν μπορούν να παράσχουν εύκολα νέες δυνατότητες και μετά να ειδοποιήσουν τους Σελίδα 18 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

19 καταναλωτές, ώστε να τις προσπελάσουν φθηνά και με έναν τρόπο που ταιριάζει με το τυπικό μοντέλο. Αν πάρουμε σαν παράδειγμα το ODBC, ο πωλητής ενός παροχέα βάσης δεδομένων που κάνει περισσότερα πράγματα από αυτά που επιτρέπει η τρέχουσα τυποποίηση ODBC, πρέπει να πείσει τη Microsoft να αναθεωρήσει το στάνταρ έτσι ώστε να υποστηρίζει τις πρόσθετες δυνατότητες του πωλητή. Έτσι, οι παραδοσιακές αρχιτεκτονικές υπηρεσιών δεν μπορούν εύκολα να επεκταθούν ή να συμπληρωθούν με έναν αποκεντρωμένο τρόπο. Οι παραδοσιακές αρχιτεκτονικές έχουν επίσης την τάση να είναι περιορισμένες ως προς την τάση να εξελίσσονται συμπαγώς καθώς οι υπηρεσίες αναθεωρούνται ή αλλάζουν έκδοση. Το πρόβλημα με την παραδοσιακή διαχείριση των εκδόσεων ενός λογισμικού με αυτόν τον τρόπο είναι το γεγονός ότι είναι δύσκολο για τον κώδικα να δείχνει πως ακριβώς διαφέρει από μια προηγούμενη έκδοση, και ακόμα χειρότερα, για τους πελάτες αυτού του κώδικα να προσαρμόζονται κατάλληλα στις νέες εκδόσεις ή να μην προσαρμόζονται καθόλου αν θέλουν να υποστηρίζουν μόνο την προηγούμενη έκδοση. Αυτό το πρόβλημα μπορεί να αντιμετωπιστεί λογικά σε ένα παραδοσιακό σύστημα όταν (i) υπάρχει μόνο ένας παροχέας μιας συγκεκριμένης υπηρεσίας, (ii) ο αριθμός της έκδοσης της υπηρεσίας ελέγχεται από τον καταναλωτή όταν δεσμεύεται με την υπηρεσία, (iii) η υπηρεσία επεκτείνεται με μόνο προς τα πίσω συμβατότητα για παράδειγμα, μπορούν μόνο να προστεθούν και ποτέ να αφαιρεθούν δυνατότητες (σημαντικός περιορισμός) έτσι ώστε ο παροχέας της έκδοσης Ν να μπορεί επίσης να λειτουργήσει με καταναλωτές της έκδοσης 1 έως Ν-1 και (iv) δεν μεταφέρονται από καταναλωτή σε καταναλωτή αναφορές σε ένα στιγμιότυπο μιας υπηρεσίας που τρέχει. Αλλά τέτοιοι περιορισμοί είναι προφανώς απαράδεκτοι σε ένα κατανεμημένο, αρθρωτό σύστημα με πολλαπλούς κατασκευαστές και πολυμορφικούς παροχείς υπηρεσιών. Αυτά τα προβλήματα της διαχείρισης των υπηρεσιών, της επεκτασιμότητας και της διαχείρισης των εκδόσεων προκαλούν και τα προβλήματα που αναφέρθηκαν παραπάνω. Η πολυπλοκότητα των εφαρμογών συνεχίζει να αυξάνεται καθώς γίνεται όλο και δυσκολότερο να επεκταθεί η λειτουργικότητα. Οι μονολιθικές εφαρμογές είναι δημοφιλείς επειδή είναι ασφαλέστερο και ευκολότερο να συγκεντρωθούν όλες οι συσχετιζόμενες υπηρεσίες και ο κώδικας που τις χρησιμοποιεί σε ένα πακέτο. Η διαλειτουργικότητα επίσης περιορίζεται καθώς οι μονολιθικές εφαρμογές δεν αφήνουν ανεξάρτητους agents να προσπελάσουν τη λειτουργικότητά τους. Πάντως, επειδή οι τελικοί χρήστες απαιτούν τη διαλειτουργικότητα, οι εφαρμογές αναγκάζονται να την επιχειρήσουν, και οδηγούνται απευθείας στο πρόβλημα της πολυπλοκότητας, κλείνοντας έναν φαύλο κύκλο προβλημάτων που περιορίζουν την πρόοδο της ανάπτυξης του λογισμικού Η προτεινόμενη λύση Το Πλαίσιο Σχεδιασμού και Ανάπτυξης Εφαρμογών «ΟΔΥΣΣΕΑΣ» έχει σκοπό να προσφέρει λύσεις στα προβλήματα που προαναφέρθηκαν. Στην ενότητα αυτή θα γίνει μια γενική περιγραφή και μια προκαταρκτική τεχνική προσέγγιση των λύσεων που προτείνονται από τον ΟΔΥΣΣΕΑ. Σύμφωνα με τους D Souza και Wills [43], «γενικά ένα πλαίσιο που βασίζεται σε συστατικά (components) είναι ένα μοντέλο συνεργασίας τμημάτων λογισμικού, όπου τα συστατικά είναι καθορισμένα σύμφωνα με κάποιες τυποποιημένες προδιαγραφές. Κάποια από αυτά μπορεί να έχουν τις υλοποιήσεις τους. Για να χρησιμοποιήσει κάποιος το πλαίσιο απλά συνδέει τις υλοποιήσεις των συστατικών που συμμορφώνονται με τις προδιαγραφές». Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 19 από 163

20 Η λύση που προτείνεται στοχεύει στο να έχει ένας κατασκευαστής τη δυνατότητα, αν τα προϊόντα του έχουν κάποια χρησιμότητα ως τμήματα ενός βοηθήματος επικοινωνίας, να κατασκευάζει λύσεις «συμβατές» με άλλα τμήματα λογισμικού που θα μπορούσαν σε συνδυασμό μεταξύ τους να αποτελέσουν ένα ολοκληρωμένο βοήθημα. Ο τρόπος για να γίνει αυτό είναι ο καθορισμός συγκεκριμένων προδιαγραφών συμβατότητας και αυστηρών οδηγιών. Αυτές οι προδιαγραφές και οι οδηγίες είναι είτε γενικές, που αφορούν για παράδειγμα στο λειτουργικό σύστημα με το οποίο θα είναι συμβατά τα επιμέρους τμήματα ενός βοηθήματος επικοινωνίας, είτε πιο ειδικές που αναφέρονται για παράδειγμα στον τρόπο επικοινωνίας των τμημάτων αυτών μεταξύ τους. Επίσης, προτείνεται ένας «χώρος» όπου ο κάθε ενδιαφερόμενος θα μπορούσε να πάρει τις πληροφορίες που χρειάζεται για την ανάπτυξη της εφαρμογής του. Εκεί θα είναι διαθέσιμες όλες οι τυποποιήσεις, οι προδιαγραφές και οι οδηγίες που χρησιμοποιούνται από τον ΟΔΥΣΣΕΑ και θα διευκολύνεται τεχνικά η ανάκτησή τους. Στον ίδιο χώρο βέβαια θα εκτίθενται και όλα τα ήδη έτοιμα και συμβατά με τον ΟΔΥΣΣΕΑ προϊόντα με κάθε πληροφορία για τις προδιαγραφές, τη λειτουργικότητα και τη χρήση τους. Ο ίδιος χώρος θα μπορούσε να χρησιμοποιηθεί και από τους κατασκευαστές που ενδιαφέρονται να αναπτύξουν ή να υποβάλλουν ήδη έτοιμα προϊόντα τους συμβατά με τον ΟΔΥΣΣΕΑ, αλλά και από τους χρήστες, είτε πρόκειται για τα ίδια τα ΑΜΑ είτε για τους θεραπευτές τους, που ενδιαφέρονται να μάθουν τι υπάρχει στην αγορά. Στην καλύτερη περίπτωση θα μπορούσαν οι χρήστες να συνθέσουν το προϊόν που τους ταιριάζει και να το παραγγείλουν κατευθείαν από το χώρο αυτό. Στην ουσία αυτός ο χώρος θα είναι ένας τόπος στο Διαδίκτυο, όπου οι τελικοί χρήστες και οι πωλητές Βοηθημάτων Διαπροσωπικής επικοινωνίας θα μπορούν εύκολα να ερευνούν τις δυνατότητες που προσφέρουν τα διαθέσιμα συστατικά (components) και οι κατασκευαστές να βρίσκουν οδηγίες και βοηθήματα για την ανάπτυξη των δικών τους συστατικών (components), αλλά και να είναι σε θέση να τα εκθέσουν. Επικεντρώνοντας πάλι το ενδιαφέρον στις τεχνικές προγραμματισμού, είναι γνωστό ότι ο αντικειμενοστραφής (object-oriented) προγραμματισμός έχει προταθεί ως λύση στα προβλήματα που μας απασχολούν. Όμως, ενώ ο object-oriented προγραμματισμός είναι ισχυρός, δεν είχε φτάσει μέχρι πρόσφατα στις πλήρεις δυνατότητές του, επειδή δεν υπήρχε τυποποιημένο ή κοινά αποδεκτό πλαίσιο μέσω του οποίου τα αντικείμενα λογισμικού (συστατικά) που έχουν δημιουργηθεί από διαφορετικούς κατασκευαστές να μπορούν να αλληλεπιδράσουν το ένα με το άλλο μέσα στον ίδιο χώρο διευθύνσεων, πόσο μάλλον μεταξύ διαφορετικών χώρων διευθύνσεων και μεταξύ συνόρων δικτύου και αρχιτεκτονικών. Το αποτέλεσμα της επανάστασης του object-oriented προγραμματισμού ήταν η παραγωγή «νησιών αντικειμένων» που δεν μπορούν να μιλήσουν μεταξύ τους με επιτυχία διαμέσου της θάλασσας των συνόρων των εφαρμογών. Η λύση είναι ένα σύστημα στο οποίο αυτοί που αναπτύσσουν τις εφαρμογές δημιουργούν επαναχρησιμοποιούμενα συστατικά λογισμικού. Ένα συστατικό (component) είναι ένα επαναχρησιμοποιούμενο τμήμα λογισμικού σε δυαδική μορφή το οποίο μπορεί να «προσκολληθεί» σε άλλα συστατικά από άλλους κατασκευαστές με σχετικά μικρή προσπάθεια. Για παράδειγμα, ένα συστατικό (component) θα μπορούσε εκτελεί μια διαδικασία ορθογραφικού ελέγχου που πωλείται από ένα κατασκευαστή και μπορεί να «προσκολληθεί» σε διάφορους επεξεργαστές κειμένου από διάφορους άλλους κατασκευαστές. Τα συστατικά λογισμικού πρέπει να υπακούουν σε μια εξωτερική δυαδική τυποποίηση, αλλά η εσωτερική τους υλοποίηση είναι εντελώς αδέσμευτη. Μπορούν να κατασκευαστούν χρησιμοποιώντας διαδικαστικές (procedural) γλώσσες όπως επίσης και Σελίδα 20 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

21 αντικειμενοστραφείς γλώσσες και πλαίσια, αν και οι τελευταίες παρουσιάζουν πολλά πλεονεκτήματα στον κόσμο των συστατικών λογισμικού. Τα συστατικά λογισμικού μοιάζουν αρκετά με τα συστατικά των ολοκληρωμένων κυκλωμάτων (integrated circuits IC) και το συστατικό λογισμικού είναι το ολοκληρωμένο κύκλωμα του αύριο. Η βιομηχανία λογισμικού σήμερα βρίσκεται εκεί που βρισκόταν η βιομηχανία hardware πριν από 20 χρόνια. Εκείνη την εποχή, οι κατασκευαστές ηλεκτρονικών μάθαιναν πως να συρρικνώνουν τα τρανζίστορ και να τα βάζουν σε πακέτα έτσι ώστε να μη ξαναχρειαστεί ποτέ κανείς να ανακαλύψει πως να κατασκευάσει μια διακριτή συνάρτηση για παράδειγμα μια πύλη NAND. Τέτοιες συναρτήσεις υλοποιούνταν μέσα σε ένα ολοκληρωμένο κύκλωμα, ένα απλό πακέτο που οι σχεδιαστές θα μπορούσαν εύκολα να το αγοράζουν και να σχεδιάζουν γύρω από αυτό. Καθώς οι hardware συναρτήσεις γίνονταν όλο και πιο πολύπλοκες, τα ICs ολοκληρωνόταν για να σχηματίσουν πλακέτες από τσιπ και να παρέχουν πιο πολύπλοκη λειτουργικότητα και αυξημένες δυνατότητες. Καθώς τα ολοκληρωμένα κυκλώματα γινόταν μικρότερα προσφέροντας ακόμα μεγαλύτερη λειτουργικότητα, οι πλακέτες από τσιπ γινόταν απλά μεγαλύτερα τσιπ. Έτσι τώρα η τεχνολογία του hardware χρησιμοποιεί τσιπ για να κατασκευάσει ακόμα μεγαλύτερα τσιπ. Η βιομηχανία του λογισμικού είναι τώρα σε ένα σημείο όπου οι κατασκευαστές λογισμικού απασχολήθηκαν για πολύ καιρό με την κατασκευή του λογισμικού που είναι ισοδύναμο με τα διακριτά τρανζίστορ ρουτίνες λογισμικού. Το μοντέλο συστατικών και αντικειμένων (Component Object Model) [7], [27], [35], επιτρέπει στους παροχείς λογισμικού να πακετάρουν τις συναρτήσεις τους σε επαναχρησιμοποιούμενα συστατικά λογισμικού με παρόμοιο τρόπο με τα ολοκληρωμένα κυκλώματα. Το μοντέλο και τα συστατικά του φέρνει το λογισμικό σε ένα κόσμο όπου ο κατασκευαστής λογισμικού δεν χρειάζεται πια να γράψει, για παράδειγμα, έναν αλγόριθμο ταξινόμησης. Ένας αλγόριθμος ταξινόμησης μπορεί να πακεταριστεί ως ένα δυαδικό αντικείμενο και να σταλεί στην αγορά των αντικειμένων συστατικών. Ο κατασκευαστής που χρειάζεται τον αλγόριθμο ταξινόμησης απλά χρησιμοποιεί οποιοδήποτε αντικείμενο ταξινόμησης οποιουδήποτε τύπου χρειάζεται χωρίς να ανησυχεί για το πως υλοποιήθηκε. Ο κατασκευαστής του αντικειμένου ταξινόμησης μπορεί να αποφύγει τις ενοχλήσεις και τα θέματα πνευματικής ιδιοκτησίας του κώδικα και να αφοσιωθεί στην παροχή της καλύτερης δυαδικής έκδοσης του αλγορίθμου ταξινόμησης. Όπως έγινε με τους κατασκευαστές hardware και τα ολοκληρωμένα κυκλώματα, έτσι και οι κατασκευαστές εφαρμογών δεν χρειάζεται να ανησυχούν για το πως θα κατασκευάσουν αυτήν την συνάρτηση. Μπορούν απλά να την αγοράσουν. Η κατάσταση είναι παρόμοια με την αγορά των ολοκληρωμένων κυκλωμάτων σήμερα: δεν μπορεί κανείς να αγοράσει τον «κώδικα» για το IC και να κατασκευάσει από μόνος του το IC. Το μοντέλο επιτρέπει την αγορά του συστατικού λογισμικού, όπως γίνεται η αγορά ενός ολοκληρωμένου κυκλώματος. Το συστατικό είναι συμβατό με οτιδήποτε κάποιος «προσκολλήσει» σε αυτό. Ενεργοποιώντας την ανάπτυξη των συστατικών λογισμικού, το μοντέλο COM (Component Object Model) παρέχει έναν πολύ πιο παραγωγικό τρόπο για τον σχεδιασμό, την κατασκευή, την πώληση, την χρήση και την επαναχρησιμοποίηση του λογισμικού. Τα συστατικά λογισμικού έχουν σημαντικές επιπτώσεις για τους πωλητές λογισμικού, τους χρήστες και τις εταιρίες: Οι κατασκευαστές εφαρμογών μπορούν να κατασκευάζουν και να διανέμουν εφαρμογές πιο εύκολα από πριν. Τα συστατικά παρέχουν και κλιμάκωση και άρθρωση Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 21 από 163

22 για την επαναχρησιμοποίηση του κώδικα. Ακόμα, οι κατασκευαστές μπορούν να επιτύχουν υψηλότερη απόδοση αφού μπορούν να μάθουν ένα σύστημα αντικειμένων για πολλές πλατφόρμες. Οι πωλητές έχουν ένα μοναδικό μοντέλο για την αλληλεπίδραση με άλλες εφαρμογές και το υπολογιστικό περιβάλλον. Ενώ τα συστατικά λογισμικού μπορούν να προστεθούν εύκολα σε ήδη υπάρχουσες εφαρμογές χωρίς να ξαναγραφτεί από τα θεμέλια και από την αρχή ο κώδικας, προσφέρουν επίσης την ευκαιρία να γίνουν οι εφαρμογές αρθρωτές και να αντικαθιστώνται αποσπασματικά δυνατότητες του συστήματος όπου αυτό χρειάζεται. Οι τελικοί χρήστες θα έχουν μια πολύ μεγαλύτερη ποικιλία επιλογών λογισμικού, και ταυτόχρονα μεγαλύτερη αποδοτικότητα. Θα έχουν πρόσβαση σε εκατοντάδες αντικειμένων μέσα από πλατφόρμες client/server. Αυτά τα αντικείμενα θα έχουν από πριν κατασκευαστεί από ανεξάρτητους πωλητές λογισμικού και εταιρίες. Ακόμα, καθώς οι χρήστες θα συνειδητοποιούν τις δυνατότητες των συστατικών λογισμικού, είναι πολύ πιθανό να αυξηθεί η ζήτηση για εξειδικευμένα συστατικά που μπορούν να αγοραστούν σε τοπικά καταστήματα και να «προσκολληθούν» σε εφαρμογές Πλαίσια ανάπτυξης εφαρμογών Γεννήτριες εφαρμογών Η μία προσέγγιση στον ΟΔΥΣΣΕΑ θα μπορούσε να είναι αυτή της γεννήτριας εφαρμογών. Πρόκειται για ένα ολοκληρωμένο περιβάλλον ανάπτυξης εφαρμογών με λειτουργικότητα που μπορεί να αντικαταστήσει πολλές από τις προγραμματιστικές δραστηριότητες. Τα πλεονεκτήματα της προσέγγισης αυτής είναι η δραματική μείωση του χρόνου και της πολυπλοκότητας ανάπτυξης μιας εφαρμογής και η βεβαιότητα ότι όλες οι εφαρμογές που αναπτύσσονται με αυτόν τον τρόπο θα είναι συμβατές με ό,τι συστήματα υποστηρίζει η γεννήτρια. Μια τέτοια εφαρμογή θα μπορούσε να αποτελεί ένα γραφικό περιβάλλον ανάπτυξης εφαρμογών με δυνατότητα να δημιουργεί κώδικα για πολλαπλές πλατφόρμες ή σε πολλές γλώσσες. Τα μειονεκτήματα είναι ότι οι ανεξάρτητοι κατασκευαστές περιορίζονται αρκετά στα προϊόντα που μπορούν να αναπτύξουν τόσο από την πλευρά της διεπαφής χρήσης, όσο και από την πλευρά της λειτουργικότητας. Επίσης, είναι δύσκολο οι κατασκευαστές να πειστούν ώστε να χρησιμοποιούν συγκεκριμένο εργαλείο ανάπτυξης των εφαρμογών τους μια και οι περισσότεροι έχουν ήδη έναν τρόπο ανάπτυξης με τα εργαλεία που τους βολεύουν. Εξάλλου, ο χρόνος και οι αναγκαίοι πόροι για την κατασκευή μιας τέτοιας γεννήτριας εφαρμογών θα ήταν πολύ μεγάλοι. Ως γεννήτρια εφαρμογών μπορεί να θεωρηθεί το σύστημα Comspec [23], [24]. Πρόκειται για ένα περιβάλλον κατασκευής Βοηθημάτων Επικοινωνίας για άτομα με αναπηρίες. Βασίζεται σε μια γενική σχεδίαση για το πώς πρέπει να είναι ένα Βοήθημα Επικοινωνίας και σε μια ποικιλία από συστατικά που μπορούν να το αποτελούν. Τα συστατικά που υποστηρίζει το Comspec είναι αυτά που το ίδιο το πρόγραμμα περιλαμβάνει, μια και είναι αρκετά δύσκολο για τρίτους κατασκευαστές να αναπτύξουν δικά τους συστατικά που μπορούν να ενσωματωθούν στο Comspec. Η φιλοσοφία της εφαρμογής είναι η χρησιμοποίηση έτοιμων απλών εικονικών πληκτρολογίων ως βάση για την ανάπτυξη πιο σύνθετων Βοηθημάτων προσθέτοντας στοιχεία που είναι διαθέσιμα σε μπάρες εργαλείων, όπως κουμπιά, πλαίσια κειμένου, συσκευές εισόδου/εξόδου κτλ. Το Comspec λειτουργεί σε 16μπιτες εκδόσεις των Windows και η διεπαφή χρήσης του είναι η τυπική μιας εφαρμογής που τρέχει σε αυτό το λειτουργικό σύστημα με τα παράθυρα, τα πλαίσια Σελίδα 22 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

23 διαλόγου, τα κουμπιά τα πλαίσια κειμένου και όλα τα τυπικά στοιχεία ελέγχου. Το Comspec αν και είναι πολύ εύκολο στη χρήση και έχει πολλές δυνατότητες παραμετροποίησης των Βοηθημάτων που κατασκευάζονται με αυτό, χαρακτηρίζεται από τα μειονεκτήματα που αναφέραμε και αφορούν στον περιορισμό των χρηστών του ως προς την ποικιλία και τον πλήρη έλεγχο στις εφαρμογές που μπορούν να κατασκευάσουν. Φυσικά θα μπορούσε κανείς να κατασκευάσει σχεδόν οποιασδήποτε μορφής Βοήθημα Επικοινωνίας χρησιμοποιώντας μια άλλη εφαρμογή που μπορεί επίσης να θεωρηθεί ως γεννήτρια εφαρμογών. Η πολύ γνωστή Microsoft Visual Basic [56] συχνά αναφέρεται ως εργαλείο προγραμματισμού και άλλοτε ως γεννήτρια εφαρμογών. Πρόκειται για μια γλώσσα προγραμματισμού υψηλού επιπέδου, ώστε να μπορούμε να την κατατάξουμε στην κατηγορία των πακέτων λογισμικού που μας απασχολεί εδώ. Με ένα τόσο ισχυρό εργαλείο θα μπορούσε κανείς να επιτύχει οποιαδήποτε χαρακτηριστικά και προδιαγραφές έβαζε ως στόχο για ένα Βοήθημα Επικοινωνίας, αλλά είναι επίσης φανερό πως δεν είναι εφικτό να κινηθούμε προς μια τέτοια κατεύθυνση επειδή έστω και μια απλοποιημένη μορφή, εστιασμένη στα Βοηθήματα Επικοινωνίας ενός τέτοιου πακέτου λογισμικού απαιτεί χρόνια συντονισμένης δουλειάς εκατοντάδων ανθρώπων για την υλοποίησή της Τυποποιήσεις, οδηγίες και τεχνικές προγραμματισμού Μια δεύτερη προσέγγιση είναι η υιοθέτηση συγκεκριμένων τεχνικών αντικειμενοστραφούς προγραμματισμού και η πρόταση ειδικών προδιαγραφών, τυποποιήσεων και οδηγιών για τη δημιουργία προϊόντων λογισμικού επαναχρησιμοποιήσιμων και συμβατών μεταξύ τους, ανεξάρτητα από τις γλώσσες προγραμματισμού, τα εργαλεία και τις πλατφόρμες που χρησιμοποιούνται για την ανάπτυξή τους. Αυτή η προσέγγιση απαιτεί την προσεκτική μελέτη όλων των διαθέσιμων τυποποιήσεων και τεχνολογιών για την ανάπτυξη εφαρμογών και την απόφαση για το ποιες από αυτές θα υποστηριχθούν. Επίσης, περιλαμβάνει τη ανάπτυξη νέων τυποποιήσεων και οδηγιών σε τομείς που δεν καλύπτονται από τις ήδη υπάρχουσες. Το αποτέλεσμα είναι ένα θεωρητικό περιβάλλον ανάπτυξης και όχι μια γεννήτρια εφαρμογών υλοποιημένη με λογισμικό. Οι ανεξάρτητοι προγραμματιστές θα έχουν την ελευθερία να χρησιμοποιήσουν τα εργαλεία ανάπτυξης εφαρμογών που προτιμούν, αρκεί οι εφαρμογές που δημιουργούνται να πληρούν τις προδιαγραφές του πλαισίου και η ανάπτυξη να συμμορφώνεται με τις αυστηρές οδηγίες που αναφέρονται στη συμβατότητα και στην ενσωμάτωση των εφαρμογών σε ένα ολοκληρωμένο βοήθημα επικοινωνίας. Έτσι ο κώδικας που αναπτύσσεται για τη δημιουργία ενός τμήματος μιας εφαρμογής θα μπορεί να ξαναχρησιμοποιείται και σε άλλες εφαρμογές και δεν θα απαιτείται οι ίδιες λειτουργικότητες να ξανασχεδιάζονται και να αναπτύσσονται από την αρχή για κάθε νέα ολοκληρωμένη εφαρμογή που τις χρειάζεται. Μια τέτοια προσέγγιση υλοποιήθηκε στα πλαίσια του έργου ACCESS [15], [16], [17], [18], [19], [20], [21], [22] και της αρχιτεκτονικής ATIC που προέκυψε από αυτό. Το πλαίσιο βασιζόταν στην υιοθέτηση τεχνικών προγραμματισμού βασισμένων στα συστατικά και τα αντικείμενα. Περιελάμβανε ένα αυτοσχέδιο (proprietary) πρωτόκολλο επικοινωνίας μεταξύ των συστατικών, έναν επίσης αυτοσχέδιο Διαχειριστή μηνυμάτων που λειτουργούσε ως μεσάζοντας και συντονιστής της επικοινωνίας αυτής και ένα σύνολο ρουτινών και βιβλιοθηκών για χρήση από τους προγραμματιστές και διευκόλυνση της διαδικασίας υλοποίησης Βοηθημάτων Επικοινωνίας. Επίσης, αναπτύχθηκαν κάποια εργαλεία για υποβοήθηση της αποσφαλμάτωσης και της συντήρησης συστατικών που ήταν συμβατά με την αρχιτεκτονική ATIC. Τέλος, αυτή η αρχιτεκτονική βασιζόταν στην υποδομή των 16μπιτων εκδόσεων του λειτουργικού συστήματος των Windows και στις Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 23 από 163

24 υπηρεσίες Μηνυμάτων Παραθύρων (Windows Messaging) που προσέφεραν. Αυτή είναι η φιλοσοφία πλαισίου ανάπτυξης εφαρμογών που θα ακολουθηθεί και στην παρούσα εργασία. Βέβαια, στόχος εδώ είναι η υποστήριξη πιο νέων τεχνολογιών, νέων λειτουργικών συστημάτων, αποφυγή μεγάλου όγκου αυτοσχέδιων τυποποιήσεων και υλοποιήσεων και μεγαλύτερη διευκόλυνση των κατασκευαστών από την άποψη του όγκου των πληροφοριών που θα πρέπει να γνωρίζουν και να χρησιμοποιούν για να κατασκευάζουν συστατικά συμβατά με το πλαίσιο. Επίσης, ο ΟΔΥΣΣΕΑΣ θα προτείνει έναν λίγο διαφοροποιημένο κύκλο ζωής των προϊόντων από αυτόν που πρότεινε η αρχιτεκτονική ATIC και θα έχει τις υπηρεσίες του λειτουργικού συστήματος στη θέση του αυτοσχέδιου Διαχειριστή Μηνυμάτων που ήταν και η καρδιά της αρχιτεκτονικής αυτής Γενικά Χαρακτηριστικά του "ΟΔΥΣΣΕΑ" Διαλειτουργικότητα Τα επιμέρους συστατικά που μπορούν να συμμορφωθούν με το πλαίσιο ΟΔΥΣΣΕΑΣ θα πρέπει να συνεργάζονται μεταξύ τους ώστε να προκύπτουν μεγαλύτερα και πιο ολοκληρωμένα βοηθήματα επικοινωνίας που να χρησιμοποιούν τμήματα ανεπτυγμένα ακόμη και από διαφορετικούς κατασκευαστές. Αρθρωτή σχεδίαση Η φιλοσοφία ανάπτυξης εφαρμογών για ΑΜΑ θα πρέπει να βασίζεται στην κατάτμησή τους σε μικρότερα κομμάτια που θα μπορούν ανεξάρτητα και ευκολότερα να τροποποιηθούν και να συντηρηθούν χωρίς να απαιτείται σε κάθε αλλαγή των απαιτήσεων από την αρχή ανάπτυξη όλης της εφαρμογής. Τα κομμάτια αυτά θα πρέπει να έχουν όσο το δυνατό μεγαλύτερη αυτονομία ώστε να προσφέρουν τον μεγαλύτερο βαθμό επαναχρησιμοποίησης και ευελιξίας. Με βάση τα συστατικά (component based) Η επέκταση και το αποτέλεσμα της αρθρωτής σχεδίασης μιας εφαρμογής οδηγεί στον προγραμματισμό με βάση τα συστατικά, στα πλαίσια του οποίου αναπτύσσονται τμήματα της εφαρμογής τα οποία είναι εντελώς αυτόνομα, μπορούν να χρησιμοποιηθούν και από άλλες εφαρμογές και το κάθε ένα από αυτά συμμορφώνεται ξεχωριστά με τις επιθυμητές προδιαγραφές. Επεκτασιμότητα Ως αποτέλεσμα των παραπάνω ικανοποιείται και η απαίτηση της επεκτασιμότητας των τελικών προϊόντων με βάση την ανεξαρτησία των συστατικών τους από το ολοκληρωμένο βοήθημα επικοινωνίας και της δυνατότητας πλήρους αντικατάστασής τους με άλλα παρεμφερή. Έτσι το τελικό προϊόν θα μπορεί να είναι πολύ ευέλικτο και παραμετροποιήσιμο, ανάλογα με τα διαθέσιμα συστατικά και τις απαιτήσεις των χρηστών. Πάνω από όλα, το βοήθημα επικοινωνίας θα μπορεί να δέχεται τροποποιήσεις και επεκτάσεις και να συμβαδίζει ακόμα και με μεταβαλλόμενες απαιτήσεις, με το μικρότερο δυνατό κόστος σε πολυπλοκότητα και χρόνο. Ανεξαρτησία από γλώσσα προγραμματισμού Αυτό το χαρακτηριστικό μπορεί να υποστηριχθεί μέχρι κάποιο βαθμό από το πλαίσιο ΟΔΥΣΣΕΑΣ και με βάση τα προηγούμενα χαρακτηριστικά, αρκεί η επιλεγμένη από κάθε προγραμματιστή γλώσσα να υποστηρίζει τις τεχνολογίες που θα απαιτούνται για τη λειτουργία μιας εφαρμογής συμβατής με το πλαίσιο αυτό. Στόχος είναι να επιλεχθούν οι Σελίδα 24 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

25 τεχνολογίες αυτές που υποστηρίζονται στο παρόν από τις περισσότερες γλώσσες προγραμματισμού έχοντας βέβαια υπόψη και την παράμετρο της μελλοντικής επιτυχίας και επικράτησης των τεχνολογιών αυτών στο βαθμό που κάτι τέτοιο είναι δυνατόν να προβλεφθεί Μεθοδολογία Ανάπτυξης του ΟΔΥΣΣΕΑ Μια γενική περιγραφή του προκαταρκτικού σχεδιασμού του Πλαισίου Σχεδιασμού και Ανάπτυξης Βοηθημάτων Διαπροσωπικής Επικοινωνίας ΟΔΥΣΣΕΑΣ εστιάζεται στους εξής άξονες: Τυποποιήσεις Οδηγίες Λογισμικό υποβοήθησης υλοποίησης συστατικών Λογισμικό σύνδεσης συστατικών Ολοκλήρωση Διεπαφή χρήσης Υποστήριξη Διαδικτύου Αυτοί οι άξονες αντιπροσωπεύουν μια κατηγοριοποίηση των χαρακτηριστικών του πλαισίου ΟΔΥΣΣΕΑ και της υλοποίησής του ή διαφορετικές γωνίες από τις οποίες πρέπει να αντιμετωπιστεί το πλαίσιο και αναλύονται στη συνέχεια. Οι λεπτομέρειες του σχεδιασμού παρουσιάζονται στο έβδομο κεφάλαιο, αφού αναλυθούν οι τεχνολογίες και η υποδομή που πρόκειται να χρησιμοποιηθεί Τυποποιήσεις Οδηγίες Η ανάπτυξη του ΟΔΥΣΣΕΑ θα γίνει σε πλατφόρμα Microsoft Windows Θα χρησιμοποιηθούν εργαλεία ανάπτυξης εφαρμογών (τοπικών εφαρμογών desktop και εφαρμογών για το Διαδίκτυο) της Microsoft όπως: Microsoft Visual C++ 6.0, Microsoft Visual Basic 6.0, Microsoft Visual Modeler, Microsoft SQL Server, Microsoft Internet Information Server. Οι τεχνολογίες που θα χρησιμοποιηθούν περιλαμβάνουν τον προγραμματισμό με βάση τα συστατικά που προτείνει και χρησιμοποιεί η Microsoft, όπως Microsoft Windows DNA-based Applications on Windows 2000, COM+, Queued Components, System Events, Data Access Components, ADO, OLE-DB, Active Server Pages, Dynamic HTML, XML. Είναι δυνατόν να χρησιμοποιηθούν και τεχνολογίες της Sun Microsystems, όπως Java, Java Beans, Java Applets. Όσον αφορά τα συστατικά του ΟΔΥΣΣΕΑ, δεν καθορίζεται συγκεκριμένη γλώσσα ή πλατφόρμα ανάπτυξης, αλλά ο βασικός όρος είναι να είναι συμβατά με τα Windows Επίσης, όλες οι τεχνολογίες που αναφέρθηκαν παραπάνω για την ανάπτυξη του ΟΔΥΣΣΕΑ θα μπορούν να χρησιμοποιηθούν και να υποστηριχθούν και από τα συστατικά του. Φυσικά θα υπάρχουν αυστηρές οδηγίες και προδιαγραφές για την κατασκευή κάθε συστατικού ξεχωριστά. Βασικός στόχος είναι τα συστατικά να συνεργάζονται μεταξύ τους Λογισμικό υποβοήθησης υλοποίησης συστατικών Θα αποφευχθεί η φιλοσοφία της γεννήτριας εφαρμογών ή του υλοποιημένου σε λογισμικό περιβάλλοντος ανάπτυξης. Δεν θα δημιουργείται από αυτό το επίπεδο κώδικας διαφορετικός από τον πηγαίο κώδικα κάθε συστατικού, αλλά θα προτιμηθεί η προσέγγιση της εφαρμογής που βοηθά τον κατασκευαστή να βρει τις σωστές οδηγίες (guidelines) και Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 25 από 163

26 προδιαγραφές (specifications) που χρειάζεται για την κατασκευή ή την προσαρμογή του συστατικού του στα πλαίσια του ΟΔΥΣΣΕΑ. Θα προσφέρονται τμήματα λογισμικού, τα οποία θα μπορούν να ενσωματωθούν σε οποιοδήποτε συστατικό κατασκευάζεται ώστε να διευκολύνεται ή να αυτοματοποιείται η διαδικασία ένταξής του στο ολοκληρωμένο Βοήθημα Επικοινωνίας. Στην ουσία θα είναι έτοιμα πρότυπα συστατικά του πλαισίου ΟΔΥΣΣΕΑΣ με χαρακτηριστικές ιδιότητες και χαρακτηριστικά. Έχοντας στα χέρια τους αυτά τα συστατικά οι κατασκευαστές θα έχουν υλοποιημένα παραδείγματα, αλλά και έτοιμο κώδικα που μπορεί να επαναχρησιμοποιηθεί σε δικά τους συστατικά Λογισμικό σύνδεσης συστατικών Αυτό το σημείο είναι και το πιο σημαντικό και πολύπλοκο για το πλαίσιο ΟΔΥΣΣΕΑΣ. Η επιθυμητή κατάσταση βέβαια θα ήταν όλα τα έτοιμα συστατικά να μπορούν να διασυνδεθούν άμεσα, εφόσον βέβαια οι συγκεκριμένες συνδέσεις των συγκεκριμένων συστατικών προβλέπονται από τον ΟΔΥΣΣΕΑ. Το επιθυμητό είναι να γίνεται απλά και αυτόματα η διαδικασία χωρίς καμία παρέμβαση. Μια λύση θα μπορούσε να είναι η κατασκευή «πρακτόρων» (agents) που θα διασυνδέουν τα συστατικά σε επίπεδο κώδικα ή σε υψηλότερο επίπεδο χρησιμοποιώντας και το registry του λειτουργικού. Παρεμφερής λύση είναι η κατασκευή message centers που θα αποκαθιστούν της επικοινωνία των συστατικών μέσω ειδικών πρωτοκόλλων και οδών που θα καθορίζονται από τον ΟΔΥΣΣΕΑ και θα χρησιμοποιούν ειδικά αρχεία ρυθμίσεων για τα συστατικά, φτιαγμένα ειδικά για τις προδιαγραφές του ΟΔΥΣΣΕΑ. Η λύση που θα έλυνε περισσότερα προβλήματα σε λιγότερο χρόνο και με μικρότερη πολυπλοκότητα φαίνεται όμως να είναι αυτή της χρήσης των Windows APIs ή του των υπηρεσιών του λειτουργικού συστήματος για την επικοινωνία και σύνδεση των συστατικών. Μία εφαρμογή που θα μπορούσε να εκμεταλλευτεί έξυπνα τις κατάλληλες υπηρεσίες θα μπορούσε χωρίς να παρεμβαίνει στη λειτουργία του βοηθήματος και χωρίς να περιορίζει τους προγραμματιστές των συστατικών να ενεργοποιεί και να συντονίζει ομαλά τα συστατικά και τις λειτουργίες τους Ολοκλήρωση user interface Όσον αφορά τη Διεπαφή Χρήστη του ΟΔΥΣΣΕΑ, αυτή μπορεί να υλοποιηθεί σε πολλά επίπεδα, ανάλογα με τη λειτουργικότητα του πλαισίου. Αν επιλεγεί το πλαίσιο να είναι προσβάσιμο από το Διαδίκτυο, η διεπαφή χρήστη θα είναι ο browser. Ο browser μπορεί να χρησιμοποιηθεί ως Διεπαφή Χρήστη ακόμη και στην περίπτωση που δεν μεσολαβεί το Διαδίκτυο στην αλληλεπίδραση με το πλαίσιο ΟΔΥΣΣΕΑΣ. Οι σελίδες HTML σε όλες τις μορφές τους (από την απλή text HTML έως και τις Active Server Pages) είναι ένα βολικό User Interface από την άποψη ότι είναι ανεξάρτητο πλατφόρμας, εύκολα μεταφέρσιμο, ομοιογενές και συνεπές από τη φύση του και υποστηρίζει τοπική ή δικτυακή αλληλεπίδραση. Πρέπει εδώ να σημειωθεί ότι δεν μιλάμε για τη διεπαφή χρήσης των προϊόντων, δηλαδή των Βοηθημάτων Επικοινωνίας, αλλά για αυτή του πλαισίου που θα χρησιμοποιείται για την κατασκευή τους. Η τελική μορφή του Οδυσσέα μπορεί να περιλαμβάνει στην ιδεατή περίπτωση όλα τα παραπάνω, αλλά ρεαλιστικά, μόνο τμήματα του παραπάνω σχεδιασμού θα μπορούσαν να υλοποιηθούν. Στόχος είναι τα λειτουργικά επίπεδα του πλαισίου ΟΔΥΣΣΕΑΣ να λειτουργούν σωστά και να συνεργάζονται αρμονικά μεταξύ τους ώστε και να έχουμε τα επιθυμητά αποτελέσματα στη σύνδεση και λειτουργία των υποστηριζόμενων συστατικών. Στην ιδανική περίπτωση η διεπαφή χρήσης του ΟΔΥΣΣΕΑ θα πρέπει να είναι ανύπαρκτη! Σελίδα 26 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

27 Δεν είναι για κάποιο λόγο αναγκαία η πολυπλοκότητα που θα επέβαλε μια ακόμα διεπαφή χρήστη. Ένα έξυπνα και σωστά σχεδιασμένο σύστημα θα μπορούσε να λειτουργεί στο παρασκήνιο χωρίς να αποσπά την προσοχή ούτε του προγραμματιστή ούτε του τελικού βέβαια χρήστη. Η προσέγγιση που τελικά ακολουθείται έχει στόχο τη δημιουργία λογισμικού τόσο συμπαγούς και διάφανου σαν να αποτελεί και αυτό μια ακόμα υπηρεσία του λειτουργικού συστήματος που ο καθένας μπορεί να χρησιμοποιήσει χωρίς να χρειάζεται να μάθει κάτι περισσότερο Υποστήριξη Διαδικτύου Η υποστήριξη του Διαδικτύου από το πλαίσιο ΟΔΥΣΣΕΑΣ είναι μία από τις απαιτήσεις μας. Το θέμα εδώ είναι έως ποιο βάθος θα υποστηρίζεται η λειτουργία του ΟΔΥΣΣΕΑ μέσα από το Internet. Από τη μια πλευρά θα μπορούσε ο ΟΔΥΣΣΕΑΣ να είναι μια καθαρά κατανεμημένη και προσβάσιμη μόνο από το Διαδίκτυο οντότητα, που θα περιλαμβάνει βάσεις δεδομένων με πληροφορίες για τυποποιήσεις και guidelines, με όλα τα διαθέσιμα συστατικά και τις προδιαγραφές τους, με Ιδρύματα και Χρήστες βοηθημάτων επικοινωνίας. Σε αυτόν θα μπορούσαν επίσης να ενσωματωθούν εγγενή συστατικά όπως βάσεις δεδομένων γλωσσών, συμβόλων, γραμματοσειρών, εικόνων πολυμέσων, εκπαιδευτικού υλικού ή υλικού αναφοράς, λεξικών κτλ. Η λειτουργικότητά του θα μπορούσε να περιλαμβάνει την υποστήριξη τεχνικών υπερκειμένου, αναζήτησης πληροφοριών και δεδομένων, πλοήγηση μέσω Internet στον κόσμο των βοηθημάτων επικοινωνίας, σχεσιακούς δεσμούς μεταξύ όλων των στοιχείων και δεδομένων του, διαδικασίες πολύπλοκων ερωτημάτων και απλών ανακτήσεων δεδομένων από τις σχεσιακές βάσεις, μηχανισμούς σύνδεσης συστατικών και σύνθεσης βοηθημάτων έστω και σε επίπεδο συστάσεων και προτάσεων. Η λειτουργικότητα ενός τέτοιου μοντέλου περιορίζεται μόνο από τις δυνατότητες των εργαλείων προγραμματισμού και των υπολογιστών. Από την άλλη πλευρά στα πλαίσια της παρούσας εργασίας θα πρέπει να γίνουν κάποιοι συμβιβασμοί στα πλαίσια του διαθέσιμου χρόνου και πόρων, ώστε ο ΟΔΥΣΣΕΑΣ να προσφέρει όσο το δυνατό περισσότερα με όσο το δυνατό λιγότερη πολυπλοκότητα και προγραμματισμό. Έτσι η Υποστήριξη του Διαδικτύου θα μπορούσε στην πιο ρεαλιστική περίπτωση να περιλαμβάνει απλά τη διαθεσιμότητα των προδιαγραφών των τυποποιήσεων και των οδηγιών του ΟΔΥΣΣΕΑ προς τους κατασκευαστές των συστατικών μέσα από το Int ernet σε μορφή υπερκειμένου. Τέλος είναι πολύ σημαντικό το πλαίσιο να σχεδιαστεί έτσι, ώστε η υποστήριξη του Διαδικτύου από τις λειτουργίες του και τις δυνατότητές του να είναι εγγενής. Δεν πρόκειται να υιοθετηθεί η προσέγγιση της επέκτασης του πλαισίου για υποστήριξη του Διαδικτύου, αλλά ο εξαρχής σχεδιασμός του ώστε να περιλαμβάνει όλες τις απαραίτητες τυποποιήσεις και χαρακτηριστικά ώστε η υποστήριξη του Διαδικτύου να είναι ενσωματωμένη. Για παράδειγμα ο τρόπος και η διαδικασία ενσωμάτωσης στο Βοήθημα Επικοινωνίας ενός συστατικού που θα στέλνει μηνύματα ηλεκτρονικού ταχυδρομείου ( ) μέσω του Διαδικτύου δεν θα πρέπει να διαφέρει δραματικά από την εγκατάσταση ενός συστατικού που λειτουργεί αποκλειστικά σε τοπικό επίπεδο. Στη συνέχεια θα αναλυθούν κάποιες τεχνολογίες που μελετήθηκαν και επιλέχθηκαν ώστε να αποτελέσουν την υποδομή του πλαισίου ΟΔΥΣΣΕΑ. Στο κεφάλαιο 7 θα δοθούν Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 27 από 163

28 περισσότερες λεπτομέρειες για τον τελικό σχεδιασμό του πλαισίου αφού αναφερθούν όλες οι τεχνικές υποδομές που χρησιμοποιούνται και αποτελούν τη βάση του πλαισίου. Σελίδα 28 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

29 3. Επικοινωνία μεταξύ Διεργασιών Ένα πολύ σημαντικό θέμα που πρέπει να λύσει ο ΟΔΥΣΣΕΑΣ είναι αυτό της επικοινωνίας μεταξύ των συστατικών. Κάτι που στο παρελθόν έγινε από το έργο ACCESS [15], [16], [17], [18], [19], [20], [21], [22] με την αρχιτεκτονική και τα πρωτόκολλα επικοινωνίας του ATIC πρέπει τώρα να βελτιωθεί και να προσαρμοστεί στις τεχνολογίες αιχμής στο χώρο της πληροφορικής. Όπως ήδη αναφέρθηκε, το αδύνατο σημείο του ATIC ήταν ότι απαιτείτο η παρουσία ενός αυτοσχέδιου Διαχειριστή Μηνυμάτων αλλά και ενός αυτοσχέδιου πρωτοκόλλου επικοινωνίας μεταξύ των συστατικών, δύο στοιχεία που επέβαλλαν σοβαρό overhead στην εφαρμογή που θα βασιζόταν σε αυτά, και σοβαρούς περιορισμούς στους υποψήφιους κατασκευαστές συστατικών για Βοηθήματα Διαπροσωπικής Επικοινωνίας. Το λεπτό σημείο του σχεδιασμού είναι ότι πρέπει να υποστηρίζεται και να υλοποιείται η επικοινωνία μεταξύ συστατικών τα οποία δεν γνωρίζουν τίποτα το ένα για το άλλο και φυσικά δεν έχουν το στη διάθεσή τους προγραμματιστικούς δείκτες ή αναφορές το ένα για το άλλο. Θα πρέπει λοιπόν να παρεμβληθεί κάποια οντότητα που να συντονίζει και να διαχειρίζεται την κυκλοφορία των δεδομένων μεταξύ των συστατικών και για να αποφευχθεί η λύση του αυτοσχέδιου Διαχειριστή Μηνυμάτων θα πρέπει να γίνει σωστή και αποτελεσματική εκμετάλλευση των υπηρεσιών του συστήματος που μπορούν να καλύψουν αυτές τις ανάγκες. Το Microsoft Win32 API παρέχει μηχανισμούς για τη διευκόλυνση της επικοινωνίας και του διαμοιρασμού δεδομένων μεταξύ των εφαρμογών. Συνολικά, οι δραστηριότητες που ενεργοποιούνται από αυτούς τους μηχανισμούς καλούνται επικοινωνίες μεταξύ διεργασιών (inter-process communications IPC) [34]. Συνήθως, οι εφαρμογές μπορούν να χρησιμοποιήσουν IPCs κατηγοριοποιημένες σε πελάτες (clients) και εξυπηρέτες (servers). Πελάτης είναι μια εφαρμογή ή μια διεργασία η οποία ζητάει μια υπηρεσία από κάποια άλλη εφαρμογή ή διεργασία. Εξυπηρέτης είναι μια εφαρμογή η διεργασία που απαντά σε μία αίτηση του πελάτη. Από το Win32 API υποστηρίζονται οι παρακάτω μηχανισμοί IPC: Clipboard OLE/COM DDE File Mapping Mailslots Pipes RPC Windows Sockets WM_COPYDATA Όλοι αυτοί οι μηχανισμοί [31], [32], [33] περιγράφονται με συντομία στη συνέχεια. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 29 από 163

30 3.1. Clipboard Το Clipboard παίζει το ρόλο μιας κεντρικής προσωρινής αποθήκης για το διαμοιρασμό δεδομένων μεταξύ εφαρμογών [32]. Όταν ένας χρήστης πραγματοποιεί μια αποκοπή ή αντιγραφή (cut or copy) σε μια εφαρμογή, η εφαρμογή βάζει τα επιλεγμένα δεδομένα στο clipboard σε μία ή περισσότερες τυπικές ή προσαρμοσμένες στην εφαρμογή μορφές (formats). Οποιαδήποτε άλλη εφαρμογή μπορεί να ανακτήσει αυτά τα δεδομένα από το clipboard, επιλέγοντας από τις διαθέσιμες μορφές που καταλαβαίνει. Το Clipboard είναι ένα πολύ χαλαρά συνδεδεμένο (loosely coupled) μέσο συναλλαγής, όπου οι εφαρμογές χρειάζεται μόνο να συμφωνούν στον τύπο των δεδομένων. Οι εφαρμογές μπορούν να βρίσκονται στον ίδιο υπολογιστή ή σε διαφορετικούς υπολογιστές σε ένα δίκτυο. Βέβαια η χρήση προγραμματιστικά του Clipboard καταλήγει σε πολύ χαμηλή απόδοση της εφαρμογής COM Οι εφαρμογές που χρησιμοποιούν OLE διαχειρίζονται μικτά έγγραφα (compound documents) [32] δηλαδή, έγγραφα που αποτελούνται από δεδομένα από διαφορετικές εφαρμογές. Το OLE έχει υπηρεσίες που διευκολύνουν τις εφαρμογές να καλέσουν άλλες εφαρμογές για επεξεργασία δεδομένων. Για παράδειγμα, ένας επεξεργαστής κειμένου που χρησιμοποιεί OLE θα μπορούσε να ενσωματώσει ένα γράφημα από μια εφαρμογή λογιστικού φύλλου. Ο χρήστης θα μπορούσε να ξεκινήσει το λογιστικό φύλλο αυτόματα μέσα από τον επεξεργαστή κειμένου επιλέγοντας το ενσωματωμένο γράφημα για επεξεργασία. Το OLE αναλαμβάνει την εκκίνηση του λογιστικού φύλλου και την παρουσίαση του γραφήματος για επεξεργασία. Όταν ο χρήστης κλείσει το λογιστικό φύλλο, το γράφημα θα ενημερωθεί στο αρχικό έγγραφο του επεξεργαστή κειμένου. Το λογιστικό φύλλο φαίνεται σαν να είναι μια επέκταση του επεξεργαστή κειμένου. Τα θεμέλια του OLE είναι το Component Object Model (COM) [35]. Ένα συστατικό λογισμικού που χρησιμοποιεί COM μπορεί να επικοινωνήσει με διάφορα άλλα συστατικά, ακόμα και με συστατικά που δεν έχουν ακόμη γραφτεί. Τα συστατικά αλληλεπιδρούν ως αντικείμενα (objects) και πελάτες (clients). Το κατανεμημένο (Distributed) COM επεκτείνει το προγραμματιστικό μοντέλο COM έτσι ώστε να λειτουργεί σε δίκτυο. Το COM παρέχει πρόσβαση στα δεδομένα ενός αντικειμένου μέσω ενός ή περισσοτέρων συνόλων σχετικών λειτουργιών (functions), που είναι γνωστά ως διεπαφές (interfaces). Μειονέκτημα είναι ότι τουλάχιστο η μία εφαρμογή θα πρέπει να ξέρει την ύπαρξη και τον τύπο της άλλης ώστε να γίνει η επικοινωνία μέσω OLE Dynamic Data Exchange (DDE) Το DDE [31], [32] είναι ένα πρωτόκολλο το οποίο επιτρέπει στις εφαρμογές να ανταλλάσσουν δεδομένα σε διάφορα formats. Οι εφαρμογές μπορούν να χρησιμοποιήσουν το DDE για ανταλλαγές δεδομένων που γίνονται μία φορά ή για συνεχόμενες συναλλαγές κατά τις οποίες οι εφαρμογές ενημερώνονται μεταξύ τους καθώς γίνονται διαθέσιμα τα νέα δεδομένα. Τα δεδομένα που χρησιμοποιούνται στο DDE είναι τα ίδια με αυτά που χρησιμοποιούνται στο clipboard. Το DDE μπορεί να θεωρηθεί ως μια προέκταση του μηχανισμού του clipboard. Το clipboard χρησιμοποιείται σχεδόν πάντα για μία (φορά) απόκριση σε μια εντολή του χρήστη, όπως στην επιλογή της εντολής επικόλλησης (paste) από έναν κατάλογο επιλογών. Το DDE συνήθως ξεκινά με μια εντολή του χρήστη, αλλά συχνά Σελίδα 30 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

31 συνεχίζει να λειτουργεί χωρίς περαιτέρω αλληλεπίδραση με το χρήστη. Μπορούν επίσης να καθοριστούν προσαρμοσμένα formats δεδομένων DDE για ειδικού τύπου IPCs μεταξύ εφαρμογών με πιο σφικτά συνδεδεμένες (tightly coupled) απαιτήσεις επικοινωνίας. Οι συναλλαγές DDE μπορούν να γίνουν μεταξύ εφαρμογών που τρέχουν στον ίδιο υπολογιστή ή σε διαφορετικούς υπολογιστές σε δίκτυο. Το DDE δεν είναι τόσο αποδοτικό όσο οι νεώτερες τεχνολογίες. Πάντως μπορεί να χρησιμοποιηθεί αν δεν είναι κατάλληλοι οι υπόλοιποι μηχανισμοί IPC ή αν πρέπει να υλοποιηθεί μια διεπαφή με μια εφαρμογή που υποστηρίζει μόνο DDE File Mapping Το file mapping επιτρέπει σε μια διεργασία να χειριστεί τα περιεχόμενα ενός αρχείου σαν να ήταν ένα block μνήμης στο χώρο διευθύνσεων της διεργασίας. Αυτή η διεργασία μπορεί να χρησιμοποιεί απλούς χειρισμούς με δείκτες για να εξετάζει και να τροποποιεί τα περιεχόμενα ενός αρχείου. Αν δύο η περισσότερες διεργασίες προσπελαύνουν το ίδιο file mapping, κάθε διεργασία λαμβάνει έναν δείκτη στη μνήμη στο δικό της χώρο διευθύνσεων τον οποίο μπορεί να χρησιμοποιήσει για να διαβάσει ή να τροποποιήσει τα περιεχόμενα του αρχείου. Οι διεργασίες πρέπει να χρησιμοποιούν ένα αντικείμενο συγχρονισμού, όπως ένας σημαφόρος (semaphore), για να αποτραπεί η καταστροφή των δεδομένων σε ένα πολυδιεργασιακό (multitasking) περιβάλλον. Το file mapping είναι αρκετά αποδοτικό και επίσης προσφέρει χαρακτηριστικά ασφαλείας υποστηριζόμενα από το λειτουργικό σύστημα που μπορούν να αποτρέψουν την καταστροφή των δεδομένων από κάποιον που δεν έχει δικαίωμα πρόσβασης. Το file mapping μπορεί να χρησιμοποιηθεί μόνο μεταξύ διεργασιών που τρέχουν στον ίδιο υπολογιστή. Βέβαια έχει και το μειονέκτημα ότι ο προγραμματιστής πρέπει να ασχοληθεί με το συγχρονισμό μεταξύ των διεργασιών Mailslots Τα mailslots παρέχουν μονόδρομη επικοινωνία. Κάθε διεργασία που δημιουργεί ένα mailslot είναι ένας εξυπηρέτης mailslot. Άλλες διεργασίες, που καλούνται πελάτες mailslot, στέλνουν μηνύματα στον εξυπηρέτη mailslot γράφοντάς τα στο mailslot του. Τα εισερχόμενα μηνύματα προστίθενται πάντα στο mailslot όπου αποθηκεύονται έως ότου ο εξυπηρέτης τα διαβάσει. Μια διαδικασία μπορεί να είναι ταυτόχρονα εξυπηρέτης και πελάτης mailslot, ούτως ώστε να γίνεται δυνατή η αμφίδρομη επικοινωνία με τη χρήση πολλαπλών mailslots. Τα mailslots παρέχουν έναν εύκολο τρόπο στις εφαρμογές να στέλνουν και να λαμβάνουν σύντομα μηνύματα. Επίσης, παρέχουν τη δυνατότητα εκπομπής (broadcast) μηνυμάτων σε όλους τους υπολογιστές ενός τοπικού δικτύου Σωληνώσεις (Pipes) Το Win32 API παρέχει δύο τύπους σωληνώσεων για αμφίδρομη επικοινωνία: ανώνυμα (anonymous ή unnamed) και επώνυμα (named) pipes [33]. Τα ανώνυμα pipes επιτρέπουν συσχετιζόμενες διεργασίες να μεταφέρουν πληροφορίες μεταξύ τους. Τυπικά, ένα ανώνυμο pipe χρησιμοποιείται για την ανακατεύθυνση της τυπικής εισόδου ή εξόδου (standard input or output) μιας θυγατρικής διεργασίας (child process) έτσι ώστε να μπορεί να ανταλλάσσει δεδομένα με την μητρική διεργασία (parent process). Για την ανταλλαγή Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 31 από 163

32 δεδομένων και προς τις δύο κατευθύνσεις (λειτουργία duplex), πρέπει να δημιουργηθούν δύο ανώνυμα pipes. Η μητρική διεργασία γράφει δεδομένα στο ένα pipe χρησιμοποιώντας το handle εγγραφής της, ενώ η θυγατρική διεργασία διαβάζει τα δεδομένα από αυτό το Pipe χρησιμοποιώντας το handle ανάγνωσής της. Παρομοίως, η θυγατρική διεργασία γράφει δεδομένα στο άλλο pipe και η μητρική διεργασία τα διαβάζει από αυτό. Τα ανώνυμα pipes δεν μπορούν να χρησιμοποιηθούν σε δίκτυο, ούτε μπορούν να χρησιμοποιηθούν μεταξύ μη συσχετισμένων διεργασιών. Τα επώνυμα pipes χρησιμοποιούνται για να μεταφέρουν δεδομένα μεταξύ διεργασιών που δεν είναι συσχετισμένες ή βρίσκονται σε διαφορετικούς υπολογιστές. Τυπικά, μια διεργασία εξυπηρέτης επωνύμου pipe (named-pipe server process) δημιουργεί ένα επώνυμο pipe με ένα γνωστό όνομα ή με ένα όνομα το οποίο θα γίνει γνωστό στους πελάτες της. Μια διεργασία πελάτης επωνύμου pipe (named-pipe client process) που γνωρίζει το όνομα του pipe μπορεί να ανοίξει την άλλη άκρη του, υποκείμενη στα δικαιώματα πρόσβασης που έχουν δοθεί από τη διεργασία εξυπηρέτη pipe. Αφού και ο εξυπηρέτης και ο πελάτης έχουν συνδεθεί στο pipe μπορούν να ανταλλάξουν δεδομένα εκτελώντας ενέργειες ανάγνωσης και εγγραφής σε αυτό RPC Το Win32 API παρέχει Remote Procedure Calls (RPC) για να μπορούν οι εφαρμογές να καλούν διεργασίες από μακριά. Έτσι, το RPC κάνει την IPC τόσο εύκολη όσο η κλήση μιας διεργασίας. Το RPC λειτουργεί μεταξύ διεργασιών στον ίδιο υπολογιστή, στο δίκτυο ή στο Διαδίκτυο. Το RPC που παρέχεται από το Win32 API είναι σύμφωνο με το Open Software Foundation (OSF) Distributed Computing Environment (DCE). Αυτό σημαίνει ότι οι εφαρμογές που βασίζονται στα Win32 και χρησιμοποιούν RPC μπορούν να επικοινωνήσουν με εφαρμογές που τρέχουν σε άλλα λειτουργικά συστήματα που υποστηρίζουν DCE. Το RPC υποστηρίζει αυτόματα την μετατροπή των δεδομένων ανάλογα με τις διάφορες αρχιτεκτονικές hardware και ανάλογα με την σειρά των bytes μεταξύ ανόμοιων περιβαλλόντων. Οι πελάτες και οι εξυπηρέτες του RPC είναι στενά συνδεδεμένοι (tightly coupled) αλλά διατηρούν την υψηλή απόδοση Windows Sockets Τα Windows Sockets είναι μια διεπαφή ανεξάρτητη από πρωτόκολλα. Εκμεταλλεύεται τις επικοινωνιακές δυνατότητες των πρωτοκόλλων που βρίσκονται σε κατώτερα επίπεδα. Στα Windows Sockets 2, ένα socket handle μπορεί προαιρετικά να χρησιμοποιηθεί ως handle αρχείου με τις τυπικές λειτουργίες εισόδου/εξόδου αρχείων. Τα Windows Sockets βασίζονται στα sockets που έγιναν αρχικά δημοφιλή από την Berkeley Software Distribution (BSD). Μια εφαρμογή που χρησιμοποιεί Windows Sockets μπορεί να επικοινωνεί με άλλες υλοποιήσεις sockets σε συστήματα διαφορετικού τύπου WM_COPYDATA Το μήνυμα WM_COPYDATA επιτρέπει την αποστολή δεδομένων από μια εφαρμογή σε μία άλλη. Όταν τα δεδομένα περνούν από μια εφαρμογή που βασίζεται στα Windows 16 Σελίδα 32 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

33 bit σε μια άλλη που βασίζεται στα 32 bit, το σύστημα μεταφράζει τους οποιουσδήποτε δείκτες. Το βασικότερο μειονέκτημα αυτής της τελευταίας μεθόδου, όπως και των περισσότερων υπολοίπων εκτός των υπηρεσιών του COM είναι ότι θα πρέπει να είναι γνωστές από πριν οι εφαρμογές ή τα συστατικά που πρέπει να επικοινωνήσουν. Αυτό όμως είναι ανέφικτο σύμφωνα με τις προδιαγραφές του πλαισίου ΟΔΥΣΣΕΑΣ, το οποίο απαιτεί πλήρη απομόνωση μεταξύ των συστατικών. Έτσι το μοντέλο αντικειμένων COM και, όπως θα δειχτεί στη συνέχεια, η εξέλιξή του, το COM+ επιλέχθηκε ως η καλύτερη λύση για την υλοποίηση του πλαισίου ΟΔΥΣΣΕΑΣ. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 33 από 163

34

35 4. COM (Component Object Model) Που εφαρμόζεται Τα αντικείμενα (objects) COM μπορούν να δημιουργηθούν με πολλές γλώσσες προγραμματισμού. Οι object-oriented γλώσσες προγραμματισμού, όπως η C++, παρέχουν μηχανισμούς προγραμματισμού που απλοποιούν την υλοποίηση των αντικειμένων COM. Αυτά τα αντικείμενα μπορούν να βρίσκονται μέσα σε μία μόνο διεργασία (process), σε διαφορετικές διεργασίες, ακόμα και σε διαφορετικούς υπολογιστές. Σε ποιους προγραμματιστές απευθύνεται Το COM [27], [28] είναι σχεδιασμένο πρωταρχικά για τους προγραμματιστές της C++ και της Microsoft Visual Basic. Απαιτήσεις χρόνου εκτέλεσης (run-time) Τρέχει σε πολλά λειτουργικά συστήματα Περιγραφή Το Component Object Model (COM) είναι ένα σύστημα ανεξάρτητο από πλατφόρμα, κατανεμημένο, object-oriented, για τη δημιουργία δυαδικών συστατικών λογισμικού τα οποία μπορούν να αλληλεπιδρούν. Το COM είναι η τεχνολογία θεμελίωσης για τις τεχνολογίες Microsoft OLE (μικτά έγγραφα) και ActiveX (συστατικά με υποστήριξη Internet), και άλλες [50], [51]. Για την κατανόηση του COM (και κατ επέκταση όλων των τεχνολογιών που βασίζονται σε αυτό), είναι σημαντικό να διευκρινιστεί ότι δεν πρόκειται για μια object-oriented γλώσσα προγραμματισμού, αλλά για μια τυποποίηση. Επίσης, το COM δεν καθορίζει πως θα πρέπει να είναι δομημένη μια εφαρμογή. Η επιλογή της γλώσσας, της δομής και οι λεπτομέρειες της υλοποίησης αφήνονται στον προγραμματιστή της εφαρμογής. Το COM καθορίζει ένα μοντέλο αντικειμένων και τις προγραμματιστικές απαιτήσεις που επιτρέπουν στα αντικείμενα COM (που καλούνται επίσης και συστατικά COM, ή απλά objects) να αλληλεπιδράσουν με άλλα αντικείμενα. Αυτά τα αντικείμενα μπορεί να βρίσκονται μέσα σε μία μόνο διεργασία (process), σε διαφορετικές διεργασίες, ακόμα και σε διαφορετικούς υπολογιστές. Μπορεί να είναι γραμμένα σε διαφορετικές γλώσσες προγραμματισμού και δομικά να μην έχουν καμία ομοιότητα. Γι αυτόν το λόγο το COM αναφέρεται ως δυαδική τυποποίηση είναι μια τυποποίηση που εφαρμόζεται αφού ένα πρόγραμμα μεταφραστεί σε δυαδικό κώδικα μηχανής. Η μόνη απαίτηση του COM ως προς τη γλώσσα προγραμματισμού είναι ότι ο κώδικας θα πρέπει να γράφεται σε μια γλώσσα που να μπορεί να δημιουργεί δομές δεικτών και, είτε ρητά είτε συνεπαγόμενα, να μπορεί να καλεί λειτουργίες (functions) μέσω των δεικτών. Object-oriented γλώσσες προγραμματισμού, όπως η C++ και η Smalltalk, παρέχουν μηχανισμούς προγραμματισμού που απλοποιούν την υλοποίηση των αντικειμένων COM, αλλά και γλώσσες όπως η C, η Pascal, η Ada, η Java, ακόμα και τα προγραμματιστικά περιβάλλοντα BASIC, μπορούν να κατασκευάσουν και να χρησιμοποιήσουν αντικείμενα COM. Το COM καθορίζει τη θεμελιώδη φύση ενός αντικειμένου COM. Γενικά, ένα αντικείμενο λογισμικού μπορεί να αποτελείται από ένα σύνολο δεδομένων και τις λειτουργίες Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 35 από 163

36 (functions) που διαχειρίζονται αυτά τα δεδομένα, Ένα αντικείμενο COM είναι τέτοιο ώστε η πρόσβαση στα δεδομένα του επιτυγχάνεται αποκλειστικά μέσω ενός ή περισσότερων σχετικών συνόλων λειτουργιών. Αυτά τα σύνολα των λειτουργιών καλούνται διεπαφές (interfaces) και οι λειτουργίες μιας διεπαφής καλούνται μέθοδοι (methods). Ακόμη, το COM καθορίζει ότι ο μόνος τρόπος πρόσβασης στις μεθόδους μιας διεπαφής είναι μέσω ενός δείκτη στη διεπαφή Αντικείμενα και Διεπαφές του COM Το COM είναι μια τεχνολογία που επιτρέπει σε αντικείμενα να αλληλεπιδρούν μεταξύ διεργασιών και υπολογιστών τόσο εύκολα όσο αλληλεπιδρούν τα αντικείμενα μέσα σε μία διεργασία. Αυτό επιτυγχάνεται επειδή σύμφωνα με το COM ο μόνος τρόπος διαχείρισης των δεδομένων που σχετίζονται με ένα αντικείμενο είναι μέσω της διεπαφής του αντικειμένου. Όταν χρησιμοποιείται αυτός ο όρος, αναφέρεται σε μια υλοποίηση σε κώδικα μιας διεπαφής σύμφωνης με το δυαδικό COM η οποία είναι συνδεδεμένη με το αντικείμενο. Το ότι ένα αντικείμενο υλοποιεί μια διεπαφή σημαίνει ότι το αντικείμενο χρησιμοποιεί κώδικα που υλοποιεί κάθε μέθοδο της διεπαφής και παρέχει δείκτες σύμφωνους με το δυαδικό COM σε αυτές τις λειτουργίες στη βιβλιοθήκη COM. Μετά το COM αναλαμβάνει τη διάθεση αυτών των λειτουργιών σε οποιονδήποτε πελάτη ζητήσει έναν δείκτη στη διεπαφή, είτε ο πελάτης είναι μέσα είτε έξω από τη διεργασία που υλοποιεί αυτές τις λειτουργίες Διεπαφές και υλοποιήσεις διεπαφών Το COM ενέχει μια θεμελιώδη διαφοροποίηση μεταξύ των ορισμών των διεπαφών (interface definitions) και των υλοποιήσεών τους. Μια διεπαφή είναι στην ουσία μια σύμβαση που αποτελείται από μια ομάδα προτύπων λειτουργιών των οποίων ορίζεται η χρήση αλλά όχι η υλοποίηση. Αυτά τα πρότυπα λειτουργιών είναι ισοδύναμα με τις καθαρές βασικές κλάσεις της C++ στον προγραμματισμό. Ο ορισμός μιας διεπαφής καθορίζει τις λειτουργίες - μέλη της διεπαφής, δηλαδή τις μεθόδους, τους τύπους δεδομένων που επιστρέφουν, τον αριθμό και τους τύπους των παραμέτρων τους και το τι πρέπει να κάνουν. Καμία υλοποίηση δεν συσχετίζεται με τη διεπαφή. Μια υλοποίηση διεπαφής είναι ο κώδικας που παρέχει ο προγραμματιστής για να πραγματοποιήσει τις ενέργειες που καθορίζονται στον ορισμό μιας διεπαφής. Υλοποιήσεις πολλών διεπαφών που θα μπορούσε να χρησιμοποιήσει ο προγραμματιστής σε μια objectoriented εφαρμογή περιέχονται στις βιβλιοθήκες COM. Πάντως, οι προγραμματιστές είναι ελεύθεροι να αγνοήσουν αυτές τις υλοποιήσεις και να γράψουν τις δικές τους. Μια υλοποίηση διεπαφής συσχετίζεται με ένα αντικείμενο όταν δημιουργείται ένα στιγμιότυπο (instance) αυτού του αντικειμένου και προσφέρει τις υπηρεσίες που προσφέρει το αντικείμενο. Απλά αντικείμενα μπορεί να υποστηρίζουν μόνο μία διεπαφή. Πιο πολύπλοκα αντικείμενα, όπως αυτά που μπορούν να ενσωματωθούν (embeddable), συνήθως υποστηρίζουν αρκετές διεπαφές. Οι πελάτες έχουν πρόσβαση σε ένα αντικείμενο COM μόνο μέσω ενός δείκτη σε μία από τις διεπαφές του, που με τη σειρά της, επιτρέπει στον πελάτη να καλέσει οποιαδήποτε από τις μεθόδους που αποτελούν τη διεπαφή. Αυτές οι μέθοδοι καθορίζουν πως ο πελάτης μπορεί να χρησιμοποιήσει τα δεδομένα του αντικειμένου. Σελίδα 36 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

37 Στην ουσία, οι διεπαφές καθορίζουν μια σύμβαση μεταξύ του αντικειμένου και των πελατών του. Η σύμβαση καθορίζει τις μεθόδους που συσχετίζονται με κάθε διεπαφή και ποια πρέπει να είναι η συμπεριφορά κάθε μιας από τις μεθόδους όσον αφορά την είσοδο και την έξοδο. Γενικά, η σύμβαση δεν καθορίζει πως θα υλοποιηθούν οι μέθοδοι μέσα σε μια διεπαφή. Ένα άλλο σημαντικό χαρακτηριστικό της σύμβασης είναι ότι εάν ένα αντικείμενο υποστηρίζει μια διεπαφή, πρέπει με κάποιο τρόπο να υποστηρίζει όλες τις μεθόδους της. Δεν χρειάζεται σε μια υλοποίηση όλες οι μέθοδοι να κάνουν κάτι αν ένα αντικείμενο δεν υποστηρίζει τη λειτουργία που περιέχεται σε μια μέθοδο, η υλοποίησή της μπορεί να είναι μια απλή επιστροφή, ή η επιστροφή ενός κατανοητού μηνύματος σφάλματος αλλά σίγουρα θα πρέπει να υφίσταται Επαναχρησιμοποίηση αντικειμένων Ένας σημαντικός σκοπός οποιουδήποτε μοντέλου αντικειμένων είναι οι προγραμματιστές των αντικειμένων να μπορούν να επαναχρησιμοποιούν και να επεκτείνουν τα αντικείμενα που παρέχονται από άλλους, ως τμήματα των δικών τους υλοποιήσεων. Ένας τρόπος να γίνει αυτό στην C++ και σε άλλες γλώσσες είναι η κληρονομικότητα της υλοποίησης (implementation inheritance), η οποία επιτρέπει σε ένα αντικείμενο να κληρονομήσει κάποιες από τις λειτουργίες του από ένα άλλο αντικείμενο καθώς και να αγνοήσει άλλες λειτουργίες. Η χρήση της παραδοσιακής κληρονομικότητας της υλοποίησης κατά την αλληλεπίδραση των αντικειμένων σε ένα σύστημα, έχει το πρόβλημα ότι η σύμβαση (η διεπαφή) μεταξύ των αντικειμένων σε μια ιεραρχική υλοποίηση δεν είναι καθαρά ορισμένη. Στην ουσία είναι συνεπαγόμενη και αμφιλεγόμενη. Όταν το μητρικό ή το θυγατρικό αντικείμενο αλλάξει την υλοποίησή του, η συμπεριφορά των συσχετιζόμενων συστατικών μπορεί να γίνει ακαθόριστη, ή ασταθής. Σε μία εφαρμογή, όπου η υλοποίηση μπορεί να κατασκευαστεί από μία ομάδα μηχανικών, οι οποίοι ενημερώνουν όλα τα συστατικά την ίδια στιγμή, αυτό δεν είναι μεγάλο πρόβλημα. Όμως, σε ένα περιβάλλον όπου τα συστατικά της μιας ομάδας κατασκευάζονται μετά από επαναχρησιμοποίηση των συστατικών μιας άλλης ομάδας ως μαύρα κουτιά, αυτού του είδους η αστάθεια κάνει την επαναχρησιμοποίηση παρακινδυνευμένη. Ακόμη, η κληρονομικότητα της υλοποίησης, συνήθως λειτουργεί μόνο μέσα στα όρια των διεργασιών. Αυτό κάνει την παραδοσιακή κληρονομικότητα της υλοποίησης μη πρακτική για μεγάλα, επεκτεινόμενα συστήματα που αποτελούνται από συστατικά λογισμικού που κατασκευάζονται από πολλές ομάδες μηχανικών. Το κλειδί για την κατασκευή επαναχρησιμοποιούμενων συστατικών είναι να υπάρχει η δυνατότητα τα συστατικά να αντιμετωπιστούν ως μαύρα κουτιά. Αυτό σημαίνει ότι το τμήμα του κώδικα που επιχειρεί να επαναχρησιμοποιήσει ένα άλλο αντικείμενο δε γνωρίζει τίποτα, και δε χρειάζεται να γνωρίζει τίποτα, σχετικά με την εσωτερική δομή ή την υλοποίηση του συστατικού που πρόκειται να χρησιμοποιηθεί. Με άλλα λόγια, ο κώδικας που προσπαθεί να χρησιμοποιήσει ένα συστατικό εξαρτάται από την συμπεριφορά του αντικειμένου και όχι την ακριβή υλοποίηση. Για την επίτευξη της επαναχρησιμοποίησης τύπου μαύρου κουτιού, το COM υιοθετεί κάποιους άλλους εδραιωμένους μηχανισμούς επαναχρησιμοποίησης που καλούνται containment/delegation και aggregation. Για την περιγραφή τους το αντικείμενο το οποίο επαναχρησιμοποιείται καλείται εσωτερικό αντικείμενο και το αντικείμενο που χρησιμοποιεί αυτό το εσωτερικό αντικείμενο καλείται εξωτερικό αντικείμενο. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 37 από 163

38 Containment/Delegation Αυτός ο τύπος επαναχρησιμοποίησης είναι μια οικεία ιδέα που συναντάται στις περισσότερες object-oriented γλώσσες προγραμματισμού και συστήματα. Το εξωτερικό αντικείμενο συμπεριφέρεται ως πελάτης για το εσωτερικό αντικείμενο. Το εξωτερικό αντικείμενο «περιέχει» το εσωτερικό αντικείμενο και όταν χρειάζεται τις υπηρεσίες του, το εξωτερικό αντικείμενο μεταβιβάζει ρητά την υλοποίηση στις μεθόδους του εσωτερικού αντικειμένου. Έτσι, το εξωτερικό αντικείμενο χρησιμοποιεί τις υπηρεσίες του εσωτερικού αντικειμένου για να υλοποιήσει τον εαυτό του. Τα δύο αντικείμενα δεν είναι ανάγκη να υποστηρίζουν τις ίδιες διεπαφές, και είναι λογικό να περιέχεται ένα αντικείμενο που υλοποιεί τις διεπαφές που δεν υλοποιεί το εξωτερικό και υλοποιεί τις μεθόδους του εξωτερικού αντικειμένου απλά ως κλήσεις στις αντίστοιχες μεθόδους του εσωτερικού αντικειμένου. Είναι απλό να υλοποιηθεί το containment για ένα εξωτερικό αντικείμενο. Το εξωτερικό αντικείμενο δημιουργεί το εσωτερικό αντικείμενο που θέλει να χρησιμοποιήσει όπως θα έκανε οποιοσδήποτε πελάτης. Η διεργασία είναι σαν ένα αντικείμενο της C++ το οποίο περιέχει ένα αντικείμενο string της C++ και το χρησιμοποιεί για να διεξάγει ορισμένες διεργασίες με strings, ακόμα και αν το εξωτερικό αντικείμενο δεν θεωρείται από μόνο του ένα string αντικείμενο. Χρησιμοποιώντας το δείκτη του στο εσωτερικό αντικείμενο, μια κλήση σε μια μέθοδο στο εξωτερικό αντικείμενο δημιουργεί μια κλήση σε μια μέθοδο του εσωτερικού αντικειμένου Aggregation Σε αυτόν τον μηχανισμό επαναχρησιμοποίησης, το εξωτερικό αντικείμενο εκθέτει διεπαφές από το εσωτερικό αντικείμενο σαν να ήταν υλοποιημένες στο ίδιο το εξωτερικό αντικείμενο. Αυτό είναι χρήσιμο όταν το εξωτερικό αντικείμενο πάντα αναθέτει κάθε κλήση σε κάποια από τις διεπαφές του στην ίδια διεπαφή του εσωτερικού αντικειμένου. Το aggregation είναι στην ουσία μια ειδική περίπτωση του containment/delegation και προσφέρει τη διευκόλυνση της αποφυγής πρόσθετου overhead υλοποίησης στο εξωτερικό αντικείμενο σε τέτοιες περιπτώσεις Η βιβλιοθήκη COM Οποιαδήποτε διεργασία χρησιμοποιεί COM πρέπει να αρχικοποιεί (initialize) και να ελευθερώνει (uninitialize) τη βιβλιοθήκη COM. Το COM εκτός από το ότι είναι μια τυποποίηση, επίσης υλοποιεί κάποιες σημαντικές υπηρεσίες στη βιβλιοθήκη. Η Βιβλιοθήκη είναι σε μορφή μιας ομάδας από DLLs και EXEs (κυρίως το OLE32.DLL και το RPCSS.EXE) στα Microsoft Windows, και περιέχει: Ένα μικρό αριθμό από θεμελιώδεις λειτουργίες API οι οποίες διευκολύνουν τη δημιουργία των εφαρμογών COM, είτε είναι πελάτες είτε εξυπηρέτες. Για τους πελάτες το COM δίνει βασικές λειτουργίες για την δημιουργία αντικειμένων. Για τους εξυπηρέτες, το COM δίνει τα μέσα για να εκθέσουν τα αντικείμενά τους. Υπηρεσίες ανιχνευτή υλοποίησης μέσα από τις οποίες το COM προσδιορίζει με βάση έναν μοναδικό δείκτη κλάσης (class identifier CLSID) ποιος εξυπηρέτης υλοποιεί αυτήν την κλάση και που βρίσκεται. Αυτή η υπηρεσία περιλαμβάνει και υποστήριξη για ένα επίπεδο απομόνωσης, συνήθως με ένα registry του συστήματος, μεταξύ της ταυτότητας μιας κλάσης αντικειμένου και του πακεταρίσματος της υλοποίησης. Έτσι Σελίδα 38 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

39 ώστε οι πελάτες να είναι ανεξάρτητοι από το πακετάρισμα, το οποίο μπορεί να αλλάξει στο μέλλον. Διάφανες απομακρυσμένες κλήσεις διεργασιών (remote procedure calls) όταν ένα αντικείμενο τρέχει σε έναν τοπικό ή απομακρυσμένο εξυπηρέτη. Έναν τυποποιημένο μηχανισμό για να μπορεί μια εφαρμογή να ελέγχει πόση μνήμη δεσμεύεται στην διεργασία της, και ιδιαίτερα μνήμη που πρέπει να περάσει ανάμεσα από συνεργαζόμενα αντικείμενα, έτσι ώστε να μπορεί να την ελευθερώσει σωστά Το μοντέλο Client/Server του COM Το COM υποστηρίζει ένα μοντέλο αλληλεπίδρασης τύπου client/server μεταξύ ενός χρήστη των υπηρεσιών ενός αντικειμένου, τον πελάτη (client), και του παροχέα αυτού του αντικειμένου και των υπηρεσιών του, τον εξυπηρέτη (server). Για την ακρίβεια, ο πελάτης είναι ένα οποιοδήποτε τμήμα κώδικα (όχι αναγκαστικά μια εφαρμογή) που με κάποιο τρόπο αποκτά ένα δείκτη (pointer) μέσω του οποίου μπορεί να έχει πρόσβαση στις υπηρεσίες ενός αντικειμένου και στη συνέχεια καλεί αυτές τις υπηρεσίες όταν είναι αναγκαίο. Ο εξυπηρέτης είναι ένα τμήμα κώδικα που υλοποιεί το αντικείμενο και το δομεί με τέτοιο τρόπο, ώστε η βιβλιοθήκη COM να μπορεί να αντιστοιχίσει αυτήν την υλοποίηση σε έναν αναγνωριστή κλάσης (class identifier), ή CLSID. Αυτό που διαφοροποιεί έναν εξυπηρέτη από μια γενική υλοποίηση ενός αντικειμένου είναι η παρουσία του αναγνωριστή κλάσης. Διεργασία Πελάτη Εφαρμογή Πελάτη Αντικείμενο διεργασίας Εξυπηρέτης διεργασίας Proxy τοπικού αντικειμένου COM Proxy απομακρυσμένου αντικειμένου Διεργασία Τοπικού Εξυπηρέτη Stub COM Τοπικό αντικείμενο Τοπικός Εξυπηρέτης Απομακρυσμένος Η/Υ Διεργασία Απομακρυσμένου Εξυπηρέτη Stub COM Απομακρυσμένο αντικείμενο Απομακρυσμένος Εξυπηρέτης Σχήμα 2: Οι πελάτες εντοπίζουν και προσπελαύνουν τα αντικείμενα μέσω υπηρεσιών εντοπισμού υλοποίησης του COM. Στη συνέχεια το COM συνδέει τον πελάτη με ένα αντικείμενο σε έναν εξυπηρέτη. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 39 από 163

40 Η βιβλιοθήκη COM χρησιμοποιεί το CLSID για να παρέχει στους πελάτες υπηρεσίες εντοπισμού της υλοποίησης. Ένας πελάτης χρειάζεται μόνο να πει στο COM το CLSID που θέλει και τον τύπο του εξυπηρέτη ενδοδιεργασιακός, τοπικός, ή απομακρυσμένος επιτρέποντας στο COM να φορτωθεί ή να ξεκινήσει. Με τη σειρά του, το COM, εντοπίζει την υλοποίηση αυτής της κλάσης και αποκαθιστά μια σύνδεση μεταξύ αυτής και του πελάτη. Η σχέση μεταξύ του πελάτη, του COM και του εξυπηρέτη απεικονίζεται στο Σχήμα 2. Σημασία έχει επίσης και η ιδέα της διαφάνειας της θέσης, σύμφωνα με την οποία οι πελάτες και οι εξυπηρέτες δεν χρειάζεται να ξέρουν που πραγματικά βρίσκονται, δηλαδή, αν είναι στην ίδια διεργασία, σε διαφορετικές διεργασίες, ή σε διαφορετικούς υπολογιστές. Ανεξάρτητα από τον τύπο του εξυπηρέτη που χρησιμοποιείται, ένας πελάτης COM πάντα ζητά από το COM να δημιουργήσει στιγμιότυπα αντικειμένων με τον ίδιο ακριβώς τρόπο. Η απλούστερη μέθοδος για τη δημιουργία ενός αντικειμένου είναι η κλήση της συνάρτησης CoCreateInstance. Αυτή δημιουργεί ένα αντικείμενο του δεδομένου CLSID και επιστρέφει έναν δείκτη διεπαφής οποιουδήποτε τύπου έχει ζητηθεί από τον πελάτη. Εναλλακτικά ο πελάτης μπορεί να αποκτήσει έναν δείκτη διεπαφής σε αυτό που λέμε εργοστάσιο κλάσεων (class factory) με βάση το CLSID καλώντας την CoGetClassObject. Αυτό το αντικείμενο (εργοστάσιο κλάσεων) υποστηρίζει μια διεπαφή που λέγεται IClassFactory μέσω της οποίας ο πελάτης ζητά από το εργοστάσιο να κατασκευάσει ένα αντικείμενο της κλάσης του. Σε αυτό το σημείο ο πελάτης έχει δείκτες διεπαφών για δύο ξεχωριστά αντικείμενα: το εργοστάσιο κλάσεων και ένα αντικείμενο αυτής της κλάσης, που το καθένα έχει το δικό του μετρητή αναφοράς. Είναι ένα σημαντικό σημείο που απεικονίζεται στο Σχήμα 3. Πελάτης (1) "Δημιούργησε ένα αντικείμενο" (3) Επιστροφή δείκτη νέας διεπαφής στον πελάτη Εξυπηρέτης Εργοστάσιο Κλάσεων (2) Κατασκευή αντικειμένου Αντικείμενο Σχήμα 3: Ένας πελάτης COM δημιουργεί αντικείμενα μέσω ενός εργοστασίου κλάσεων. Εσωτερικά η συνάρτηση CoCreateInstance καλεί το ίδιο CoGetClassObject. Είναι απλά μια πιο βολική συνάρτηση για πελάτες που θέλουν να δημιουργήσουν ένα αντικείμενο. Υπάρχουν δύο βασικά είδη εξυπηρετών αντικειμένων: Σελίδα 40 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

41 Βασισμένοι σε Dynamic Link Library (.DLL). Ο εξυπηρέτης υλοποιείται σε ένα module το οποίο μπορεί να φορτωθεί και να εκτελεστεί μέσα από το χώρο διευθύνσεων του πελάτη. (Ο όρος.dll χρησιμοποιείται για να περιγράψει οποιοδήποτε μηχανισμό διαμοιραζόμενης βιβλιοθήκης που υπάρχει σε μια δεδομένη πλατφόρμα COM) [57]. Βασισμένοι σε.exe. Αυτός ο εξυπηρέτης υλοποιείται ως ένα stand-alone εκτελέσιμο module. Αφού το COM υποστηρίζει κατανεμημένα αντικείμενα, επιτρέπει επίσης και στους δυο βασικούς τύπους εξυπηρετών να υλοποιηθούν σε απομακρυσμένους υπολογιστές. Για να μπορούν οι εφαρμογές να ενεργοποιούν απομακρυσμένα αντικείμενα, το COM χρησιμοποιεί τον Service Control Manager (SCM). Διεπαφές αντικειμένου (όσες χρειάζονται) Αντικείμενο Όμοια υλοποίηση για κάθε μονάδα IClassFactory Εργοστάσιο Κλάσεων: Κατασκευάζε ι αντικείμενο Έκθεση για το Εργοστάσιο κλάσεων Μηχανισμός "Κλεισίματος" (Unloading) Η υλοποίηση διαφέρει στα EXE και στα DLL Μονάδα Εξυπηρέτη Σχήμα 4: Η γενική δομή ενός εξυπηρέτη COM Όπως ένας πελάτης είναι υπεύθυνος για τη χρήση ενός εργοστασίου κλάσεων και για τη διαχείριση του εξυπηρέτη, ένας εξυπηρέτης είναι υπεύθυνος για την υλοποίηση του εργοστασίου κλάσεων, την υλοποίηση της κλάσης των αντικειμένων που κατασκευάζει το εργοστάσιο, την έκθεση του εργοστασίου κλάσεων στο COM και την παροχή της Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 41 από 163

42 δυνατότητας του κλεισίματος (unloading) του εξυπηρέτη κάτω από τις κατάλληλες συνθήκες. Στο Σχήμα 4 φαίνεται ένα διάγραμμα που δείχνει τι υπάρχει μέσα σε ένα module εξυπηρέτη (EXE ή DLL). Το πως ο εξυπηρέτης ικανοποιεί αυτές τις απαιτήσεις εξαρτάται από το αν ο εξυπηρέτης υλοποιείται ως.dll ή ως.exe, αλλά είναι ανεξάρτητο από το αν ο εξυπηρέτης είναι στον ίδιο υπολογιστή με τον πελάτη ή σε έναν απομακρυσμένο υπολογιστή. Σελίδα 42 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

43 5. DCOM και CORBA To DCOM (Distributed Component Object Model) και το CORBA (Common Object Request Broker Architecture) είναι δύο δημοφιλή κατανεμημένα μοντέλα αντικειμένων [9], [10], [11]. Θα κάνουμε μια σύγκριση των αρχιτεκτονικών DCOM και CORBA με άξονες τη βασική προγραμματιστική αρχιτεκτονική, την αρχιτεκτονική απομακρυσμένων διαδικασιών και την αρχιτεκτονική του πρωτοκόλλου επικοινωνίας. Θα δοθεί μια βήμα προς βήμα περιγραφή της απομακρυσμένης ενεργοποίησης αντικειμένων και κλήσης μεθόδων για να φανούν οι ομοιότητες και οι διαφορές των δύο πλαισίων Εισαγωγή Η ανάπτυξη του Διαδικτύου, η αυξανόμενη δημοτικότητα των προσωπικών υπολογιστών και η ανάπτυξη της πρόσβασης σε δίκτυα με υψηλές ταχύτητες έβαλαν τον προγραμματισμό κατανεμημένων εφαρμογών στην πρώτη γραμμή. Για την απλούστευση του προγραμματισμού των δικτύων και για την υλοποίηση της αρχιτεκτονικής του λογισμικού που βασίζεται σε συστατικά, εμφανίστηκαν ως τυποποιήσεις τα δύο μοντέλα που μελετούμε. Το DCOM είναι η κατανεμημένη επέκταση του COM (Component Object Model) που δημιουργεί ένα επίπεδο κλήσης απομακρυσμένων διεργασιών αντικειμένων (Object Remote Procedure Call ORPC) πάνω από το DCE RPC (Distributed Computing Environment Remote Procedure Call) για να υποστηρίξει απομακρυσμένα αντικείμενα. Ένας εξυπηρέτης COM μπορεί να δημιουργήσει στιγμιότυπα αντικειμένων πολλαπλών κλάσεων αντικειμένων. Ένα αντικείμενο COM μπορεί να υποστηρίζει πολλαπλές διεπαφές, που κάθε μία αντιπροσωπεύει μια διαφορετική πλευρά ή συμπεριφορά του αντικειμένου. Μια διεπαφή αποτελείται από ένα σύνολο συσχετιζόμενων λειτουργικά μεθόδων. Ένας πελάτης COM αλληλεπιδρά με ένα αντικείμενο COM αποκτώντας έναν δείκτη σε μία από τις διεπαφές του αντικειμένου και καλώντας μεθόδους μέσω αυτού του δείκτη, σαν να ήταν το αντικείμενο μέσα στο χώρο διευθύνσεων του πελάτη. Το COM καθορίζει ότι οποιαδήποτε διεπαφή πρέπει να ακολουθεί μια τυποποιημένη εμφάνιση στη μνήμη, η οποία είναι η ίδια με το virtual function table της C++. Αφού η τυποποίηση είναι στο δυαδικό επίπεδο, επιτρέπει την ολοκλήρωση δυαδικών συστατικών που πιθανώς να έχουν γραφτεί σε διαφορετικές γλώσσες προγραμματισμού όπως οι C++, Java, Visual Basic. Το CORBA είναι ένα πλαίσιο κατανεμημένων αντικειμένων που προτάθηκε από μια διεθνή συνεργασία πάνω από 700 εταιριών που λέγεται Object Management Group (OMG). Ο πυρήνας της αρχιτεκτονικής CORBA είναι ο "Μεσίτης Αιτήσεων Αντικειμένων" (Object Request Broker - ORB) που δρα ως ο δίαυλος αντικειμένων πάνω στον οποίον τα αντικείμενα αλληλεπιδρούν με διαφάνεια με άλλα αντικείμενα που βρίσκονται τοπικά ή απομακρυσμένα. Ένα αντικείμενο CORBA αντιπροσωπεύεται στον έξω κόσμο από μια διεπαφή με ένα σύνολο μεθόδων. Ένα συγκεκριμένο στιγμιότυπο ενός αντικειμένου αναγνωρίζεται από μια αναφορά αντικειμένου (object reference). To ORB είναι υπεύθυνο για όλους τους μηχανισμούς που απαιτούνται για την εύρεση της υλοποίησης του αντικειμένου, για την προετοιμασία του ώστε να λάβει την αίτηση, για τη μεταφορά της αιτήσεως σε αυτό και για τη μεταφορά της απάντησης (αν υπάρχει) πίσω Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

44 στον πελάτη. Η υλοποίηση του αντικειμένου αλληλεπιδρά με το ORB είτε μέσω ενός Προσαρμογέα Αντικειμένου (Object Adapter OA) είτε μέσω της διεπαφής του ORB. Και τα δύο πλαίσια, το DCOM και το CORBA παρέχουν επικοινωνία τύπου πελάτηεξυπηρέτη (client-server). Για να ζητήσει μία υπηρεσία, ένας πελάτης καλεί μια μέθοδο που είναι υλοποιημένη από ένα απομακρυσμένο αντικείμενο, το οποίο δρα ως ο εξυπηρέτης στο μοντέλο πελάτη-εξυπηρέτη. Η υπηρεσία που παρέχεται από τον εξυπηρέτη πακετάρεται ως ένα αντικείμενο και η διεπαφή ενός αντικειμένου περιγράφεται σε μία Γλώσσα Ορισμού Διεπαφών (Interface Definition Language IDL). Οι διεπαφές που ορίζονται από ένα αρχείο IDL έχουν το ρόλο ενός συμβολαίου μεταξύ του εξυπηρέτη και των πελατών του. Οι πελάτες αλληλεπιδρούν με έναν εξυπηρέτη καλώντας μεθόδους που περιγράφονται στην IDL. Η πραγματική υλοποίηση του αντικειμένου κρύβεται από τους πελάτες. Στο επίπεδο της IDL υπάρχουν κάποια χαρακτηριστικά του αντικειμενοστραφούς προγραμματισμού, όπως το data encapsulation, ο πολυμορφισμός και η απλή κληρονομικότητα. Η CORBA υποστηρίζει επίσης την πολλαπλή κληρονομικότητα στο επίπεδο του IDL, αλλά το DCOM όχι. Για την επίτευξη του ίδιου στόχου, στο DCOM χρησιμοποιείται η έννοια του αντικειμένου που έχει πολλαπλές διεπαφές. Και στο DCOM και στο CORBA, οι αλληλεπιδράσεις μεταξύ μιας διεργασίας-πελάτη και ενός αντικειμένου-εξυπηρέτη υλοποιούνται ως αντικειμενοστραφείς επικοινωνίες τύπου RPC. Το Σχήμα 5 δείχνει την τυπική δομή του RPC. Για να κληθεί μια απομακρυσμένη συνάρτηση, ο πελάτης κάνει μια κλήση στο stub του πελάτη. Το stub πακετάρει τις παραμέτρους της κλήσης σε ένα μήνυμα αίτησης και καλεί ένα πρωτόκολλο επικοινωνίας για να στείλει το μήνυμα στον εξυπηρέτη. Στην πλευρά του εξυπηρέτη, το πρωτόκολλο επικοινωνίας παραδίδει το μήνυμα στο stub του εξυπηρέτη, το οποίο στη συνέχεια ξεπακετάρει το μήνυμα της αίτησης και καλεί την πραγματική συνάρτηση στο αντικείμενο. Στο DCOM, το stub του πελάτη αναφέρεται ως proxy και το stub του εξυπηρέτη αναφέρεται ως stub. Αντίστοιχα, το stub του πελάτη στο CORBA αναφέρεται ως stub και το stub του εξυπηρέτη αναφέρεται ως skeleton. Μερικές φορές, ο όρος "proxy" χρησιμοποιείται για την αναφορά σε ένα εκτελούμενο στιγμιότυπο του stub στην CORBA. Οι συνολικές αρχιτεκτονικές του DCOM και της CORBA φαίνονται στο Σχήμα 6 και στο Σχήμα 7 αντίστοιχα. Σελίδα 44 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

45 1. Η εφαρμογήπελάτης καλεί την απομακρυσμένη διεργασία 2. Το stub πακετάρει την κλήση διεργασίας, και το περιβάλλον εκτέλεσης την εκπέμπει στον διακομιστή του εξυπηρέτη Πελάτης Εφαρμογή Πελάτης Stub Πελάτη Βιβλιοθήκη RPC Χρόνου Εκτέλεσης 6. Το περιβάλλον εκτέλεσης παραλαμβάνει τα αποτελέσματα, τα προωθεί στο stub του πελάτη όπου τα δεδομένα της κλήσης μετατρέπονται για να τα λάβει η εφαρμογήπελάτης Δίκτυο 5. Το stub πακετάρει τα αποτελέσματα της διεργασίας και το περιβάλλον εκτέλεσης τα στέλνει στον δια-κομιστή της εφαρμογής Εξυπηρέτης Απομακρυσμένη Διεργασία Stub Εξυπηρέτη Βιβλιοθήκη RPC Χρόνου Εκτέλεσης 4. Η απομακρυσμένη διεργασία εκτελείται 3. Το περιβάλλον εκτέλεσης λαμβάνει την κλήση, την προωθεί στο stub του εξυπηρέτη όπου τα δεδομένα της κλήσης μετατρέπονται για να τα λάβει η απομακρυσμένη διεργασία Σχήμα 5: Η δομή του RPC (Remote Procedure Call). Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 45 από 163

46 Σχήμα 6: Η συνολική αρχιτεκτονική του DCOM. Σχήμα 7: Η συνολική αρχιτεκτονική του CORBA. Στη συνέχεια, θα δοθεί μια βήμα προς βήμα περιγραφή της ενεργοποίησης αντικειμένων και της κλήσης μεθόδων όπως υλοποιούνται στο COM και στο CORBA, στα τρία διαφορετικά επίπεδα που φαίνονται στη Σχήματα. Το κορυφαίο επίπεδο είναι η βασική προγραμματιστική αρχιτεκτονική (basic programming architecture), η οποία είναι ορατή στους προγραμματιστές των προγραμμάτων του πελάτη και του αντικειμένουεξυπηρέτη. Το μεσαίο επίπεδο είναι η αρχιτεκτονική απομακρυσμένων διαδικασιών (remoting architecture), ή οποία με διαφάνεια κάνει τους δείκτες διεπαφών ή τις αναφορές σε αντικείμενα να έχουν νόημα μεταξύ διαφορετικών διεργασιών. Το χαμηλότερο επίπεδο είναι η αρχιτεκτονική του πρωτοκόλλου επικοινωνίας (wire Σελίδα 46 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

47 protocol architecture), η οποία επεκτείνει την αρχιτεκτονική απομακρυσμένων διαδικασιών για να λειτουργεί και διαμέσου διαφορετικών μηχανημάτων Κορυφαίο Επίπεδο: Βασική Αρχιτεκτονική Προγραμματισμού Στο κορυφαίο επίπεδο φαίνεται η εικόνα που έχει ο προγραμματιστής για το DCOM και το CORBA. Πιο συγκεκριμένα, περιγράφεται πως ένας πελάτης ζητά ένα αντικείμενο και καλεί τις μεθόδους του και πως ένα εξυπηρέτης δημιουργεί ένα στιγμιότυπο ενός αντικειμένου και το κάνει διαθέσιμο στον πελάτη. Το πώς ακριβώς συνδέεται ο πελάτης με τον εξυπηρέτη είναι εντελών κρυμμένο από τους προγραμματιστές. Τα προγράμματα του πελάτη και του εξυπηρέτη αλληλεπιδρούν σαν να βρισκόταν στον ίδιο χώρο διευθύνσεων στο ίδιο μηχάνημα. Οι σημαντικότερες διαφορές μεταξύ του DCOM και του CORBA σε αυτό το επίπεδο περιλαμβάνουν το πώς ένας πελάτης καθορίζει μία διεπαφή και τα εργοστάσια κλάσεων του COM και τις μεθόδους IUnknown. Μια βήμα προς βήμα περιγραφή δίνεται στον Πίνακα 1 και απεικονίζεται στα Σχήματα 8 και 9 για το DCOM και το CORBA, αντίστοιχα. Αν και ο Πίνακας 1 δείχνει μια κοινή ακολουθία κλήσης του DCOM, πρέπει να σημειωθούν δύο σημεία. Πρώτον, η χρήση των εργοστασίων κλάσεων στο COM είναι προαιρετική. Ένα αντικείμενο του εξυπηρέτη μπορεί να καλέσει την CoRegisterClassObject() για να δηλώσει οποιονδήποτε δείκτη διεπαφής και οι πελάτες μπορούν να καλέσουν ένα άλλο API του COM που λέγεται CoGetClassObject() για να πάρουν αυτόν τον δείκτη. Δεύτερον, η CoCreateInstance() δεν δημιουργεί αναγκαία ένα νέο στιγμιότυπο. Μέσα στην IClassFactory::CreateInstance(), ο εξυπηρέτης μπορεί να επιλέξει να επιστρέφει συνέχεια τον ίδιο δείκτη διεπαφής, έτσι ώστε διαφορετικοί πελάτες να μπορούν να συνδεθούν στο ίδιο στιγμιότυπο αντικειμένου με μια συγκεκριμένη κατάσταση. Ένας άλλος τρόπος σύνδεσης σε ένα στιγμιότυπο αντικειμένου είναι η χρήση των monikers ή/και του Running Object Τable. DCOM 1. Ο πελάτης καλεί την CoCreateInstance() της βιβλιοθήκης του COM χρησιμοποιώντας τα Class IDs των αντικειμένων. 2. Η υποδομή του COM εκκινεί έναν εξυπηρέτη αντικειμένων. 3. O Εξυπηρέτης κατασκευάζει εργοστάσια κλάσεων για όλα τα CLSIDs που υποστηρίζονται και καλεί την CoRegisterClassObject() για να δηλώσει το κάθε εργοστάσιο. Ο εξυπηρέτης περιμένει έως ότου να συμβεί κάτι για να τον ειδοποιήσει ότι δεν χρειάζεται πια. Οι εισερχόμενες κλήσεις πελατών θα εξυπηρετούνται σε άλλα threads. 4. Το COM παίρνει τους δείκτες Ενεργοποίηση αντικειμένων CORBA 1. Ο πελάτης καλεί τη ::bind(), η οποία είναι μια στατική συνάρτηση του stub του πελάτη. 2. Το ORB εκκινεί έναν εξυπηρέτη ο οποίος περιέχει ένα αντικείμενο που υποστηρίζει τη ζητούμενη διεπαφή. 3. Ο εξυπηρέτης δημιουργεί στιγμιότυπα όλων των υποστηριζόμενων αντικειμένων. (Σε κάθε διαδικασία κατασκευής, γίνονται κλήσεις για τη δημιουργία και τη δήλωση των αναφορών των αντικειμένων). Ο εξυπηρέτης καλεί την CORBA::BOA::impl_is_ready() για να πληροφορήσει το ORB ότι είναι έτοιμος να δεχτεί αιτήσεις πελατών. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 47 από 163

48 DCOM IClassFactory για τα CLSIDs που χρειάζεται και σε αυτούς καλεί την CreateInstance(). 5. Στην CreateInstance(), ο εξυπηρέτης δημιουργεί ένα στιγμιότυπο του αντικειμένου και κάνει μια κλήση στην QueryInterface() για να πάρει έναν δείκτη σε διεπαφή για το IID που χρειάζεται. 6. Το COM επιστρέφει το δείκτη της διεπαφής στον πελάτη. 1. Ο πελάτης καλεί την ->get() για τη διεπαφή που βλέπει η οποία στη συνέχεια καλεί την ::get() στο αντικείμενο στον εξυπηρέτη. 2. Για να πάρει έναν δείκτη σε μία άλλη διεπαφή του ίδιου στιγμιότυπου του αντικειμένου, ο πελάτης καλεί την ->QueryInterface() στην διεπαφή, η οποία καλεί την ::QueryInterface() στο αντικείμενο στον εξυπηρέτη. 3. Όταν τελειώσει με τη χρήση της πρώτης διεπαφής, ο πελάτης καλεί την ->Release() (η οποία μπορεί και να μην καλέσει την ::Release() του αντικειμένου) [Σημείωση 1]. 4. Ο πελάτης καλεί την ->reset() για την δεύτερη διεπαφή, η οποία καλεί την ::reset() στο αντικείμενο. 5. Ο πελάτης καλεί την ->Release() για τη δεύτερη διεπαφή, η οποία καλεί την ::Release() του αντικειμένου. Ενεργοποίηση αντικειμένων Κλήση Μεθόδων Πίνακας 1: Περιγραφή του κορυφαίου επιπέδου. CORBA 4. Το ORB επιστρέφει την αναφορά του αντικειμένου στον πελάτη. 1. Ο πελάτης καλεί την ->get(), η οποία στη συνέχεια καλεί την ::get() στον εξυπηρέτη. 2. Ο πελάτης καλεί την ->reset(), η οποία καλεί την ::reset() στον εξυπηρέτη. Στο CORBA, ένα αντικείμενο μπορεί να ενεργοποιηθεί καλώντας οποιαδήποτε μέθοδο μιας υπάρχουσας αναφοράς αντικειμένου. Κάποιοι πωλητές παρέχουν ειδικές κλήσεις μεθόδων, όπως η bind() στο Orbix [11], για να ενεργοποιήσουν ένα αντικείμενοεξυπηρέτη και να πάρουν την αναφορά αντικειμένου του. Ο πελάτης μπορεί να συνδεθεί σε ένα υπάρχον στιγμιότυπο αντί σε ένα νέο, αν βέβαια υπάρχει ένα υπάρχον στιγμιότυπο που να ταιριάζει με τον τύπο που ζητείται. Σημειώνεται ότι ένας πελάτης μπορεί να αποθηκεύσει μια αναφορά αντικειμένου κάνοντάς την αλφαριθμητική σειρά Σελίδα 48 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

49 χρησιμοποιώντας την object_to_string() και να τη χρησιμοποιήσει αργότερα επαναφέροντάς την με την string_to_object(). Σημείωση για τα Σχήματα: οι αριθμοί σε παρενθέσεις () αφορούν στα βήματα ενεργοποίησης αντικειμένων ενώ οι αριθμοί σε άγκιστρα [] αφορούν σε βήματα κλήσεων μεθόδων. Σχήμα 8: Βήματα του DCOM στο κορυφαίο επίπεδο. Σχήμα 9: Βήματα του CORBA στο κορυφαίο επίπεδο. Μια άλλη διαφορά μεταξύ του DCOM και του CORBA στο προγραμματιστικό επίπεδο είναι ο τρόπος που διαχειρίζονται τις εξαιρέσεις (exceptions) και τα σφάλματα. Το CORBA παρέχει υποστήριξη για συνήθεις εξαιρέσεις της C++ και κάποιες εξαιρέσεις της CORBA. Ακόμη, επιτρέπονται εξαιρέσεις που ορίζονται από τον χρήστη και δηλώνονται στην IDL. Ο IDL compiler αντιστοιχίζει μια εξαίρεση χρήστη σε μία κλάση της C++. Σε αντίθεση, το DCOM απαιτεί σε αυτό το επίπεδο, όλες οι μέθοδοι να επιστρέφουν ένα 32μπιτο κωδικό σφάλματος που ονομάζεται HRESULT. Στο επίπεδο της γλώσσας ή του εργαλείου προγραμματισμού, μια ομάδα από συμβάσεις και υπηρεσίες παρεχόμενες από το σύστημα (το αντικείμενο IError) επιτρέπει τα HRESULTs αποτυχίας να μετατρέπονται σε εξαιρέσεις με έναν τρόπο φυσικό για τη γλώσσα. Το χαμηλότερο επίπεδο του DCOM περιλαμβάνει έναν μηχανισμό γνωστό ως body extensions, ο οποίος Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 49 από 163

50 επιτρέπει τη μεταφορά πληροφοριών εξαιρέσεων (όπως αλφαριθμητικές σειρές που εξηγούν το σφάλμα) Μεσαίο Επίπεδο: Αρχιτεκτονική Απομακρυσμένων Διαδικασιών Το μεσαίο επίπεδο αποτελείται από την υποδομή που χρειάζεται για να δίνει στον πελάτη και τον εξυπηρέτη την ψευδαίσθηση ότι βρίσκονται στον ίδιο χώρο διευθύνσεων. Η περιγραφεί στον Πίνακα 2 δείχνει πως η υποδομή βρίσκει και εκκινεί τον ζητούμενο εξυπηρέτη και τις οντότητες που εμπλέκονται όταν παρουσιάζεται μια κλήση μεθόδου μεταξύ διαφορετικών διεργασιών. Οι ανάλογες απεικονίσεις για το DCOM και το CORBA φαίνονται στα Σχήματα 10 και 11,αντίστοιχα. Οι βασικές διαφορές μεταξύ του DCOM και του CORBA σε αυτό το επίπεδο περιλαμβάνουν το πώς τα αντικείμενα του εξυπηρέτη δηλώνονται και πότε δημιουργούνται τα στιγμιότυπα των proxy/stub/skeleton. DCOM CORBA Ενεργοποίηση αντικειμένων 1. Με την παραλαβή της κλήσης CoCreateInstance(), η βιβλιοθήκη COM αναθέτει την αποστολή στο Service Control Manager (SCM). 2. Ο SCM ελέγχει αν έχει δηλωθεί ένα εργοστάσιο κλάσεων για το συγκεκριμένο CLSID. Αν όχι, ο SCM λέει στο registry να αντιστοιχίσει το CLSID στη διαδρομή του εξυπηρέτη του και ξεκινά τον εξυπηρέτη. 3. Ο εξυπηρέτης δηλώνει όλα τα υποστηριζόμενα εργοστάσια κλάσεων σε έναν πίνακα κλάσεων αντικειμένων. 4. Ο SCM παίρνει από τον πίνακα τον δείκτη IClassFactory για το εργοστάσιο του συγκεκριμένου CLSID και καλεί σε αυτόν την CreateInstance(). 5. Όταν η CreateInstance() επιστρέφει τον δείκτη IID το COM δημιουργεί ένα stub αντικειμένων για το νέο στιγμιότυπο αντικειμένου. 6. Το stub αντικειμένων κάνει marshal τον δείκτη της διεπαφής, λέει στο registry να φτιάξει ένα stub διεπαφών για το συγκεκριμένο IID, και το συσχετίζει με το πραγματικό IID της διεπαφής του αντικειμένου-εξυπηρέτη. 7. Όταν ο SCM μεταφέρει τον marshaled δείκτη πίσω στην πλευρά του πελάτη, το COM δημιουργεί ένα proxy αντικειμένων για το 1. Με την παραλαβή της κλήσης ::bind(), το stub του πελάτη αναθέτει την αποστολή στο ORB. 2. Το ORB λέει στο Implementation Repository να αντιστοιχίσει την κλάση που έκανε την οντότητα που καλείται στη διαδρομή του εξυπηρέτη, και ενεργοποιεί τον εξυπηρέτη (στο Orbix, ο orbixd daemon αναλαμβάνει τη διαδικασία του εξυπηρέτη). 3. Ο εξυπηρέτης δημιουργεί στιγμιότυπα όλων των υποστηριζόμενων αντικειμένων. Το ζητούμενο αντικείμενο κληρονομεί έμμεσα το CORBA::Object του οποίου η διεργασία κατασκευής καλεί τη BOA::create() με ένα μοναδικό ID αναφοράς για να πάρει μία αναφορά αντικειμένου. Στη συνέχεια δηλώνει την αναφορά του αντικειμένου στο ORB καλώντας την obj_is_ready(). 4. Η διεργασία κατασκευής της επιθυμητής κλάσης κατασκευάζει επίσης ένα στιγμιότυπο της κλάσης skeleton. 5. Όταν το ORB μεταφέρει την αναφορά αντικειμένου πίσω στην πλευρά του πελάτη, δημιουργεί ένα στιγμιότυπο του proxy κλάσεων και Σελίδα 50 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

51 DCOM CORBA στιγμιότυπο του αντικειμένου. 8. To proxy αντικειμένων κάνει unmarshal τον δείκτη, λεει στο registry να δημιουργήσει ένα proxy διεπαφών για το συγκεκριμένο IID και το συσχετίζει με το αντικείμενο καναλιού RPC που είναι συνδεδεμένο στο stub. 9. Η βιβλιοθήκη COM επιστρέφει στον Πελάτη έναν δείκτη IID στο proxy διεπαφής. Ενεργοποίηση αντικειμένων το δηλώνει στον πίνακα proxy αντικειμένων με την αντίστοιχη αναφορά αντικειμένου. 6. Το stub του πελάτη επιστρέφει στον πελάτη μία αναφορά αντικειμένου. DCOM CORBA Κλήση μεθόδων 1. Με την παραλαβή της κλήσης - >get(), το proxy διεπαφών κάνει marshal τις αναγκαίες παραμέτρους και καλεί τη μέθοδο SendReceive() στο αντικείμενο του RPC καναλιού για να στείλει την αίτηση. 2. Το RPC κανάλι στέλνει την αίτηση στην πλευρά του εξυπηρέτη, βρίσκει το stub διεπαφών για το κατάλληλο IID και καλεί σε αυτό την μέθοδο Invoke(). 3. To stub διεπαφών κάνει unmarshal τις παραμέτρους, καλεί τη μέθοδο (που καθορίζεται από έναν αριθμό μεθόδου) στο αντικείμενο, κάνει marshal τις τιμές επιστροφής και επιστρέφει από τη μέθοδο Invoke. 4. Όταν το RPC κανάλι μεταφέρει τις marshaled τιμές επιστροφής πίσω στην πλευρά του πελάτη, το stub διεπαφών επιστρέφει από την κλήση της SendReceive(), κάνει unmarshal τις τιμές επιστροφής και τις επιστρέφει στον πελάτη για να τελειώσει την κλήση - >get(). 1. Με την παραλαβή της κλήσης - >get, το proxy δημιουργεί ένα ψευδοαντικείμενο Request, κάνει marshal τις απαραίτητες παραμέτρους σε αυτό, και καλεί την Request::invoke(), η οποία καλεί την CORBA::request::send() για αν βάλει το μήνυμα στο κανάλι και περιμένει στην CORBA::Request::get_response( ) για την απάντηση. 2. Όταν το μήνυμα φτάνει στον εξυπηρέτη, το BOA βρίσκει τον στόχο skeleton, ξαναφτιάχνει το αντικείμενο Request και το προωθεί στο skeleton. 3. Το skeleton κάνει unmarshal τις παραμέτρους από το αντικείμενο request, καλεί τη μέθοδο (που χαρακτηρίζεται από ένα όνομα μεθόδου) στο αντικείμενο, κάνει marshal τις παραμέτρους επιστροφής και επιστρέφει από την μέθοδο του skeleton. Το ORB κατασκευάζει ένα μήνυμα απάντησης και το τοποθετεί στο buffer μετάδοσης. 4. Όταν η απάντηση φτάσει στην πλευρά του πελάτη, η κλήση CORBA::Request::get_response() επιστρέφει αφού διαβάσει το μήνυμα απάντησης από το buffer παραλαβής. Στη συνέχεια το proxy κάνει unmarshal τις τιμές επιστροφής, ελέγχει για εξαιρέσεις και τις επιστρέφει στον πελάτη για να τελειώσει την Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 51 από 163

52 DCOM CORBA 5. Με την παραλαβή της κλήσης - >QueryInterface(), το proxy διεπαφών αναθέτει την αίτηση στη διεπαφή IUnknown() του proxy αντικειμένων. 6. Το proxy αντικειμένων καλεί απομακρυσμένα την πραγματική κλήση QueryInterface() στο πραγματικό αντικείμενο μέσω της ίδιας διαδικασίας που εξηγήθηκε παραπάνω. Κλήση μεθόδων 7. Με την επιστροφή του νέου δείκτη διεπαφής για το νέο IID, το COM δημιουργεί το stub διεπαφών και το proxy για αυτό (το οποίο μοιράζεται το ίδιο stub αντικειμένων και proxy με το stub διεπαφών και το proxy για το πρώτο IID, αντίστοιχα). 8. Το proxy διεπαφών για το πρώτο IID επιστρέφει στον πελάτη έναν δείκτη με το νέο IID για το νέο proxy διεπαφών. 9. Με την παραλαβή της κλήσης - >Release(), το proxy διεπαφών του πρώτου IID αναθέτει την αίτηση στο proxy αντικειμένων. 10.Με την παραλαβή της κλήσης - >reset() για το δεύτερο αντικείμενο, το proxy διεπαφών για το δεύτερο IID κάνει την απομακρυσμένη κλήση όπως συνήθως. 11.Με την παραλαβή της κλήσης - >Release για το δεύτερο αντικείμενο, το proxy διεπαφών του δεύτερου IID αναθέτει την αίτηση στο proxy αντικειμένων το οποίο στη συνέχεια κάνει μια απομακρυσμένη κλήση για να απελευθερώσει το δεύτερο αντικείμενο (και πιθανά και το πρώτο). κλήση της ->get(). Πίνακας 2: Περιγραφή του μεσαίου επιπέδου. Σελίδα 52 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

53 Σχήμα 10: Βήματα του DCOM στο μεσαίο επίπεδο. Σχήμα 11: Βήματα του CORBA στο μεσαίο επίπεδο. Για την αποστολή δεδομένων διαμέσου διαφορετικών χώρων διευθύνσεων απαιτεί μια διαδικασία που λέγεται marshaling και unmarshaling. Το marshaling πακετάρει τις παραμέτρους μιας κλήσης μεθόδου (στο χώρο του πελάτη) ή τις τιμές επιστροφής (στο χώρο του εξυπηρέτη) σε μία τυπική μορφή για μετάδοση. Το unmarshaling, η αντίστροφη διαδικασία, ξεπακετάρει την τυπική μορφή σε μια κατάλληλη μορφή παρουσίασης των δεδομένων στο χώρο διευθύνσεων της διεργασίας που παραλαμβάνει. Σημειώνεται ότι η διαδικασία marshaling που περιγράφεται εδώ λέγεται standard marshaling στην ορολογία του DCOM. Το DCOM παρέχει επίσης έναν μηχανισμό custom marshaling για να παρακάμψει τη διαδικασία του standard marshaling. Υλοποιώντας μία διεπαφή IMarshal, ένα αντικείμενο του εξυπηρέτη ξεκαθαρίζει ότι θέλει να ελέγχει πως και ποια δεδομένα γίνονται marshal και unmarshal και πως θα πρέπει να επικοινωνεί ο πελάτης με τον εξυπηρέτη. Ως αποτέλεσμα, το custom marshaling παρέχει μια επεκτάσιμη αρχιτεκτονική για τη σύνδεση σε υποδομές επικοινωνίας που είναι ειδικές για Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 53 από 163

54 συγκεκριμένες εφαρμογές. Αυτό μπορεί να είναι χρήσιμο για data caching στην πλευρά του πελάτη, για έλεγχο ανοχής σφαλμάτων, κλπ. Θα περιγράψουμε εδώ κάποιους από τους πρόσθετους όρους της CORBA που χρησιμοποιούνται στον Πίνακα 2. Όπως ειπώθηκε στην εισαγωγή, το ORB συμπεριφέρεται ως δίαυλος των αντικειμένων. Το Object Adaptor (ΟΑ) κάθεται πάνω από το ORB και είναι υπεύθυνο για τη σύνδεση της υλοποίησης του αντικειμένου με το ORB. Τα Object Adaptors παρέχουν υπηρεσίες όπως η δημιουργία των αναφορών των αντικειμένων (object references), η κλήση μεθόδων, η ενεργοποίηση και απενεργοποίηση αντικειμένων και η αντιστοίχηση αναφορών αντικειμένων σε υλοποιήσεις. Διαφορετικά στυλ υλοποίησης αντικειμένων έχουν διαφορετικές απαιτήσεις και χρειάζονται υποστήριξη από διαφορετικούς προσαρμογείς αντικειμένων, π.χ., αντικειμενοστραφείς προσαρμογείς βάσεων δεδομένων για αντικείμενα μέσα σε μια βάση δεδομένων. Το Basic Object Αdapter (BOA) ορίζει έναν προσαρμογέα αντικειμένων ο οποίος μπορεί να χρησιμοποιηθεί για τις περισσότερες συμβατικές υλοποιήσεις αντικειμένων. Η τυποποίηση CORBA δεν επιβάλλει τον τρόπο που η λειτουργικότητα ORB/BOA θα υλοποιηθεί. Το σύστημα Orbix κατασκεύασε τη λειτουργικότητα ORB/BOA σε δύο βιβλιοθήκες και μια διεργασία daemon (orbixd). Ο daemon είναι υπεύθυνος για την θέση και την ενεργοποίηση των αντικειμένων. Οι δύο βιβλιοθήκες, μια στην πλευρά του εξυπηρέτη και μία στην πλευρά του πελάτη, συνδέονται (linked) κατά τη διάρκεια της μεταγλώττισης (compile time) με τις υλοποιήσεις του εξυπηρέτη και του πελάτη, αντίστοιχα, για να παρέχουν τη λειτουργικότητα. Πρέπει να σημειωθεί ότι το πρόσφατο POA αντικαθιστά το BOA. Η τυποποίηση POA παρέχει μεταφερσιμότητα για τον κώδικα εξυπηρέτη της CORBA και εισάγει επίσης κάποια νέα χαρακτηριστικά στον Object Adapter Χαμηλό Επίπεδο: Αρχιτεκτονική Πρωτοκόλλου Επικοινωνίας Το χαμηλότερο επίπεδο καθορίζει το πρωτόκολλο των καλωδίων για την υποστήριξη της εκτέλεσης του πελάτη και του εξυπηρέτη σε διαφορετικά μηχανήματα. Η περιγραφή στον Πίνακα 3 δείχνει πως δημιουργούνται τα αντικείμενα σε ένα απομακρυσμένο μηχάνημα και περιγράφει τις οντότητες που εμπλέκονται όταν μια κλήση μεθόδου μεταφέρεται διαμέσου μηχανημάτων. Τα Σχήματα 12 και 13 απεικονίζουν τα βήματα για το DCOM και το CORBA, αντίστοιχα. Οι βασικές διαφορές μεταξύ του DCOM και του CORBA σε αυτό το επίπεδο περιλαμβάνουν το πώς οι δείκτες των απομακρυσμένων διεπαφών ή οι αναφορές των αντικειμένων αντιπροσωπεύονται για να μεταδώσουν τις πληροφορίες από τον εξυπηρέτη στον πελάτη και την τυπική μορφή με την οποία τα δεδομένα γίνονται marshaled για τη μεταφορά τους σε ένα ετερογενές περιβάλλον. Σημειώνεται ότι το CORBA δεν καθορίζει ένα πρωτόκολλο για την επικοινωνία μεταξύ ενός πελάτη και ενός αντικειμένου εξυπηρέτη που τρέχουν σε ORBs του ίδιου κατασκευαστή. Το πρωτόκολλο για την επικοινωνία μεταξύ των ORBs ενός κατασκευαστή εξαρτάται από τον κατασκευαστή. Πάντως, για την υποστήριξη της διαλειτουργικότητας μεταξύ διαφορετικών ORBs, έχει καθοριστεί ένα γενικό πρωτόκολλο το General Inter-ORB Protocol (GIOP). Έχει επίσης καθοριστεί μια αντιστοίχηση του GIOP στις συνδέσεις TCP/IP και είναι γνωστή ως Internet Inter-ORB Protocol (IIOP). Σελίδα 54 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

55 DCOM 1. Με την παραλαβή της αίτησης CoCreateInstance, αν το SCM της πλευράς του πελάτη δει στο τοπικό registry ότι το αντικείμενο θα έπρεπε να βρίσκεται σε ένα άλλο μηχάνημα εξυπηρέτη, καλεί μια μέθοδο της διεπαφής RPC IRemoteActivation στο SCM της πλευρά του εξυπηρέτη. 2. Όταν ο εξυπηρέτης εκκινηθεί από το SCM της πλευράς του εξυπηρέτη, συσχετίζεται με έναν εξαγωγέα αντικειμένων και του ανατίθεται ένας αναγνωριστής εξαγωγέα αντικειμένων (Object Exporter ID OXID). Η αντιστοίχηση του OXID με τη σύνδεση RPC που μπορεί να χρησιμοποιηθεί για την πρόσβαση στον εξυπηρέτη, δηλώνεται στον OXID resolver της πλευράς του εξυπηρέτη. 3. Όταν το stub αντικειμένων κάνει marshal τον δείκτη IID του αντικειμένου που επιστράφηκε από την CreateInstance(), ανατίθεται στον δείκτη ένας αναγνωριστής δείκτη διεπαφής (Interface pointer Identifier IPID), μοναδικός στον εξυπηρέτη. Επίσης, δημιουργείται μια αναφορά αντικειμένου (Object Reference OBJREF) για να αντιπροσωπεύσει τον δείκτη. Το OBJREF περιέχει το IPID, το OXID, διευθύνσεις των OXID resolvers (ένας για κάθε πρωτόκολλο), κτλ. 4. Όταν ο marshaled δείκτης διεπαφής επιστραφεί στην πλευρά του πελάτη μέσω των SCM της πλευράς του εξυπηρέτη και του πελάτη, το proxy αντικειμένων εξάγει το OXID και τις διευθύνσεις των OXID resolvers από το OBJREF και καλεί τη μέθοδο IOXIDResolver:ResolveOXID του τοπικού OXID resolver. 5. Ο OXID resolver της πλευράς του πελάτη ελέγχει αν έχει μία cached αντιστοίχηση του OXID, Αν όχι, καλεί τη μέθοδο IOXIDResolver:ResolveOXID του OXID resolver της πλευράς του εξυπηρέτη, η οποία επιστρέφει τη δηλωμένη σύνδεση RPC. 6. Ο resolver της πλευράς του πελάτη αποθηκεύει (caches) την αντιστοίχηση και επιστρέφει τη Ενεργοποίηση αντικειμένων CORBA 1. Με την παραλαβή της αίτησης ::bind(), το ORB της πλευράς του πελάτη λέει σε ένα αρχείο locator να επιλέξει ένα μηχάνημα που υποστηρίζει το συγκεκριμένο αντικείμενο και αποστέλλει μια αίτηση στο ORB της πλευράς του εξυπηρέτη μέσω του TCP/IP. 2. Όταν ο εξυπηρέτης εκκινηθεί από το ORB της πλευράς του εξυπηρέτη, δημιουργείται από τον εξυπηρέτη ένα στιγμιότυπο του αντικειμένου, καλείται ο κατασκευαστής CORBA::Object και η μέθοδος BOA::create(). Μέσα στην BOA::create(), το BOA δημιουργεί ένα socket endpoint, στο αντικείμενο ανατίθεται ένα object ID, μοναδικό στον εξυπηρέτη, δημιουργείται μια αναφορά αντικειμένου που περιέχει τα ονόματα της διεπαφής και της υλοποίησης, το ID της αναφοράς και τη διεύθυνση του endpoint. Για πελάτες που μιλούν στο πρωτόκολλο IIOP, ο εξυπηρέτης δημιουργεί ένα Ιnteroperable Object Reference (IOR) που περιέχει το όνομα ενός μηχανήματος, έναν αριθμό θύρας TCP/IP, και ένα key αντικειμένου. To BOA δηλώνει την αναφορά αντικειμένου στο ORB. 3. Όταν η αναφορά του αντικειμένου επιστραφεί στην πλευρά του εξυπηρέτη, το proxy εξάγει τη διεύθυνση του endpoint και ανοίγει μια socket σύνδεση με τον εξυπηρέτη. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 55 από 163

56 DCOM σύνδεση RPC στο proxy αντικειμένων. Αυτό επιτρέπει στο proxy αντικειμένων να συνδεθεί το ίδιο και τα proxies διεπαφών που δημιουργεί σε ένα RPC κανάλι το οποίο είναι συνδεδεμένο στον εξαγωγέα αντικειμένων. 1. Με την παραλαβή της κλήσης - >get(), το proxy διεπαφών κάνει marshal τις παραμέτρους στη μορφή Network Data Representation (NDR). 2. Το κανάλι RPC στέλνει την αίτηση τον στόχο εξαγωγέα αντικειμένων που καθορίστηκε από την RPC σύνδεση (OXID). 3. Η υποδομή RPC της πλευρά του εξυπηρέτη βρίσκει το στόχο stub διεπαφών βασιζόμενο στο IPID που βρίσκεται στην RPC επικεφαλίδα (header). 4. Μετά την κλήση της πραγματικής μεθόδου στο αντικείμενο του εξυπηρέτη, το stub διεπαφών κάνει marshal τις τιμές επιστροφής στη μορφή NDR. 5. Με την παραλαβή της κλήσης - >QueryInterface(), το proxy αντικειμένων καλεί τη μέθοδο IRemUnknown::RemQueryInterface στο αντικείμενο OXID στο στόχο εξαγωγέα αντικειμένων. Στη συνέχεια το αντικείμενο OXID καλεί την τη μέθοδο QueryInterface() σε (ίσως πολλαπλές) διεπαφές μέσα στον εξαγωγέα. 6. Με την παραλαβή της κλήσης - >Release(), το proxy αντικειμένων καλεί την μέθοδο IRemUnknown::RemRelease() στο αντικείμενο OXID στο στόχο εξαγωγέα αντικειμένων. Το αντικείμενο OXD στη συνέχεια καλεί τη μέθοδο Release() σε (ίσως πολλαπλές) διεπαφές μέσα στον εξαγωγέα. Ενεργοποίηση αντικειμένων Κλήση μεθόδων Πίνακας 3: Περιγραφή του χαμηλότερου επιπέδου CORBA 1. Με την παραλαβή της κλήσης - >get(), το proxy κάνει marshal τις παραμέτρους στη μορφή Common Data Representation (CDR). 2. Η αίτηση αποστέλλεται στον εξυπηρέτη στόχο μέσω της socket σύνδεσης 3. Ο skeleton στόχος αναγνωρίζεται είτε από το reference ID είτε από το object_key. 4. Μετά την κλήση της πραγματικής μεθόδου στο αντικείμενο του εξυπηρέτη, το skeleton κάνει marshal τις τιμές επιστροφής στη μορφή CDR. Το πρωτόκολλο επικοινωνίας του DCOM βασίζεται κυρίως στην τυποποίηση OSF DCE RPC με κάποιες επεκτάσεις. Αυτές περιλαμβάνουν τις απομακρυσμένες αναφορές αντικειμένων, μία διεπαφή IRemUnknown για την βελτιστοποίηση της απόδοσης των Σελίδα 56 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

57 απομακρυσμένων κλήσεων μεθόδων της IUnknown και ένα pinging πρωτόκολλο. Η διαδικασία του pinging επιτρέπει σε ένα αντικείμενο εξυπηρέτη να ακυρώνει απομακρυσμένες αναφορές αντικειμένων όταν ένας απομακρυσμένος πελάτης σταματά ανώμαλα. Όταν ένας πελάτης αποκτά έναν δείκτη διεπαφής για ένα απομακρυσμένο αντικείμενο για πρώτη φορά, ο κώδικας ping στη μηχανή του πελάτη προσθέτει το αντικείμενο σε μια ομάδα ping και στέλνει περιοδικά ένα ping στο μηχάνημα του εξυπηρέτη για του γνωστοποιήσει ότι ο πελάτης τρέχει ακόμα. Αν χαθεί ένας προκαθορισμένος αριθμός από συνεχόμενα pings, σημαίνει ότι ο πελάτης έχει σταματήσει ανώμαλα και ότι οι αναφορές αντικειμένων που έχει κρατήσει μπορούν να απελευθερωθούν. Για τη βελτιστοποίηση της απόδοσης, τα pings μπορεί να καταργηθούν όταν χρειάζεται για να μειωθεί η κίνηση στο δίκτυο. Σχήμα 12: Βήματα του DCOM στο χαμηλότερο επίπεδο. Σχήμα 13: Βήματα του CORBA στο χαμηλότερο επίπεδο. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 57 από 163

58 5.5. Συμπέρασμα Οι βήμα προς βήμα περιγραφές των τριών επιπέδων έδειξαν ότι οι αρχιτεκτονικές του DCOM και του CORBA/Orbix είναι παρόμοιες. Και οι δύο παρέχουν μια υποδομή κατανεμημένων αντικείμενων για διαφανείς ενεργοποιήσεις και πρόσβαση σε απομακρυσμένα αντικείμενα. Ο Πίνακας 4 συνοψίζει τους όρους και τις οντότητες των δύο αρχιτεκτονικών. Πρέπει να σημειωθεί ότι πολλές από τις αντιστοιχίες είναι κατά προσέγγιση. Οι κύριες διαφορές τους επίσης συνοψίζονται παρακάτω: 1. Πρώτον, το DCOM υποστηρίζει αντικείμενα με πολλαπλές διεπαφές και παρέχει μια στάνταρ μέθοδο QueryInterface() για την περιήγηση μεταξύ των διεπαφών. Αυτό επίσης εισάγει και την ιδέα ενός proxy/stub αντικειμένου να φορτώνει δυναμικά πολλαπλά proxies/stubs διεπαφών στο επίπεδο των απομακρυσμένων διαδικασιών. Τέτοιες έννοιες δεν υπάρχουν στο CORBA. 2. Δεύτερον, κάθε διεπαφή του CORBA κληρονομείται από το CORBA::Object, ο κατασκευαστής του οποίου κάνει κοινές ενέργειες, όπως τη δήλωση των αντικειμένων, τη δημιουργία αναφορών αντικειμένων, δημιουργία στιγμιοτύπων του skeleton, κτλ. Στο DCOM, τέτοιες ενέργειες γίνονται είτε από τα προγράμματα του εξυπηρέτη ή διαχειρίζονται δυναμικά από το σύστημα του περιβάλλοντος χρόνου εκτέλεσης. 3. Τρίτον, το πρωτόκολλο επικοινωνίας του DCOM είναι στενά συνδεδεμένο με το RPC, ενώ του CORBA δεν είναι. Τέλος πρέπει να σημειωθεί ότι η τυποποίηση του DCOM περιέχει πολλές λεπτομέρειες που θεωρούνται ως θέματα υλοποίησης και δεν τυποποιούνται στο CORBA. Ως αποτέλεσμα, πρέπει να χρησιμοποιείται σε πολλά σημεία μια υλοποίηση του CORBA (όπως είναι το Orbix) για επιτευχθούν λειτουργικότητες που το DCOM έχει ενσωματωμένες. DCOM Κορυφαίο Επίπεδο: Αρχιτεκτονική Προγραμματισμού CORBA Κοινή βασική κλάση IUnknown CORBA::Object Αναγνωριστής διεπαφής CLSID Όνομα διεπαφής Ενεργοποίηση αντικειμένου στην πλευρά του πελάτη CoCreateInstance() Κλήση μεθόδου / bind() Handle αντικειμένου Δείκτης αντικειμένου Αναφορά αντικειμένου Μεσαίο Επίπεδο: Αρχιτεκτονική Απομακρυσμένων Διαδικασιών Όνομα αντιστοίχησης της υλοποίησης Registry Implementation Repository Τύπος πληροφοριών για τις μεθόδους Type library Interface Repository Εύρεση υλοποίησης SCM ORB Ενεργοποίηση υλοποίησης SCM OA Stub πελάτη proxy Stub/proxy Stub εξυπηρέτη Stub Skeleton Σελίδα 58 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

59 DCOM Χαμηλό Επίπεδο: Αρχιτεκτονική Πρωτοκόλλου Επικοινωνίας Resolver του endpoint του εξυπηρέτη OXID resolver ORB Endpoint του εξυπηρέτη Εξαγωγέας αντικειμένων ΟΑ CORBA Αναφορά αντικειμένου OBJREF IOR (ή αναφορά αντικειμένου) Δημιουργία αναφοράς αντικειμένου Εξαγωγέας αντικειμένων ΟΑ Μορφή marshaling δεδομένων NDR CDR Αναγνωριστής στιγμιοτύπου διεπαφής IPID Object_key Πίνακας 4: Σύνοψη αντίστοιχων όρων και οντοτήτων Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 59 από 163

60

61 6. COM+ (Component Services) Περιγραφή Το COM+ είναι η εξέλιξη του Component Object Model (COM) και του Microsoft Transaction Server (MTS) [8], [12], [14], [54]. Το COM+ μπορεί να επεκτείνει εφαρμογές που υλοποιήθηκαν χρησιμοποιώντας τα COM, MTS και άλλες τεχνολογίες που βασίζονται σε COM. Το COM+ διαχειρίζεται πολλές από τις λειτουργίες διαχείρισης πόρων τις οποίες μέχρι τώρα οι προγραμματιστές έπρεπε να αναπτύξουν, όπως η κατανομή των νημάτων (thread allocation) και η ασφάλεια. Που εφαρμόζεται Το COM+ μπορεί να χρησιμοποιηθεί για την ανάπτυξη εταιρικών, κρίσιμων, κατανεμημένων εφαρμογών που βασίζονται στο λειτουργικό σύστημα Microsoft Windows Σε ποιους προγραμματιστές απευθύνεται Το COM+ είναι σχεδιασμένο πρωταρχικά για τους προγραμματιστές της C++ και της Microsoft Visual Basic. Μπορεί επίσης να χρησιμοποιηθεί για να διαχειριστεί και να εγκαταστήσει εφαρμογές. Απαιτήσεις χρόνου εκτέλεσης (run-time) Είναι ενσωματωμένο στο λειτουργικό σύστημα και απαιτεί τα Windows Οι εφαρμογές COM+ μπορούν επίσης να τρέξουν σε πελάτες (clients) Windows 98 και Microsoft Windows NT Εισαγωγή Η κατασκευή λογισμικού που βασίζεται σε συστατικά είναι πια πολύ πιο απλή χάρη στην επέκταση του COM, το COM+. Το COM+ παρέχει ένα περιβάλλον χρόνου εκτέλεσης (run-time) και υπηρεσίες που χρησιμοποιούνται εύκολα από οποιαδήποτε γλώσσα ή εργαλείο προγραμματισμού και επιτρέπει εκτεταμένη διαλειτουργικότητα μεταξύ συστατικών, ανεξάρτητα από τον τρόπο που έχουν υλοποιηθεί Ανασκόπηση Η βασική ιδέα του αντικειμενοστραφούς (object-oriented) λογισμικού είναι ότι ένα πρόγραμμα μπορεί να εκφραστεί με βάση αντικείμενα και ενέργειες που μπορούν να εκτελέσουν αυτά τα αντικείμενα. Σε ένα αφαιρετικό επίπεδο τα αντικείμενα είναι έννοιες που μπορεί να καταλάβει ο χρήστης. Για παράδειγμα σε ένα Βοήθημα Διαπροσωπικής Επικοινωνίας, τα κουμπιά, τα παράθυρα, οι μπάρες, οι λέξεις, τα μηνύματα και τα πλαίσια κειμένου είναι αντικείμενα. Καθώς προχωρά ο σχεδιασμός και η υλοποίηση, ορίζονται πρόσθετοι τύποι αντικειμένων που είναι πιο κατανοητοί σε έναν προγραμματιστή. Μια κλάση (class) είναι ένας τύπος αντικειμένου που ορίζεται βάσει της κατάστασης και της συμπεριφοράς του. Η κατάσταση εκφράζεται από ένα σύνολο ιδιοτήτων (properties). Οι τιμές αυτών των ιδιοτήτων αποτελούν την κατάσταση ενός αντικειμένου, αλλά το σύνολο των ιδιοτήτων είναι το ίδιο για όλα τα αντικείμενα μιας συγκεκριμένης κλάσης. Η συμπεριφορά καθορίζεται από δημόσιες μεθόδους (public methods) τις οποίες μπορούν να Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 61 από 163

62 καλέσουν οι πελάτες (clients) του αντικειμένου για να μεταβάλλουν την κατάστασή του. Ο μόνος τρόπος για να αλληλεπιδράσουν οι πελάτες με το αντικείμενο είναι μέσω των ιδιοτήτων και των μεθόδων του. Πρέπει να σημειωθεί ότι οι ιδιότητες και οι μέθοδοι δεν δίνουν πληροφορία για το πως έχει υλοποιηθεί η κλάση και, στην ιδανική περίπτωση, οι πελάτες δεν θα χρειαστεί ποτέ να ξέρουν τίποτα για την υλοποίηση. Πολλές φορές κάποιες ομάδες από μεθόδους χρησιμοποιούνται από περισσότερες από μία κλάσεις. Μπορεί κανείς να εκμεταλλευτεί αυτήν την κοινή συμπεριφορά ορίζοντας διεπαφές (interfaces). Μια διεπαφή είναι απλά ένας ορισμός από μία ομάδα συσχετιζόμενων ιδιοτήτων και μεθόδων, χωρίς την υλοποίηση. Οι διεπαφές υλοποιούνται από κλάσεις και είναι ένα δυνατό εργαλείο για την επαναχρησιμοποίηση. Ας πούμε ότι έχουμε δύο κλάσεις, την Α και τη Β, που υλοποιούν την ίδια διεπαφή IAddress. Επειδή η αλληλεπίδραση με τα αντικείμενα γίνεται μέσω public διεπαφών, ένας πελάτης που έχει έναν δείκτη στην IAddress, δεν χρειάζεται να γνωρίζει αν μιλά σε ένα στιγμιότυπο της κλάσης Α ή της κλάσης Β, ούτε καν την ύπαρξη των κλάσεων Α και Β. Επίσης, οι κλάσεις Α και Β μπορούν να αγνοούν την ύπαρξη η μία της άλλης. Αυτή η δυνατότητα να αντιμετωπίζονται πολλαπλές κλάσεις αντικειμένων σαν να ήταν ο ίδιος τύπος είναι γνωστή ως πολυμορφισμός. Μια σημαντική σχέση μεταξύ των κλάσεων είναι η κληρονομικότητα (inheritance) που χρησιμοποιείται για την κατασκευή ιεραρχίας κλάσεων. Σε αυτήν την σχέση μία κλάση μπορεί να κληρονομεί και τη διεπαφή και την υλοποίηση από μία άλλη. Άλλες σχέσεις μεταξύ των κλάσεων χρησιμοποιούνται για τον καθορισμό σύνθετων τύπων αντικειμένων. Τέλος, υπάρχει και η δυνατότητα της οργάνωσης των κλάσεων σε μονάδες που μπορούν να μεταφερθούν. Αντικειμενοστραφείς γλώσσες προγραμματισμού όπως η C++ και η Java προσφέρουν δυνατότητες υλοποίησης κλάσεων και διεπαφών. Οι γλώσσες διαφέρουν στο βαθμό που επιτρέπουν την πρόσβαση σε αντικείμενα ή σε public διεπαφές και που οι διεπαφές είναι ξεχωριστές οντότητες. Πάντως τα βασικά μπορούν γενικά να χρησιμοποιηθούν. Αν και οι αντικειμενοστραφείς γλώσσες προγραμματισμού προσφέρουν πολλά πλεονεκτήματα, δεν είναι από μόνες τους αρκετές για την ανάπτυξη κατανεμημένων εφαρμογών μεγάλης κλίμακας. Οι περισσότερες γλώσσες προγραμματισμού επικεντρώνονται στη δημιουργία μονοδιεργασιακών και μονογλωσσικών εφαρμογών. Όμως, μπορεί να μην είναι πάντα πρακτικό να γράφεται όλος ο κώδικας μιας εφαρμογής σε μία μόνο γλώσσα. Για παράδειγμα, θα μπορούσαμε να θέλουμε να γράψουμε τη διεπαφή χρήσης χρησιμοποιώντας ένα εργαλείο RAD (γρήγορης ανάπτυξης) και τις διεργασίες διαχείρισης δεδομένων σε C++ για να εκμεταλλευτούμε μια βιβλιοθήκη μαθηματικών συναρτήσεων. Θα πρέπει τότε να μάθει κανείς κάποιους μηχανισμούς επικοινωνίας μεταξύ διεργασιών ή μεταξύ μηχανημάτων για να κάνει την εφαρμογή να λειτουργεί σε διαφορετικά υπολογιστικά συστήματα. Επίσης, οι περισσότερες γλώσσες ενθαρρύνουν την χρήση της κληρονομικότητας της υλοποίησης, κάτι που μπορεί να δημιουργεί προβλήματα όταν βασικές κλάσεις τροποποιούνται. Μοντέλα αντικειμένων του επιπέδου του συστήματος όπως το COM απευθύνονται σε τέτοια προβλήματα. Το COM παρέχει ένα απλό, ισχυρό μοντέλο για την κατασκευή συστημάτων λογισμικού από αλληλεπιδρώντα αντικείμενα. Το COM ορίζει μια δυαδική τυποποίηση για τα αντικείμενα και για την επικοινωνία μεταξύ των αντικειμένων. Όλη η επικοινωνία με ένα αντικείμενο πρέπει να γίνεται μέσω διεπαφών και όλες οι επικοινωνίες πρέπει να φαίνονται ως απλές κλήσεις μεθόδων, ακόμα και αν το αντικείμενο προορισμού Σελίδα 62 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

63 βρίσκεται σε μια άλλη διεργασία ή σε ένα άλλο υπολογιστικό σύστημα. Υλοποιήσεις του COM παρέχουν τις βασικές υπηρεσίες που απαιτούνται για τον εντοπισμό, την ενεργοποίηση και την πρόσβαση σε αντικείμενα και συστατικά που εκθέτουν τις διεπαφές τους. Επειδή το COM ορίζει μια δυαδική τυποποίηση για το πως είναι τα αντικείμενα και οι διεπαφές στη μνήμη, το COM είναι ανεξάρτητο από γλώσσες προγραμματισμού. Οι πελάτες δεν ενδιαφέρονται (και κανονικά δε γνωρίζουν) ποια γλώσσα προγραμματισμού έχει χρησιμοποιηθεί για να γραφτούν τα συστατικά που χρησιμοποιούν. Μαζί, το COM και οι αντικειμενοστραφείς γλώσσες προγραμματισμού, παρέχουν απλοποίηση της διαδικασίας ανάπτυξης λογισμικού. Μπορούμε να κατασκευάσουμε συστήματα αλληλεπιδρώντων αντικειμένων COM και να γράψουμε συστατικά COM χρησιμοποιώντας αντικειμενοστραφείς γλώσσες προγραμματισμού. Όμως, αν και το μοντέλο προγραμματισμού COM φαίνεται απλό, η κατασκευή συστατικών και εφαρμογών βασισμένων σε συστατικά είναι συχνά δυσκολότερη από ότι θα έπρεπε. Ένα πρόβλημα είναι οι πολλές ασυμβατότητες μεταξύ του τι θεωρούν αντικείμενο τα εργαλεία και οι γλώσσες προγραμματισμού και του τι θεωρεί αντικείμενο το COM. Εννοιολογικά, αυτό κάνει πιο δύσκολη για τους προγραμματιστές την εκμάθηση της ανάπτυξης με βάση τα συστατικά. Επίσης, κάνει πολύ δύσκολη την ανάπτυξη συστατικών και υπηρεσιών του συστήματος που μπορούν πραγματικά να χρησιμοποιηθούν από οποιαδήποτε γλώσσα ή εργαλείο προγραμματισμού. Για παράδειγμα, πολλά εργαλεία και γλώσσες προγραμματισμού υποστηρίζουν μόνο ένα υποσύνολο από τα χαρακτηριστικά και τις δυνατότητες του COM, κι έτσι τα γενικώς προσβάσιμα συστατικά περιορίζονται στο κοινό υποσύνολο που υποστηρίζεται από τα εργαλεία (όπως το Automation) και πρέπει να εκθέτουν τη λειτουργικότητά τους με πολλαπλούς τρόπους. Ιδανικά, το COM θα έπρεπε να παρέχει συνεπή αντικείμενα που είναι εύκολα προσβάσιμα και συμβατά με την έννοια του αντικειμένου που ορίζεται από τις μοντέρνες αντικειμενοστραφείς γλώσσες και εργαλεία προγραμματισμού. Θα έπρεπε επίσης να διασφαλίζει ότι τα νέα APIs και υπηρεσίες θα μπορούσαν να καλεστούν εύκολα από οποιαδήποτε μεταγλωττισμένη ή μεταφρασμένη γλώσσα προγραμματισμού χωρίς πρόσθετη ανάπτυξη, δοκιμή ή τεκμηρίωση. Τέλος, όλα τα αντικείμενα, ανεξάρτητα από την προέλευσή τους, θα έπρεπε να έχουν το χαρακτηριστικό της διαλειτουργικότητας. Σε ένα συνηθισμένο συστατικό ή εφαρμογή γραμμένη σε C++, μεγάλα τμήματα του κώδικα δεν έχουν καμία σχέση με το προς επίλυση πρόβλημα. Υπάρχει κώδικας για την αρχικοποίηση υπηρεσιών, κώδικας για τη συνεργασία με το λειτουργικό σύστημα, κώδικας για την κυκλοφορία των πληροφοριών του συστήματος. Το μεγαλύτερο κομμάτι αυτού του κώδικα παραμένει το ίδιο από εφαρμογή σε εφαρμογή και από συστατικό σε συστατικό. Εργαλεία όπως ή Visual Basic αντλούν πολλή από τη χρησιμότητά τους κρύβοντας αυτόν τον κοινό κώδικα σε ένα περιβάλλον χρόνου εκτέλεσης (συγκεκριμένο για κάθε εργαλείο) και αφήνοντας τον προγραμματιστή να εστιάσει στον κώδικα που λύνει το πρόβλημα που τον απασχολεί. Πολλά πλαίσια και γεννήτριες εφαρμογών έχουν αναπτυχθεί για να παρέχουν παρόμοιες υπηρεσίες στους προγραμματιστές της C++. Υπάρχουν μειονεκτήματα στα περιβάλλοντα χρόνου εκτέλεσης και στα πλαίσια (frameworks) του κάθε εργαλείου: περιορίζουν τον προγραμματιστή στις δυνατότητες που υποστηρίζονται από αυτό το εργαλείο. Επίσης, υπάρχει μια σημαντική χρονική καθυστέρηση για να γίνει προσβάσιμη από τα περισσότερα εργαλεία μία νέα δυνατότητα του λειτουργικού συστήματος. Όμως, αν το λειτουργικό σύστημα παρέχει το περιβάλλον χρόνου εκτέλεσης, θα είναι δυνατό να γίνουν τα νέα χαρακτηριστικά διαθέσιμα σε όλα τα εργαλεία αμέσως. Επίσης, όταν χρησιμοποιούνται συστατικά γραμμένα σε πολλαπλά Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 63 από 163

64 εργαλεία, πιθανώς να είναι φορτωμένα στη μνήμη πολλαπλά περιβάλλοντα χρόνου εκτέλεσης, επιβαρύνοντας άσκοπα το χώρο που καταλαμβάνει στη μνήμη η εφαρμογή. Ένα περιβάλλον χρόνου εκτέλεσης που προσφέρεται από το λειτουργικό σύστημα θα πρέπει να είναι τελικά το μόνο περιβάλλον χρόνου εκτέλεσης που χρειάζεται. Με τα περιβάλλοντα χρόνου εκτέλεσης των διαφόρων εργαλείων προγραμματισμού, πρέπει να διασφαλίζεται ότι το κάθε ένα από αυτά τα περιβάλλοντα είναι εγκατεστημένο οπουδήποτε γίνεται χρήση κάποιου συστατικού που βασίζεται σε αυτό το περιβάλλον. Όμως ένα περιβάλλον εκτέλεσης που παρέχεται από το σύστημα θα εγκαθίσταται πάντα αυτόματα. Εκτός από την απλοποίηση της ανάπτυξης συστατικών, πολλά εργαλεία προγραμματισμού εισήγαγαν καινοτομικές δυνατότητες για να γίνει η ανάπτυξη εφαρμογών βασισμένων στο COM πιο εύκολη. Κάποια από αυτά τα χαρακτηριστικά ταιριάζουν καλύτερα στο επίπεδο του συστήματος. Για παράδειγμα η Active Template Library (ATL Βιβλιοθήκη Ενεργών προτύπων) εισήγαγε έναν μηχανισμό βασισμένο σε script για την απλοποίηση της δήλωσης (registration) των συστατικών. H Visual Basic εισήγαγε εύκολους στη χρήση μηχανισμούς πρόσβασης δεδομένων μέσω data-bound controls. Αυτά είναι χαρακτηριστικά τα οποία είναι χρήσιμα σε πολλά συστατικά. Ο Microsoft Transaction Server (MTS) εισήγαγε πολλά χαρακτηριστικά για να κάνει πιο εύκολη τη συγγραφή κλιμακούμενων και κατανεμημένων εφαρμογών. Εκτός από την υποστήριξη των συναλλαγών (transactions), ο MTS παρέχει και ένα περιβάλλον εκτέλεσης με υπηρεσίες διαχείρισης νημάτων (threads) και αντικειμένων. Οι προγραμματιστές μπορούν να γράφουν συστατικά υποθέτοντας ότι τα αντικείμενά τους θα προσπελαύνονται μόνο από έναν πελάτη τη φορά ο MTS αναλαμβάνει τα υπόλοιπα. Αυτό απλοποιεί κατά πολύ την ανάπτυξη των συστατικών. Ο MTS φανερώνει έναν περιορισμό της αρχιτεκτονικής του COM: Δεν υπάρχει τυποποιημένος μηχανισμός για την πρόσθεση εξωτερικών υπηρεσιών στο COM. Βέβαια, μπορεί κανείς να ορίζει διεπαφές και να γράφει συστατικά αλλά το πρόβλημα προκύπτει όταν θελήσει να παρέμβει στη διαδικασία ενεργοποίησης των αντικειμένων ή να παρακολουθήσει τις κλήσεις μεθόδων. Ο MTS διαχειρίζεται το registry έτσι ώστε να καλείται όταν δημιουργείται ένα αντικείμενο, και στη συνέχεια δημιουργεί ένα περιτύλιγμα που τοποθετείται μεταξύ των πελατών και των πραγματικών αντικειμένων. Αυτό δουλεύει καλά με τον MTS, αλλά δημιουργεί πρόβλημα όταν εμφανίζεται μία υπηρεσία που θέλει να κάνει το ίδιο πράγμα Γιατί COM+; Το COM είναι ένα αρκετά επιτυχημένο μοντέλο αντικειμένων, με υποστήριξη από μια μεγάλη γκάμα εργαλείων προγραμματισμού και μια γρήγορα αναπτυσσόμενη αγορά τρίτων κατασκευαστών για τα συστατικά. Όμως υπάρχουν περιθώρια και περιοχές που παίρνουν βελτίωση και το COM+ προτίθεται να καλύψει αυτές τις περιοχές. Οι πρωταρχικοί στόχοι του COM+ είναι: Να είναι ευκολότερη η κατασκευή των συστατικών COM. Να αντιμετωπιστούν θέματα-κλειδιά στην ανάπτυξη και την μεταφορά εφαρμογών βασισμένων στο COM. Να παρασχεθούν νέες υπηρεσίες στους προγραμματιστές του COM. Να κατοχυρωθεί ένας τυποποιημένος μηχανισμός επεκτασιμότητας για την ενσωμάτωση νέων καινοτομιών. Σελίδα 64 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

65 Τα δύο πρώτα σημεία ικανοποιούνται από το περιβάλλον χρόνου εκτέλεσης του COM+. Όπως φαίνεται στο Σχήμα 14, το περιβάλλον εκτέλεσης εξελίχθηκε από τη Microsoft για τη διευκόλυνση της συγγραφής αντικειμένων COM με συγκεκριμένες γλώσσες προγραμματισμού. Τα δύο τελευταία σημεία ικανοποιούνται από υπηρεσίες που έχουν βασιστεί στο περιβάλλον χρόνου εκτέλεσης του COM+, το οποίο εξελίχθηκε από το COM και τον MTS. Μαζί, το περιβάλλον χρόνου εκτέλεσης και οι υπηρεσίες είναι γνωστά ως COM+. Υπηρεσίες Συστατικών Κατανεμημένες Υπηρεσίες COM+ (1998) Πλουσιότερο περιβάλλον χρόνου εκτέλεσης και υπηρεσίες για όλες τις γλώσσες Java VM (1997) Διάφανο CΟΜ για Java ATL (1996) Διάφανο COM για C++ Visual Basic 4.0 (1995) Διάφανο COM για Visual Basic COM (1992) Σχήμα 14: Η εξέλιξη του COM+ IIS 4.0 / MTS 2.0 (1997) Συναλλαγές στο Internet, διαλειτουργικότητα MTS 1.0 (1996) Συναλλαγές, pooling DCOM (1996) Κατανομή, ασφάλεια Με το COM Class Factory DLL Register Reference Counting QueryInterface IDispatch Connection Points Type Info Methods Με το COM+ Class Factory DLL Register Reference Counting QueryInterface IDispatch Connection Points Metadata Methods Κανονική γραφή: Γράφονται από τον προγραμματιστή Έντονη γραφή: Το σύστημα παρέχει προκαθορισμένη υλοποίηση Σχήμα 15: Συγγραφή συστατικών Σήμερα ένας προγραμματιστής αντικειμένων βασισμένων στο COM (ή ο δημιουργός ενός εργαλείου ανάπτυξης σε COM), πρέπει να ανησυχεί για πολλά θέματα που δεν έχουν σχέση με την ουσιαστική λειτουργικότητα των συστατικών (βλέπε Σχήμα 15). Κάθε συστατικό θα πρέπει να περιέχει μια υλοποίηση της IUnknown για να παράσχει την αναφορά (reference counting) και τις υπηρεσίες της QueryInterface. Οι πελάτες ενός αντικειμένου πρέπει να χρησιμοποιούν σωστά το reference counting για διαχειρίζονται τον κύκλο ζωής (lifetime) του αντικειμένου και πρέπει να χρησιμοποιούν το QueryInterface για να έχουν πρόσβαση στα χαρακτηριστικά του αντικειμένου. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 65 από 163

66 Επίσης, κάθε συστατικό χρειάζεται ένα εργοστάσιο κλάσεων (class factory) που γνωρίζει πώς να δημιουργεί αντικείμενα ενός συγκεκριμένου τύπου, και ο απαιτούμενος κώδικας πρέπει να πακετάρεται έτσι ώστε το συστατικό να αρχικοποιείται σωστά στο σύστημα κατά τη διάρκεια της εκτέλεσης. Επίσης, τα συστατικά πρέπει να παρέχουν πληροφορίες δήλωσης (registration). Οι νέες διεπαφές πρέπει να περιγράφονται μέσω της IDL (Interface Definition Language Γλώσσα Ορισμού Διεπαφών), η οποία κατασκευάζει proxy/stub DLLs και type libraries. Αν ένα συστατικό πρέπει να προσπελαστεί από scripting γλώσσες, πρέπει να υλοποιεί την υποστήριξη Automation μέσω του IDispatch και άλλων διεπαφών. Τα συστατικά που θέλουν να πυροδοτήσουν γεγονότα (fire events) και πελάτες που θέλουν να λάβουν γεγονότα πρέπει να υλοποιούν τις διεπαφές IConnectionPoint. Πρέπει ακόμη κάποιος να σκεφτεί αν το εργαλείο προγραμματισμού που χρησιμοποιεί συμμορφώνεται στη δυαδική τυποποίηση για τα αντικείμενα στη μνήμη. Ο περισσότερος κώδικας για την υλοποίηση των IUknown, IDispach, των γεγονότων (events), των εργοστασίων κλάσεων (class factories) και του πακεταρίσματος των συστατικών είναι σχεδόν όμοιος για όλα τα συστατικά. Έτσι ο πρώτος στόχος του COM+ είναι να παράσχει ένα περιβάλλον χρόνου εκτέλεσης που θα προσφέρει μια προκαθορισμένη υλοποίηση για τη διαχείριση αυτών των θεμάτων για τα πιο κοινά σενάρια (βλέπε Σχήμα 15). Οι προγραμματιστές υλοποιούν μερικά κλάσεις για να διαχειριστούν τη λογική της εφαρμογής και να παράσχουν πληροφορίες για τα χαρακτηριστικά των κλάσεων. Το περιβάλλον εκτέλεσης του COM+ κάνει τα υπόλοιπα. Δε χρειάζεται ειδικός κώδικας για τη δήλωση των κλάσεων στο registry, για την περιγραφή της λειτουργικότητάς τους στους πελάτες, για την παροχή ενός εργοστασίου κλάσεων για τη δημιουργία των αντικειμένων, για τη διαχείριση του κύκλου ζωής των αντικειμένων ή για οτιδήποτε δεν είναι άμεσα συσχετισμένο με τη λογική της εφαρμογής που περιλαμβάνει το συστατικό. Αν η υλοποίηση του περιβάλλοντος εκτέλεσης δεν ικανοποιεί τις ανάγκες του προγραμματιστή, μπορεί πάντα να χρησιμοποιήσει τις παραδοσιακές τεχνικές του COM για την κατασκευή προσαρμοσμένων υλοποιήσεων. Διάφορα εργαλεία προγραμματισμού και ειδικά η Visual Basic ήδη έχει αντιμετωπίσει αυτά τα θέματα για τον κατασκευαστή του συστατικού και για τον πελάτη του συστατικού. Το πλεονέκτημα ενός περιβάλλοντος εκτέλεσης που παρέχεται από το σύστημα είναι ότι το ίδιο περιβάλλον μπορεί να χρησιμοποιηθεί από όλα τα συστατικά, άσχετα από τη γλώσσα ανάπτυξης. Αυτό προσφέρει βελτιώσεις στην απόδοση και πιο συνεπή συμπεριφορά των συστατικών. Αλλά τα πραγματικά πλεονεκτήματα του COM+ για την ανάπτυξη με εργαλεία όπως η Visual Basic είναι οι υπηρεσίες και οι μηχανισμοί επέκτασης που θα περιγραφούν αργότερα. Ένας δεύτερος στόχος του COM+ είναι να διευθετηθούν βασικά θέματα στην ανάπτυξη και μεταφορά εφαρμογών βασισμένων σε COM. Πολλές δυσκολίες που συναντώνται κατά τη δημιουργία των συστατικών σχετίζονται με τον ορισμό νέων διεπαφών μέσω της IDL. Με το COM+ οι διεπαφές ορίζονται χρησιμοποιώντας κοινές γλώσσες προγραμματισμού. Δεν χρειάζεται να είναι κάποιος ειδικός στην IDL ή να διαχειρίζεται ξεχωριστά αρχεία ορισμού διεπαφών. Τα εργαλεία προγραμματισμού χρησιμοποιούν το περιβάλλον εκτέλεσης του COM+ για να εξάγουν metadata που περιγράφουν τις διεπαφές. Τα metadata είναι αρκετά για την αυτόματη δημιουργία proxies και stubs, κάτι που υποβοηθά τη διαδικασία κατασκευής και εγκατάστασης των συστατικών. Επίσης, το COM+ ορίζει ένα απλούστερο και πιο συμπαγές μοντέλο για τη δήλωση, την εγκατάσταση και τις Εκδόσεις των συστατικών. Αυτό το μοντέλο στηρίζεται στις Σελίδα 66 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

67 υπηρεσίες downloading του Win32, στα πακέτα του MTS, στο class store των Windows NT και στα διαχειριστικά εργαλεία του COM, και συνδυάζει όλα αυτά σε μια συνεπή και εύκολη στη χρήση υπηρεσία. Το πακέτο (package) είναι μια απλή, εγκαταστάσιμη μονάδα κώδικα που περιέχει μία ή περισσότερες κλάσεις. Ένα πακέτο μπορεί επίσης να αντιπροσωπεύει μια έννοια όπως ένας χρήστης ή ένα μηχάνημα. Όλη η πληροφορία μπορεί να συντηρηθεί από τα εργαλεία του προγραμματιστή ή από το διαχειριστή του συστήματος. Δε χρειάζεται η συγγραφή κώδικα για τη δημιουργία πληροφορίας δηλώσεων (registration). Η υπηρεσία δηλώσεων παρέχει έναν μηχανισμό για την παράκαμψη της έκδοσης μιας κλάσης που βρίσκεται σε ένα πακέτο. Αυτό βοηθά στην επίλυση ενός από τα πιο ενοχλητικά θέματα των εφαρμογών των συστατικών. Ας πούμε για παράδειγμα, ότι η εφαρμογή Α χρησιμοποιεί την έκδοση 1.0 του συστατικού Ψ και λειτουργεί καλά, αλλά η εφαρμογή Β εγκαθίσταται με την έκδοση 2.0 του συστατικού Ψ και επίσης λειτουργεί καλά, αλλά η εφαρμογή Α σταματά να δουλεύει. Με το περιβάλλον εκτέλεσης του COM+, μπορούν να χρησιμοποιηθούν και οι δύο Εκδόσεις του συστατικού Ψ, η έκδοση 1.0 για την εφαρμογή Α και η έκδοση 2.0 για την εφαρμογή Β. Οι προγραμματιστές μπορούν εύκολα να εκμεταλλευτούν αυτές τις υπηρεσίες. Για καινούρια συστατικά θα πρέπει απλά να γραφούν οι κλάσεις, να δοθούν τα χαρακτηριστικά των κλάσεων και να αφεθεί το περιβάλλον εκτέλεσης του COM+ να κάνει τα υπόλοιπα. Η περισσότερη δουλειά για τη μεταφορά των παλιών συστατικών στο μοντέλο COM+ θα είναι στην ουσία η διαγραφή τμημάτων κώδικα. Τα συστατικά που θα προκύψουν θα είναι συστατικά COM και θα λειτουργούν με κάθε εργαλείο που μπορεί να χρησιμοποιήσει συστατικά COM, αλλά αυτά τα νέα συστατικά θα είναι πιο εύκολο να γραφτούν και να εγκατασταθούν από τα παραδοσιακά συστατικά COM Επικοινωνία με γεγονότα (events) Ένας ΕΚΔΟΤΗΣ (Publisher) είναι οποιοδήποτε πρόγραμμα κάνει τις COM κλήσεις που ξεκινούν γεγονότα (events) και ένας ΣΥΝΔΡΟΜΗΤΗΣ (Subscriber) είναι ένα συστατικό COM+ που λαμβάνει τις COM κλήσεις που αντιπροσωπεύουν γεγονότα από έναν Εκδότη. Ο Συνδρομητής υλοποιεί μία διεπαφή ως ένας εξυπηρέτης COM. Ο Εκδότης κάνει κλήσεις σε αυτόν σαν ένας πελάτης COM [26], [55]. Η σύνδεση προγραμμάτων που παρέχουν πληροφορίες που αλλάζουν με το χρόνο (Εκδότες) με προγράμματα που θέλουν να λαμβάνουν ειδοποιήσεις για αυτές τις (Συνδρομητές) ήταν για καιρό μια πρόκληση στην κατασκευή κατανεμημένων εφαρμογών. Η υπηρεσία γεγονότων του COM+ παρέχει μια υποδομή που κάνει εύκολη την έκδοση και τη συνδρομή σε δεδομένα Έκδοση (Publishing) και Συνδρομή (Subscribing) Ένα πρόγραμμα ανιχνεύει μια αλλαγή σε κάποια δεδομένα ή σε κάποια κατάσταση που θεωρεί ότι τα άλλα προγράμματα πρέπει να τη γνωρίζουν. Για παράδειγμα, ένα Εικονικό Πληκτρολόγιο βλέπει το πάτημα ενός πλήκτρου, ένα πρόγραμμα παρακολούθησης του χρηματιστηρίου βλέπει την αλλαγή σε μια τιμή μετοχής, ένα πρόγραμμα παρακολούθησης του καιρού βλέπει αλλαγές στις βαρομετρικές μετρήσεις από ένα απομακρυσμένο αισθητήρα ή ένα πρόγραμμα ιατρικής παρακολούθησης βλέπει ότι η πίεση του αίματος ενός ασθενή έχει υπερβεί την αποδεκτή τιμή. Κάπου υπάρχουν άλλα προγράμματα που θα ήθελαν να ξέρουν για αυτές τις αλλαγές: Ένας συνθέτης ομιλίας θέλει να εκφωνήσει τη Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 67 από 163

68 λέξη που αντιστοιχεί στο πλήκτρο του Εικονικού Πληκτρολογίου που πατήθηκε, ένα πρόγραμμα χαρτοφυλακίου που πρέπει να αγοράσει μια μετοχή όταν αυτή φτάσει σε μια συγκεκριμένη τιμή, ένα πρόγραμμα συναγερμού που λέει στις ψαρόβαρκες να επιστρέψουν στο λιμάνι ή ένα πρόγραμμα παρακολούθησης του ασθενή που δίνει σήμα στο σταθμό των νοσοκόμων ότι ο ασθενής χρειάζεται φάρμακο. Οι έννοιες του πελάτη και του εξυπηρέτη γίνονται ομιχλώδεις σε σενάρια σαν αυτά κι έτσι εισάγουμε τη νέα ονοματολογία. Προγράμματα που παρέχουν ειδοποιήσεις σε άλλα προγράμματα, όπως το Εικονικό Πληκτρολόγιο, τα καλούμε "Εκδότες". Εφαρμογές όπως ο Συνθέτης Ομιλίας που λαμβάνουν δεδομένα από Εκδότες και δρουν ανάλογα με αυτά, τις καλούμε "Συνδρομητές". Όταν ο Εκδότης ανιχνεύει μια αλλαγή που αφορά τον Συνδρομητή, προκύπτει το πρόβλημα της ειδοποίησης του Συνδρομητή. Ο απλούστερος τρόπος είναι να "ρωτά" κάθε τόσο (polling) ο Συνδρομητής τον Εκδότη. Στην ορολογία του COM+, ο Εκδότης θα μπορούσε να δώσει στο Συνδρομητή μία διεπαφή και ο Συνδρομητής θα μπορούσε να καλεί περιοδικά μια μέθοδο σε αυτήν τη διεπαφή για να δει αν έχουν συμβεί αλλαγές, όπως φαίνεται στο Σχήμα Ο Συνδρομητής δημιουργεί ένα αντικείμενο Εκδότη. Εκδότης Συνδρομητές 2. Ο Συνδρομητής περιοδικά ρωτά για αλλαγές Σχήμα 16: "Ερωτήσεις" (polling) του Συνδρομητή Αυτή η στρατηγική είναι απλή στον προγραμματισμό, αλλά δεν είναι σωστή για πολλούς λόγους. Πρώτον, ο Συνδρομητής ξοδεύει πολύ χρόνο και ενέργεια ρωτώντας "Υπάρχουν αλλαγές;". Ο Εκδότης επίσης σπαταλά χρόνο και προσπάθεια απαντώντας "Όχι δεν υπάρχουν". Κάτι τέτοιο είναι απαράδεκτο από άποψη απόδοσης και ταχύτητας για την εφαρμογή. Δεύτερον, η τεχνική του polling εισάγει κάποια αναπόφευκτη καθυστέρηση μεταξύ του χρόνου που λαμβάνει χώρα η αλλαγή και του χρόνου που ο Συνδρομητής ρωτά. Κατά μέσο όρο, αυτή η καθυστέρηση είναι ίση με το μισό του μεσοδιαστήματος του polling (μεταξύ των ερωτήσεων). Καθώς μεγαλώνει το μεσοδιάστημα των ερωτήσεων για να ξοδεύονται λιγότεροι κύκλοι του επεξεργαστή, αυξάνει η καθυστέρηση. Αυτή η καθυστέρηση δεν είναι μόνο ένα μειονέκτημα από μόνη της, αλλά και το γεγονός ότι δεν είναι ντετερμινιστική (διαφέρει μεταξύ των κλήσεων) εισάγει ένα πρόβλημα στο σχεδιασμό των συστημάτων. Θα θέλαμε ο Εκδότης να ξεκινά τη διαδικασία ειδοποίησης όταν ανιχνεύει ενδιαφέρουσες αλλαγές. Στην ορολογία του COM, ο Συνδρομητής εφοδιάζει τον Εκδότη με μία διεπαφή και ο Εκδότης καλεί μια μέθοδο σε αυτή όταν συμβαίνει κάτι ενδιαφέρον. Αυτή είναι η προσέγγιση που χρησιμοποιούν τα ActiveX controls για να πυροδοτήσουν γεγονότα στις οντότητες που τα περιέχουν (containers), όπως φαίνεται στο Σχήμα 17. Εδώ το control είναι ο Εκδότης και η μονάδα που το περιέχει (container) είναι ο Συνδρομητής. Σελίδα 68 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

69 Αυτό καλείται στενά συνδεδεμένο γεγονός (tightly coupled event). Ο Συνδρομητής ξέρει ακριβώς από ποιον Εκδότη να ζητήσει ειδοποιήσεις (η μονάδα που τον περιέχει γνωρίζει το CLSID, ή τον αναγνωριστή της κλάσης ή το control) και το μηχανισμό για να συνδεθεί σε αυτό (τις διεπαφές IConnectionPointContainer και IConnectionPoint που εκτίθενται από το control). Ένα στενά συνδεδεμένο γεγονός δεν ταιριάζει όσο θα θέλαμε στη φιλοσοφία και το σχεδιασμό του ΟΔΥΣΣΕΑ μια και στη δική μας εφαρμογή απαιτείται να μην ξέρουν τα συστατικά την ύπαρξη το ένα του άλλου. Θα πρέπει να υπάρχει μεγαλύτερη ελευθερία και λιγότερες απαιτήσεις για την επικοινωνία μεταξύ τους. IConnectionPoint 1. Ο Συνδρομητής παρέχει μια διεπαφή ανάκλησης μέσω του σημείου σύνδεσης (connection point) Εκδότης (ActiveX control) Συνδρομητής (ActiveX Container) 2. Ο Εκδότης ειδοποιεί για τις αλλαγές χρησιμοποιώντας τη διεπαφή ανάκλησης Σχήμα 17: Ανακλήσεις ActiveX Για να λειτουργήσει ο μηχανισμός των γεγονότων, ένα στενά συνδεδεμένο γεγονός απαιτεί να τρέχουν συνέχεια και ο Εκδότης και ο Συνδρομητής. Και οι δύο πλευρές πρέπει να τρέχουν όταν ο Συνδρομητής (container) δίνει στον Εκδότη (control) τη διεπαφή ανάκλησης και επίσης όταν ο Εκδότης καλεί τη μέθοδο στη διεπαφή του Συνδρομητή. Στη δική μας περίπτωση, οι Συνδρομητές και οι Εκδότες δεν θα πρέπει να είναι τόσο στενά συνδεδεμένοι μια και κανείς δεν εγγυάται ούτε καν τη ύπαρξή τους σε κάθε στιγμή. Θα χρειάζεται Συνδρομητές και Εκδότες να μπορούν να αντικαθίστανται ή να καταργούνται χωρίς να απαιτείται επαναμεταγλώτισση ή επανεγκατάσταση όλης της εφαρμογής. Επίσης, θα παρουσιαστούν και ανάγκες ασύγχρονης επικοινωνίας συστατικών, κάτι που δεν είναι συμβατό με την απαίτηση να τρέχουν ταυτόχρονα οι Εκδότες και οι Συνδρομητές. Ένα άλλο πρόβλημα με τα στενά συνδεδεμένα γεγονότα είναι ότι ο Συνδρομητής πρέπει να ξέρει τον ακριβή μηχανισμό που ένας Εκδότης απαιτεί για να εγκαθιδρύει συνδρομές και αυτός ο μηχανισμός μπορεί να διαφέρει ριζικά από τον έναν Εκδότη στον άλλον. Για παράδειγμα, τα ActiveX controls χρησιμοποιούν το μηχανισμό του IConnectionPoint για να στήσουν το κύκλωμα ανακλήσεων και να παραδίδουν ειδοποιήσεις για τα γεγονότα τους. Ένας OLE server χρησιμοποιεί τη μέθοδο Advise στη διεπαφή IOleObject για να φτιάξει ένα κύκλωμα ανακλήσεων και να παραδίδει ειδοποιήσεις γεγονότων που σχετίζονται με embedding. Θα ήταν πολύ καλό να τυποποιηθεί ένας μηχανισμός σύνδεσης για τους Εκδότες και τους Συνδρομητές και να μπορεί κανείς να χρησιμοποιεί αυτόν το μηχανισμό σύνδεσης διαχειριστικά αντί να πρέπει να γράφει κώδικα για να έχει πρόσβαση σε αυτόν. Το τρίτο πρόβλημα του κλασσικού μηχανισμού γεγονότων είναι ότι δεν περιλαμβάνει μηχανισμούς για φιλτράρισμα ή αναχαίτιση (interception). Για παράδειγμα, θα Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 69 από 163

70 μπορούσαμε να έχουμε πολλά συστατικά μιας εφαρμογής να λειτουργούν παράλληλα και να πρέπει να μοιράζονται τον ίδιο χώρο μηνυμάτων και τον ίδιο μηχανισμό για την επικοινωνία μεταξύ τους. Αν ένα Εικονικό Πληκτρολόγιο ως Εκδότης ανακοίνωνε τη λέξη που ο χρήστης επέλεξε, και αυτή η λέξη αφού επεξεργαζόταν από ένα Συστατικό Μετάφρασης έπρεπε να παραδοθεί στον Συνθέτη Ομιλίας, πως θα ήξερε αυτό το τελευταίο συστατικό αν η λέξη είναι η πρωτογενής ή η μεταφρασμένη για να την εκφωνήσει; Επίσης, το Συστατικό Μετάφρασης πως θα απέφευγε να μεταφράσει την ίδια τη έξοδό του αφού αυτή θα την έβρισκε πάλι σαν είσοδο στον κοινό χώρο μηνυμάτων επικοινωνίας; Θα έπρεπε κάθε συστατικό να έχει την ικανότητα φιλτραρίσματος των γεγονότων που δέχεται ή που στέλνει και ιδανικά αυτή η διαδικασία θα έπρεπε να ρυθμίζεται διαχειριστικά. Μια λύση σε αυτό το πρόβλημα θα ήταν η αποθήκευση της πληροφορίας για το ταίριασμα των Εκδοτών και των Συνδρομητών εξωτερικά, αντί αυτή να αποθηκεύεται μέσα στα ίδια τα προγράμματα. ο Εκδότης θα διατηρούσε μια εξωτερική βάση δεδομένων που θα περιείχε μια λίστα με τα διάφορα γεγονότα για τα οποία ξέρει πώς να στέλνει ειδοποιήσεις. Οι Συνδρομητές θα διάβαζαν αυτή τη λίστα και θα επέλεγαν τα γεγονότα για τα οποία θέλουν να ειδοποιούνται. Ο Εκδότης θα διατηρούσε επίσης ένα είδος βάσης δεδομένων συνδρομών, κάτι σαν τις λίστες ηλεκτρονικής αλληλογραφίας, που θα περιείχε τα CLSIDs των Συνδρομητών που θέλουν να ειδοποιούνται για το κάθε γεγονός. Θα έπρεπε για όλα αυτά να υπάρχουν διαχειριστικά εργαλεία ή τα ίδια τα προγράμματα θα έπρεπε να ξέρουν πώς να διαχειρίζονται τις εγγραφές αυτών των βάσεων δεδομένων. Όταν λοιπόν ο Εκδότης θέλει να πυροδοτήσει ένα γεγονός, συνδέεται με τη βάση δεδομένων, βρίσκει τα CLSIDs όλων των ενδιαφερόμενων Συνδρομητών, δημιουργεί ένα νέο αντικείμενο για κάθε μια από τις ενδιαφερόμενες κλάσεις και καλεί μια μέθοδο σε αυτό το αντικείμενο. Ένα τέτοιο σύστημα θα ονομαζόταν σύστημα χαλαρά συνδεδεμένων γεγονότων αντί για στενά συνδεδεμένων γιατί η πληροφορία για το ποιος Συνδρομητής θέλει να ακούει ποιον Εκδότη θα συντηρούνταν σε μια κεντρική βάση δεδομένων αντί να είναι κλεισμένη στα ίδια τα προγράμματα. Αυτή η πολλά υποσχόμενη σχεδιαστική προσέγγιση έχει δύο παγίδες. Πρώτα, θα έπρεπε να αναπτύξουμε και να συντηρήσουμε τη βάση των γεγονότων και των συνδρομών και να γράψουμε όλον τον κώδικα για τον μηχανισμό πυροδότησης γεγονότων από την πλευρά του Εκδότη και για τα εργαλεία διαχείρισης. Δεύτερον, ακόμα και αν αναπτύσσαμε αυτήν την υποδομή η διαδικασία συνδρομών μας θα ήταν ακόμη διαφορετική από οποιουδήποτε άλλου κατασκευαστή. Οι Συνδρομητές θα έπρεπε να ξέρουν όχι μόνο τις συγκεκριμένες τεχνικές που απαιτούνται για να έχουν συνδρομή στα γεγονότα μας, αλλά και τους διάφορους μηχανισμούς που απαιτούνται από οποιονδήποτε άλλον Εκδότη τον οποίο θέλουν να ακούν και να είναι συμβατοί με αυτόν. Αυτό που θα θέλαμε πραγματικά θα ήταν να εκμεταλλευτούμε έναν τέτοιο μηχανισμό που θα τον προσέφερε το λειτουργικό σύστημα. Με αυτόν τον τρόπο θα είχαμε να γράψουμε πολύ λίγο κώδικα και η διαδικασία συνδρομών για κάθε κατασκευαστή θα ήταν η ίδια Υπηρεσίες γεγονότων του COM+ Η υπηρεσία γεγονότων του COM+ [26], είναι η υπηρεσία του λειτουργικού συστήματος που ασχολείται με το ταίριασμα και τη σύνδεση Εκδοτών και Συνδρομητών. Η αρχιτεκτονική της φαίνεται στο Σχήμα 18. Χρησιμοποιώντας την ορολογία του Σχήματος, ένα γεγονός αντιπροσωπεύει μία κλήση σε μία μέθοδο σε μία COM διεπαφή, που ξεκίνησε από έναν Εκδότη και παραδόθηκε από την υπηρεσία γεγονότων στον σωστό Συνδρομητή ή Συνδρομητές. Ο Εκδότης είναι Σελίδα 70 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

71 οποιοδήποτε πρόγραμμα κάνει τις κλήσεις που ξεκινούν γεγονότα και ο Συνδρομητής είναι ένα συστατικό COM+ που παραλαμβάνει τις COM κλήσεις που αντιστοιχούν σε γεγονότα από έναν Εκδότη. Ο Συνδρομητής υλοποιεί μια διεπαφή ως ένας εξυπηρέτης COM. Ο Εκδότης κάνει κλήσεις σε αυτήν ως πελάτης COM. Η μόνη αλλαγή από το κλασσικό COM είναι η υπηρεσία γεγονότων που μεσολαβεί, η οποία παρακολουθεί ποιοι Συνδρομητές θέλουν να παραλαμβάνουν τις κλήσεις και κατευθύνει τις κλήσεις σε αυτούς τους Συνδρομητές χωρίς να απαιτείται οποιαδήποτε γνώση για τον Εκδότη. 1. Δηλώνει Κλάση γεγονότος Κατάλογος COM+ 2. Δηλώνει (Event Class) (COM+ Catalog) 5. Διαβάζει τη λίστα των Συνδρομητών 3. Δημιουργεί Εκδότης 4. Πυροδοτεί ένα γεγονός Αντικείμενο γεγονότος Συνδρομητής 6. Παραλαμβάνει το γεγονός Σχήμα 18: Αρχιτεκτονική της υπηρεσίας Γεγονότων του COM+ Η πραγματοποίηση μιας απλής κλήσης γεγονότος λέγεται πυροδότηση του γεγονότος. Μπορούμε επίσης να χρησιμοποιούμε και τον όρο "Έκδοση" ως συνώνυμο της πυροδότησης. Η σύνδεση μεταξύ ενός Εκδότη και ενός Συνδρομητή αντιπροσωπεύεται από μία κλάση γεγονότος (event class). Μια κλάση γεγονότος είναι ένα συστατικό COM+ που συντίθεται από το σύστημα γεγονότων και περιέχει τις διεπαφές και τις μεθόδους που θα καλέσει ένας Εκδότης για να πυροδοτήσει γεγονότα και που ο Συνδρομητής πρέπει να υλοποιήσει αν θέλει να παραλαμβάνει γεγονότα. Οι διεπαφές και οι μέθοδοι που παρέχονται από μια κλάση γεγονότων λέγονται διεπαφές γεγονότων και μέθοδοι γεγονότων. Πληροφορούμε το COM+ ποιες διεπαφές και μεθόδους θέλουμε να περιέχει μια κλάση γεγονότων, δίνοντάς του μια βιβλιοθήκη τύπων (type library). Οι κλάσεις γεγονότων αποθηκεύονται στον κατάλογο του COM+ (COM+ Catalog), και τοποθετούνται εκεί είτε από τους ίδιους τους Εκδότες, είτε από διαχειριστικά εργαλεία. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 71 από 163

72 Ένας Συνδρομητής εκφράζει την επιθυμία του να παραλαμβάνει γεγονότα από έναν Εκδότη, δηλώνοντας στην υπηρεσία γεγονότων του COM+ μια συνδρομή. Η συνδρομή είναι μια δομή δεδομένων που δίνει στην υπηρεσία γεγονότων πληροφορίες σχετικά με τον παραλήπτη ενός γεγονότος. Καθορίζει για τον Συνδρομητή, από ποια κλάση γεγονότων και από ποια διεπαφή ή μέθοδο μέσα σε αυτήν την κλάση γεγονότων, θα λαμβάνει κλήσεις. Οι συνδρομές αποθηκεύονται στον κατάλογο του COM+, και τοποθετούνται εκεί είτε από τους ίδιους τους Συνδρομητές, είτε από διαχειριστικά εργαλεία. Οι μόνιμες (persistent) συνδρομές επιζούν μετά από μια επανεκκίνηση του συστήματος, ενώ οι προσωρινές (transient) δεν επιζούν. Όταν ένας Εκδότης θέλει να πυροδοτήσει ένα γεγονός, χρησιμοποιεί τις τυπικές συναρτήσεις δημιουργίας αντικειμένων, όπως η CoCreateInstance ή η CreateObject, για να δημιουργήσει ένα αντικείμενο από την επιθυμητή κλάση γεγονότων. Αυτό το αντικείμενο, γνωστό ως αντικείμενο γεγονότος, περιέχει την υλοποίηση του συστήματος γεγονότων για τη ζητούμενη διεπαφή. Στη συνέχεια, ο Εκδότης καλεί τη μέθοδο του γεγονότος που θέλει να πυροδοτήσει προς τους Συνδρομητές. Μέσα στην υλοποίηση της το σύστημα γεγονότων κοιτάζει τον κατάλογο του COM+ και βρίσκει όλους τους Συνδρομητές που έχουν δηλώσει συνδρομές σε αυτήν τη διεπαφή και μέθοδο. Όταν αυτή η διαδικασία ολοκληρωθεί, το σύστημα γεγονότων συνδέεται με κάθε Συνδρομητή (χρησιμοποιώντας οποιοδήποτε συνδυασμό άμεσης δημιουργίας, monikers ή queued components) και καλεί τη ζητούμενη μέθοδο. Επειδή πολύ συχνά περισσότεροι από έναν Συνδρομητές θέλουν ειδοποιήσεις για κάθε γεγονός, οι μέθοδοι των γεγονότων δεν μπορούν να χρησιμοποιούν οποιουδήποτε τύπου παραμέτρους εξόδου, αλλά πρέπει να επιστρέφουν μόνο HRESULTs επιτυχίας ή αποτυχίας. Με αυτόν τον τρόπο, κάθε πελάτης COM μπορεί ουσιαστικά να γίνει Εκδότης και κάθε συστατικό COM+ μπορεί να γίνει Συνδρομητής. Κανείς από τους δύο δεν χρειάζεται να ξέρει τίποτα για τις διαδικασίες που θα διεξαχθούν από το σύστημα των γεγονότων για να γίνει η σύνδεση Συνδρομές Η συνδρομή είναι μια δομή δεδομένων που βρίσκεται στον κατάλογο COM+. Οι ιδιότητες μιας συνδρομής είναι διαθέσιμες μέσω της διεπαφής IΕventSubscription. Πολλές από τις ιδιότητες μπορούν να τροποποιηθούν μέσω των Component Services, αλλά άλλες δεν είναι διαθέσιμες μέσω αυτής της διεπαφής χρήστη. Πρέπει να γράψει κανείς το δικό του διαχειριστικό πρόγραμμα για να προσπελάσει αυτές τις ιδιότητες. Οι συνδρομές συναντώνται σε δύο τύπους, μόνιμες και προσωρινές. Οι μόνιμες συνδρομές βρίσκονται στον κατάλογο COM+ και συνεχίζουν να υπάρχουν μετά από επανεκκινήσεις του συστήματος. Υπάρχουν ανεξάρτητα από τον κύκλο ζωής του αντικειμένου Συνδρομητή. Ένα πρόγραμμα Συνδρομητής δημιουργεί συχνά μια μόνιμη συνδρομή όταν εγκαθίσταται, και αφαιρεί τη συνδρομή όταν απεγκαθίσταται. Όταν ένας Εκδότης κάνει μια κλήση σε ένα αντικείμενο γεγονότος, αυτό ψάχνει όλες τις μόνιμες συνδρομές στον κατάλογο και δημιουργεί ένα καινούριο στιγμιότυπο για κάθε κλάση Συνδρομητή. Η διαδικασία δημιουργίας μπορεί να γίνει είτε άμεσα είτε μέσω moniker. Το ποιο αντικείμενο Συνδρομητή θα δημιουργηθεί καθορίζεται από τη ρύθμιση της ιδιότητας της συνδρομής SubscriberCLSID ή την SubscriberMoniker. Το αντικείμενο Συνδρομητή που δημιουργείται από μια μόνιμη συνδρομή απελευθερώνεται Σελίδα 72 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

73 πάντα μετά από κάθε κλήση γεγονότος, ανεξάρτητα από την επιτυχία ή αποτυχία της κλήσης και από τον αν ο Εκδότης απελευθερώνει το αντικείμενο γεγονότος. Μια προσωρινή συνδρομή απαιτεί οι κλήσεις να γίνονται σε ένα συγκεκριμένο υπάρχον αντικείμενο Συνδρομητή. Οι προσωρινές συνδρομές αποθηκεύονται επίσης στον κατάλογο COM+, αλλά δεν συνεχίζουν να υπάρχουν μετά από μια επανεκκίνηση του συστήματος. Η διεπαφή χρήσης του Component Services δεν προβλέπει τη δημιουργία προσωρινών συνδρομών. Πρέπει το πρόγραμμα του Συνδρομητή να δημιουργήσει μόνο του τη συνδρομή χρησιμοποιώντας τις προγραμματιστικές διαχειριστικές διεπαφές του COM+. Μια προσωρινή συνδρομή εγκαθίσταται προσθέτοντας μια νέα συνδρομή στο σύστημα γεγονότων και θέτοντας στην ιδιότητα SubscriberInterface τη διεπαφή IUnknown του αντικειμένου Συνδρομητή. Σε αυτήν την περίπτωση, ο μηχανισμός των γεγονότων δεν δημιουργεί ένα νέο στιγμιότυπο του αντικειμένου Συνδρομητή όταν πυροδοτεί ένα γεγονός, αλλά χρησιμοποιεί αυτό που έχει δοθεί. Το σύστημα γεγονότων θα κρατά ένα reference count για το αντικείμενο Συνδρομητή έως ότου ένα διαχειριστικό πρόγραμμα ή το ίδιο το αντικείμενο Συνδρομητή αφαιρέσει τον εαυτό του από το σύστημα γεγονότων. Επειδή δεν περιλαμβάνουν επαναλαμβανόμενες δημιουργίες και καταστροφές αντικειμένων, οι προσωρινές συνδρομές είναι πιο αποδοτικές από τις μόνιμες συνδρομές, αν και αίρουν όλα τα θέματα που έχουν να κάνουν με τον κύκλο ζωής και αποφεύγονται με τις μόνιμες συνδρομές. Οποιαδήποτε συνδρομή μπορεί να απενεργοποιηθεί. Αυτό γίνεται θέτοντας την ιδιότητα Enabled της συνδρομής στην τιμή FALSE. Μια απενεργοποιημένη συνδρομή δεν καλείται ποτέ από το σύστημα γεγονότων. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 73 από 163

74

75 7. Λεπτομερής Σχεδιασμός Έχοντας μελετήσει και επιλέξει τις τεχνολογίες αιχμής που θα αποτελέσουν τη βάση του Πλαισίου Σχεδιασμού και Ανάπτυξης Βοηθημάτων Διαπροσωπικής Επικοινωνίας "ΟΔΥΣΣΕΑΣ", και έχοντας υπόψη τη γενική περιγραφή του πλαισίου που προηγήθηκε, ακολουθούν κάποιες λεπτομέρειες του σχεδιασμού της υλοποίησής του. Μέθοδοι σχεδιασμού λογισμικού και εφαρμογών όπως η Ενοποιημένη Γλώσσα Μοντελοποίησης (Unified Modeling Language UML) [39], [43], και το εργαλείο μοντελοποίησης Microsoft Visual Modeler [37] που είναι ενσωματωμένο στο περιβάλλον προγραμματισμού Visual Studio της Microsoft, ήταν από τις μεθόδους που εξετάστηκαν ως υποψήφιες για την τεχνική (formal) περιγραφή των συστατικών που επρόκειτο να υλοποιηθούν. Τελικά, λόγω του μικρού μεγέθους των συστατικών αυτών αποφασίστηκε ότι δεν υπάρχει η ανάγκη χρησιμοποίησης τέτοιων μεθόδων σχεδιασμού και μοντελοποίησης. Τέτοιες μέθοδοι χρησιμοποιούνται μάλλον σε πιο μεγάλα προγράμματα και ολοκληρωμένες εφαρμογές όπου ο σχεδιασμός και η τεχνική περιγραφή δεν είναι δυνατό να γίνει με απλά λόγια ή σχήματα και απαιτείται πιο τεχνική (formal) μέθοδος για να δοθεί η ακριβής εικόνα του τι υλοποιείται. Σε τέτοιες περιπτώσεις τα εργαλεία αυτά επιτρέπουν την ακριβή περιγραφή, την αποφυγή ασαφειών, την απλοποίηση και την τυποποίηση της ορολογίας για την περιγραφή των λειτουργικοτήτων και της δομής των προγραμμάτων. Σε περιπτώσεις όμως σαν τη δική μας, όπου πρέπει να περιγραφούν μικρά και απλά τμήματα λογισμικού, θεωρείται ασύμφορη η χρήση τέτοιων εργαλείων. Η περιγραφή για παράδειγμα ενός δοκιμαστικού πρότυπου συστατικού, όπως αυτά που υλοποιούνται στα πλαίσια του ΟΔΥΣΣΕΑ, μπορεί να γίνει με ακρίβεια, σαφώς και χωρίς πολυπλοκότητα με τη χρήση απλού κειμένου και σχημάτων που αποσαφηνίζουν τη λειτουργικότητα και τη δομή του. Εκτός από τα συστατικά που παράγονται στα πλαίσια του ΟΔΥΣΣΕΑ, ο σχεδιασμός του πλαισίου αφορά και σε θέματα όπως ο καθορισμός των ομάδων χρηστών του ΟΔΥΣΣΕΑ, ο κύκλος ζωής του Βοηθήματος και η διαδικασία εγκατάστασής του. Όλα αυτά περιγράφονται στις ενότητες που ακολουθούν Ομάδες Χρηστών του ΟΔΥΣΣΕΑ Σχεδιαστές Κατασκευαστές Προγραμματιστές Βοηθημάτων Διαπροσωπικής επικοινωνίας και Συστατικών τους Πωλητές Συναρμολογητές Ολοκληρωτές Βοηθημάτων Διαπροσωπικής Επικοινωνίας Σχήμα 19: Ομάδες χρηστών του πλαισίου ΟΔΥΣΣΕΑΣ. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 75 από 163

76 Το Πλαίσιο Σχεδιασμού και Ανάπτυξης Εφαρμογών ΟΔΥΣΣΕΑΣ σχεδιάστηκε για δύο συγκεκριμένες κύριες ομάδες χρηστών: τους Προγραμματιστές και τους Πωλητές (Σχήμα 19). Για την τρίτη ομάδα χρηστών που είχε προταθεί από την αρχιτεκτονική ATIC του έργου ACCESS [16], [17], [18] τους Θεραπευτές ή βοηθούς των ΑΜΑ, το πλαίσιο ΟΔΥΣΣΕΑΣ είναι εντελώς διάφανο. Αν και οι Θεραπευτές απολαμβάνουν τα ευεργετικά αποτελέσματα του ΟΔΥΣΣΕΑ, όπως την ποικιλία των συστατικών, τις δυνατότητες προσαρμογής των Βοηθημάτων Επικοινωνίας και το χαμηλό κόστος τους, δεν έρχονται σε άμεση επαφή με το ίδιο το πλαίσιο και τις υπηρεσίες του και δε θεωρούνται άμεσοι χρήστες του. Θα αναλυθεί στη συνέχεια πως ακριβώς ο ΟΔΥΣΣΕΑΣ απευθύνεται στις δύο κύριες ομάδες χρηστών και ποιες είναι οι υπηρεσίες που τους προσφέρει. Σε επίπεδο Διαδικτύου, ο σχεδιασμός των υπηρεσιών του ΟΔΥΣΣΕΑ για αυτούς τους χρήστες, αλλά και για όλους τους ενδιαφερόμενους περιγράφεται στην ενότητα "ο ΟΔΥΣΣΕΑΣ στο Διαδίκτυο" Προγραμματιστές Αυτή η ομάδα χρηστών είναι τα πρόσωπα που σχεδιάζουν και υλοποιούν συστατικά Βοηθημάτων Διαπροσωπικής Επικοινωνίας, Μπορεί να πρόκειται για μεμονωμένα πρόσωπα ή για ολόκληρες εταιρίες ανάπτυξης λογισμικού ή ολοκληρωμένων συστημάτων επικοινωνίας. Ο ΟΔΥΣΣΕΑΣ αρχικά πρέπει να παρέχει σε αυτή την ομάδα χρηστών μια σειρά από τυποποιήσεις σχετικές με την ανάπτυξη λογισμικού. Πρόκειται να προταθούν τρεις τυποποιήσεις της Microsoft και είναι οι εξής: Τυποποίηση για την κατασκευή εφαρμογών των Windows 2000, που αφορά σε τεχνικές απαιτήσεις των εφαρμογών αυτών και απατήσεις για τη διεπαφή χρήσης της. Τυποποίηση του Μοντέλου Αντικειμένων και Συστατικών (COM) που αφορά στην τεχνική προγραμματισμού συστατικών. Τυποποίηση των Υπηρεσιών Συστατικών (COM+) που αφορά στις υπηρεσίες υποστήριξης της ανάπτυξης εφαρμογών με συστατικά και είναι ενσωματωμένες στο λειτουργικό σύστημα. Όλες αυτές οι τυποποιήσεις αναλύονται περισσότερο στα επόμενα κεφάλαια που αφορούν την Υλοποίηση του πλαισίου ΟΔΥΣΣΕΑΣ. Στη συνέχεια, ο ΟΔΥΣΣΕΑΣ πρέπει δίνει στους Προγραμματιστές πιο συγκεκριμένες τεχνικές οδηγίες για την κατασκευή συστατικών. Αυτές οι οδηγίες δεν είναι τόσο γενικές όσο οι τυποποιήσεις που προαναφέρθηκαν, αλλά αναφέρονται συγκεκριμένα στο πλαίσιο. Κύριος στόχος αυτών των οδηγιών είναι να παράγονται συστατικά που είναι συμβατά μεταξύ τους και μπορούν να επικοινωνήσουν ακολουθώντας συγκεκριμένο πρωτόκολλο επικοινωνίας και συγκεκριμένες προδιαγραφές. Μεγάλο μέρος αυτών των προδιαγραφών καθώς και το πρωτόκολλο επικοινωνίας καθορίζονται από τον ΟΔΥΣΣΕΑ και περιλαμβάνονται στην Υλοποίησή του. Παραδείγματα τέτοιων οδηγιών είναι ότι τα συστατικά θα πρέπει να είναι αρχεία βιβλιοθηκών δυναμικής σύνδεσης (Dynamic Link Libraries DLLs) [57], ώστε να είναι δυνατή η ενσωμάτωσή τους στον κατάλογο συστατικών των Windows 2000, να είναι φυσικά συμβατά με το λειτουργικό σύστημα Windows 2000, να χρησιμοποιούν συγκεκριμένο μοντέλο νημάτων (threading model), να χρησιμοποιούν καθορισμένη δομή και ονοματολογία στις κλάσεις και τα αντικείμενα που Σελίδα 76 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

77 περιέχουν, καθώς και να υλοποιούν συγκεκριμένες διεπαφές για την επικοινωνία τους με τα άλλα συστατικά. Οι διεπαφές επικοινωνίας που αναφέρθηκαν, ο σχεδιασμός και η υλοποίησή τους, είναι μία ακόμη υποχρέωση του πλαισίου ΟΔΥΣΣΕΑΣ. Ενσωματώνουν το προκαθορισμένο πρωτόκολλο επικοινωνίας μεταξύ των συστατικών του ΟΔΥΣΣΕΑ και επιτρέπουν τη χρήση της υποδομής και των υπηρεσιών του λειτουργικού συστήματος για τη διεκπεραίωση της επικοινωνίας αυτής. Πρέπει να αναπτυχθεί ένα αρχείο dll, το οποίο να περιέχει τη διεπαφή αυτή και να είναι τέτοιο ώστε να μπορεί να δηλωθεί ως μία κλάση γεγονότων (Event Class) στην υπηρεσία συστατικών των Windows Τέλος, στα πλαίσια του ΟΔΥΣΣΕΑ πρέπει να υλοποιηθούν συστατικά δοκιμών και αναφοράς για τους προγραμματιστές. Αυτά χρησιμεύουν ως πρότυπα για τον τρόπο που πρέπει να εφαρμόζονται οι τυποποιήσεις και να ακολουθούνται οι οδηγίες του ΟΔΥΣΣΕΑ και πρέπει να διατίθεται ελεύθερα ο κώδικάς τους ως δείγμα. Επίσης, τα συστατικά αυτά πρέπει να εξυπηρετούν σκοπούς δοκιμών και ελέγχου της συμβατότητας των συστατικών που αναπτύσσουν οι προγραμματιστές με το πλαίσιο ΟΔΥΣΣΕΑΣ Πωλητές Αυτή η ομάδα χρηστών περιλαμβάνει τους ανθρώπους που διαθέτουν τα Βοηθήματα Διαπροσωπικής Επικοινωνίας στους τελικούς τους χρήστες ΑΜΑ. Οι χρήστες αυτοί του ΟΔΥΣΣΕΑ δεν είναι απλά "Πωλητές" αλλά πρέπει να διαθέτουν τα κατάλληλα προσόντα και γνώσεις ώστε να μπορούν να αναγνωρίζουν σωστά τις ανάγκες των τελικών χρηστών των Βοηθημάτων, να τις αντιστοιχούν σε υπηρεσίες του συστήματος και να βρίσκουν τα κατάλληλα συστατικά του Βοηθήματος που παρέχουν αυτές τις υπηρεσίες. Τέλος πρέπει να έχουν και γνώσεις σχετικά με την εγκατάσταση εφαρμογών και τη διαχείριση των Component Services, μια και θα πρέπει να εκτελούν διαχειριστικές ενέργειες για την εγκατάσταση και ρύθμιση των Βοηθημάτων. Ο ΟΔΥΣΣΕΑΣ για τους Πωλητές έχει τη μορφή ενός Εγχειριδίου Χρήσης για τις Υπηρεσίες των Συστατικών (Component Services) των Windows 2000 και τις συγκεκριμένες δραστηριότητες που πρέπει αυτοί να εκτελούν, ώστε να εγκαθίστανται και να λειτουργούν σωστά τα Βοηθήματα Επικοινωνίας. Το Εγχειρίδιο Χρήσης περιλαμβάνεται στο αντίστοιχο κεφάλαιο της υλοποίησης του Πλαισίου Κύκλος ζωής του Βοηθήματος Επικοινωνίας Μέχρι τώρα, ο παραδοσιακός τρόπος ανάπτυξης Βοηθημάτων Διαπροσωπικής Επικοινωνίας και γενικά εφαρμογών για υπολογιστές, ήταν οι προγραμματιστές να εργάζονται απομονωμένοι και χωριστά. Κάθε κατασκευαστής είχε μια ομάδα σχεδιαστών και προγραμματιστών οι οποίοι υλοποιούσαν μια ιδέα (ή ιδέες) για προϊόντα που βασίζονταν στην κατάλληλη έρευνα αγοράς και τη μελέτη των αναγκών των χρηστών. Η Υλοποίηση των προϊόντων προχωρούσε μέχρι το τέλος για την παραγωγή ολοκληρωμένων Βοηθημάτων και μονολιθικών εφαρμογών. Το εξειδικευμένο υλικό (συσκευές εισόδου εξόδου, μηχανήματα επικοινωνίας) και το λογισμικό προέρχονταν για κάθε σύστημα από τον ίδιο κατασκευαστή με μικρή ή καθόλου ευελιξία και προβλήματα συμβατότητας με προϊόντα άλλων κατασκευαστών (Σχήμα 20). Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 77 από 163

78 Μελέτες αναγκών των χρηστών Έρευνες αγοράς Συγκεκριμένη ιδέα για προϊόν Συγκεκριμένη ιδέα για προϊόν Α ν τ α λ λ α γ ή π λ η ρ ο φ ο ρ ι ώ ν Οι σχεδιαστές και κατασκευαστές εργάζονται ανεξάρτητα και αποκομμένα Διαφορετικά προϊόντα από διαφορετικούς κατασκευαστές Οι πωλητές έχουν περιορισμένη γκάμα προϊόντων για συγκεκριμένες ανάγκες χρηστών Οι χρήστες αγοράζουν το Βοήθημα που ταιριάζει καλύτερα στις τρέχουσες ανάγκες τους, διαλέγοντας από έναν υπάρχοντα περιορισμένο αριθμό προϊόντων Σχήμα 20: Παραδοσιακή διαδικασία ανάπτυξης και διάθεσης Βοηθημάτων Επικοινωνίας Σελίδα 78 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

79 Μελέτες αναγκών των χρηστών Έρευνες αγοράς Ποικιλία ιδεών για διάφορα προϊόντα Α ν τ α λ λ α γ ή π λ η ρ ο φ ο ρ ι ώ ν Διάφοροι ανεξάρτητοι κατασκευαστές σε διαφορετικά μέρη Κέντρο συγκέντρωσης Συστατικών και πληροφοριών του ΟΔΥΣΣΕΑ στο Διαδίκτυο Διαφορετικά προϊόντα από διαφορετικούς κατασκευαστές συμβατά μεταξύ τους Οι σχεδιαστές και κατασκευαστές χρησιμοποιούν τα εργαλεία και τις οδηγίες του ΟΔΥΣΣΕΑ Οι πωλητές έχουν μεγάλη γκάμα συστατικών για να συνθέτουν Βοηθήματα χρησιμοποιώντας τα εργαλεία του ΟΔΥΣΣΕΑ Διαφορετικά, ρυθμιζόμενα και τροποποιήσιμα Βοηθήματα Επικοινωνίας εξειδικευμένα για κάθε χρήστη δημιουργούνται πολύ γρήγορα με μικρό κόστος Σχήμα 21: Η προσέγγιση του ΟΔΥΣΣΕΑ για τον κύκλο ζωής των Βοηθημάτων Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 79 από 163

80 Οι κατασκευαστές υλοποιούν τα προϊόντα τους που στη συνέχεια, φτάνουν στον τελικό χρήστη μέσω ενός πωλητή. Ο χρήστης με Αναπηρία πρέπει να αγοράσει το προϊόν που ταιριάζει καλύτερα στις ανάγκες του. Υπάρχει δυνατότητα ρυθμίσεων μόνο στο επίπεδο του τελικού χρήστη και στο βαθμό που προσφέρεται αυτή η δυνατότητα από τον κατασκευαστή. Οποιαδήποτε τροποποίηση και ανάγκη αλλαγής συνήθως σημαίνει αγορά ενός νέου προϊόντος ή ανάπτυξή του από την αρχή. Τέλος η ανταλλαγή πληροφοριών σχετικά με το σχεδιασμό του προϊόντος (feedback) γίνεται μεταξύ τελικών πελατών και κατασκευαστών. Ο ρόλος των πωλητών είναι υποβαθμισμένος στο επίπεδο του απλού μεσάζοντα για τη διάθεση των προϊόντων. Από την άλλη πλευρά, στην προσέγγιση του ΟΔΥΣΣΕΑ (Σχήμα 21), ενώ οι αρχικές ιδέες αφήνονται στους κατασκευαστές, ενθαρρύνεται ένας μεγαλύτερος βαθμός συνεργασίας των εμπλεκομένων στον κύκλο ζωής των προϊόντων που στοχεύει στη μεγαλύτερη ευελιξία και επαναχρησιμοποίηση των σχεδιασμών και των προϊόντων. Επίσης, διευκολύνεται η μεγαλύτερη προσαρμοστικότητα και συμβατότητα των διαφόρων υλοποιήσεων. Η προσέγγιση του ΟΔΥΣΣΕΑ, σχετικά με τον κύκλο ζωής των προϊόντων έχει αρκετές ομοιότητες με την προσέγγιση της αρχιτεκτονικής ATIC του έργου ACCESS [16], αλλά έχει και μια βασική διαφορά: τον ενεργό ρόλο του Διαδικτύου στον κύκλο ζωής. Στην ουσία η αρχιτεκτονική ATIC προέβλεπε στη θέση του Κέντρου Συγκέντρωσης Συστατικών και Πληροφοριών του ΟΔΥΣΣΕΑ στο Διαδίκτυο, μια πιο παραδοσιακή «δεξαμενή» συστατικών που θα μπορούσε να είναι είτε το ίδιο το κατάστημα του πωλητή, είτε ένα κέντρο συγκέντρωσης συστατικών που θα ελεγχόταν από ειδικούς διαχειριστές (απαιτούσε προσωπικό) και δεν είχε καμία σχέση με το Διαδίκτυο. Η εισαγωγή του Διαδικτύου στον κύκλο ζωής των προϊόντων που προτείνει ο ΟΔΥΣΣΕΑΣ κάνει εξαιρετικά πιο ευέλικτη τη διαδικασία συλλογής των συστατικών, αλλά και τη διαδικασία εντοπισμού τους. Τέλος μια άλλη διαφορά που ήδη αναφέρθηκε είναι ότι, ενώ οι θεραπευτές ήταν χρήστες του ATIC, και επομένως περιλαμβάνονταν στον κύκλο ζωής των προϊόντων, στο πλαίσιο ΟΔΥΣΣΕΑΣ δεν περιλαμβάνονται. Το αποτέλεσμα της διαφάνειας του ΟΔΥΣΣΕΑ για τους θεραπευτές-βοηθούς των ΑΜΑ είναι η μείωση των γνώσεων που χρειάζεται να έχουν σχετικά με το πλαίσιο. Οι κατασκευαστές υλοποιούν συστατικά, τα οποία συναρμολογούν οι πωλητές και τα ολοκληρώνουν σε πλήρως λειτουργικά Βοηθήματα Επικοινωνίας σύμφωνα με τις ανάγκες των συγκεκριμένων χρηστών. Οι χρήστες ΑΜΑ έχουν πολύ μεγαλύτερες πιθανότητες να αποκτήσουν ένα σύστημα κομμένο και ραμμένο στα μέτρα τους. Οι δυνατότητες ρυθμίσεων αυξάνονται μια και αυτές δεν γίνονται πια μόνο από τους κατασκευαστές και τους τελικούς χρήστες σύμφωνα με τις δυνατότητες που τους δίνονται από τους κατασκευαστές, αλλά επεκτείνονται και στους πωλητές συστημάτων. Ο σχεδιασμός γίνεται με βάση την επαναχρησιμοποίηση και ενθαρρύνεται η επικοινωνία και η ανταλλαγή πληροφοριών (feedback), μεταξύ τόσο των χρηστών και των κατασκευαστών όσο και μεταξύ των πωλητών και του πλαισίου ΟΔΥΣΣΕΑΣ και όλων των συνδυασμών των προηγουμένων. Μεγάλη διαφορά υπάρχει στην προσπάθεια που χρειάζεται για τη μεταβολή του σχεδιασμού του Βοηθήματος και την τροποποίησή του. Μπορεί ο κατασκευαστής να μη χρειαστεί καν να παρέμβει για να επιτευχθεί κάτι τέτοιο μια και υπάρχουν οι δυνατότητες προσθαφαίρεσης λειτουργιών και υπηρεσιών από το Βοήθημα με την επέμβαση μόνο του πωλητή ή και του ίδιου του χρήστη και του βοηθού-θεραπευτή του. Σε καμία περίπτωση δεν χρειάζεται επανασχεδιασμός ολόκληρου του Βοηθήματος και κάθε νέα ανάγκη μπορεί να αντιμετωπιστεί με κατασκευή νέων συστατικών ή πρόσθεσηαντικατάσταση ήδη υπαρχόντων. Σελίδα 80 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

81 7.3. Συστατικά Βοηθήματος Επικοινωνίας Τα συστατικά ενός Βοηθήματος Επικοινωνίας που παράγεται από το πλαίσιο ΟΔΥΣΣΕΑΣ πρέπει να έχουν κάποια βασικά χαρακτηριστικά εκτός από αυτά που προκύπτουν από τη συμμόρφωση στις γενικές τυποποιήσεις και οδηγίες που δίνει ο ΟΔΥΣΣΕΑΣ. Πρώτον, πρέπει να υλοποιούν τη λειτουργικότητα είτε του Εκδότη δεδομένων, είτε του Συνδρομητή σε Εκδότες είτε ένα συνδυασμό των δύο. Πολύ βασικό είναι το γεγονός ότι κατά τον προγραμματισμό αυτών των συστατικών πρέπει να λαμβάνεται η κατάλληλη μέριμνα για να μπορούν στη συνέχεια αυτά τα συστατικά να επικοινωνήσουν μεταξύ τους και να εκμεταλλευτούν την υποδομή του λειτουργικού συστήματος για την επικοινωνία και τη λειτουργία τους. Η Επικοινωνία βασίζεται σε συγκεκριμένο πρωτόκολλο και διεπαφές που περιγράφονται στη συνέχεια. Η λειτουργία των συστατικών σύμφωνα με όλα όσα έχουν περιγραφεί μέχρι τώρα βασίζεται στην υπηρεσία γεγονότων του COM+ που περιγράφτηκε στο σχετικό κεφάλαιο και συνοψίζεται στο παρακάτω Σχήμα 22. Συστατικά Εκδότες θεωρούνται τα συστατικά "εισόδου". Μπορούν να είναι Εικονικά Πληκτρολόγια με Συμβατικά Πλήκτρα (γράμματα αλφαβήτου), Εικονικά Πληκτρολόγια με Εναλλακτικά Πλήκτρα (σύμβολα BLISS, εικόνες, λέξεις), Επεξεργαστές Κειμένου, Αναγνωριστές Ομιλίας, Προγράμματα Σύνθεσης Μηνυμάτων Ηλεκτρονικής Αλληλογραφίας. 1. Δηλώνει Κλάση γεγονότος Κατάλογος COM+ 2. Δηλώνει (Event Class) (COM+ Catalog) 5. Διαβάζει τη λίστα των Συνδρομητών 3. Δημιουργεί Συστατικό Εκδότης 4. Πυροδοτεί ένα γεγονός αποστέλλοντας δεδομένα Αντικείμενο γεγονότος Συστατικό Συνδρομητής 6. Παραλαμβάνει το γεγονός και τα δεδομένα Σχήμα 22: Μοντέλο λειτουργίας των συστατικών του Βοηθήματος Επικοινωνίας Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 81 από 163

82 Συστατικά Συνδρομητές θεωρούνται τα συστατικά "εξόδου". Μπορούν να είναι Συνθέτες Ομιλίας, Απεικονίσεις Κειμένου στην Οθόνη, Προγράμματα Αποστολής και Παραλαβής Μηνυμάτων Ηλεκτρονικής Αλληλογραφίας. Συστατικά που υλοποιούν και τους δύο ρόλους (του Εκδότη και του Συνδρομητή) θεωρούνται τα "ενδιάμεσα" συστατικά που έχουν και είσοδο και έξοδο. Τέτοια μπορεί να είναι Μεταφραστές, Συστατικά Πρόβλεψης Λέξεων, Επεξεργαστές Προτάσεων (μετατροπή ασύντακτων προτάσεων σε συντεταγμένες) και γενικά συστατικά που εκτελούν οποιαδήποτε επεξεργασία σε δεδομένα που λαμβάνουν και τα αποστέλλουν προς την έξοδο Πρωτόκολλο επικοινωνίας των συστατικών Το πρωτόκολλο επικοινωνίας μεταξύ των συστατικών ενός βοηθήματος Διαπροσωπικής Επικοινωνίας που βασίζεται στο πλαίσιο ΟΔΥΣΣΕΑΣ, περιλαμβάνει μηνύματα που αποστέλλονται και λαμβάνονται με τη μεσολάβηση του λειτουργικού συστήματος Windows 2000 και συγκεκριμένα με την εκμετάλλευση της τεχνολογίας COM+ και της υπηρεσίας γεγονότων. Τα μηνύματα αυτά αποστέλλονται και παραλαμβάνονται μέσω της υλοποίησης από τα συστατικά συγκεκριμένων διεπαφών της Υπηρεσίας Γεγονότων (Event Classes) που θα περιγραφούν στην επόμενη ενότητα. Το βασικό που πρέπει να περιέχουν αυτά τα μηνύματα είναι τα δεδομένα του χρήστη. Το πλαίσιο ΟΔΥΣΣΕΑΣ προβλέπει για τα δεδομένα του χρήστη ένα μόνο τύπο δεδομένων και αυτός είναι οι αλφαριθμητικές σειρές (strings). Αυτό θέτει σε όλα τα συστατικά την προδιαγραφή ότι, άσχετα με τη λειτουργικότητα του καθενός, την επεξεργασία που εκτελεί το καθένα στα δεδομένα και τους εσωτερικούς τύπους δεδομένων που μπορεί να υποστηρίζουν το καθένα για τον εαυτό του, θα πρέπει υποχρεωτικά να επικοινωνούν μεταξύ τους μόνο με βάση αλφαριθμητικές σειρές. Αυτές οι αλφαριθμητικές σειρές προβλέπεται να περιέχουν την καθαρή πληροφορία του χρήστη, η οποία μπορεί να είναι ένας απλός χαρακτήρας, μια λέξη, μία πρόταση ή ένα ολόκληρο έγγραφο. Άσχετα με το αν ο χρήστης επικοινωνεί με συμβατική γλώσσα, με συμβατικούς αλφαριθμητικούς χαρακτήρες ή με εικόνες, με εναλλακτικές γλώσσες επικοινωνίας, όπως οι εικονικές γλώσσες, τα συστατικά (εισόδου) έχουν την υποχρέωση να μετατρέπουν την οποιαδήποτε είσοδο του χρήστη σε αλφαριθμητικές σειρές (για παράδειγμα, να αντιστοιχίζουν ένα σύμβολο στην έννοια του) πριν τη στείλουν σε επόμενα συστατικά. Λόγω της διαφορετικής επεξεργασίας που εφαρμόζεται στα είδη αλφαριθμητικών σειρών που αναφέρθηκαν, δηλαδή σε χαρακτήρες, σε λέξεις, προτάσεις και έγγραφα, ο ΟΔΥΣΣΕΑΣ διαχωρίζει ρητά τα είδη αυτά, σαν να ήταν διαφορετικοί τύποι δεδομένων. Δεν είναι ένας διαχωρισμός που θα έχει κάποιο προγραμματιστικό αντίκτυπο, όπως για παράδειγμα ο διαχωρισμός που παρατηρείται σε διάφορες γλώσσες προγραμματισμού μεταξύ τύπων δεδομένων, όπως οι αριθμοί και οι αλφαριθμητικές σειρές. Είναι μάλλον ένας λογικός και εννοιολογικός διαχωρισμός που οφείλουν να σεβαστούν οι κατασκευαστές συστατικών για να επιτευχθεί η σωστή και αποτελεσματική επεξεργασία των δεδομένων του χρήστη. Ακολουθεί ένας πίνακας (Πίνακας 5) που περιλαμβάνει αυτό το διαχωρισμό στο επίπεδο πρωτοκόλλου επικοινωνίας και διαφωτιστικά παραδείγματα που δείχνουν γιατί γίνεται αυτός ο διαχωρισμός. Σελίδα 82 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

83 Τύπος δεδομένων Μπορεί να είναι έξοδος από Μπορεί να είναι είσοδος σε Χαρακτήρας Εικονικό πληκτρολόγιο χαρακτήρων Επεξεργαστή κειμένου Λέξη Εικονικό πληκτρολόγιο λέξεων Εικονικό πληκτρολόγιο συμβόλων Επεξεργαστή κειμένου Συστατικό αναγνώρισης ομιλίας Συστατικό μετάφρασης λέξεων Πρόταση Εικονικό πληκτρολόγιο συμβόλων Επεξεργαστή κειμένου Συστατικό μετάφρασης προτάσεων Έγγραφο Επεξεργαστή κειμένου Συστατικό σύνθεσης μηνυμάτων ηλεκτρονικής αλληλογραφίας Συστατικό μετάφρασης κειμένων Συστατικό πρόβλεψης λέξεων Συστατικό απεικόνισης κειμένου Συστατικό για σύγχρονη απομακρυσμένη συνομιλία Συστατικό απεικόνισης κειμένου Συστατικό για σύγχρονη απομακρυσμένη συνομιλία Συνθέτη ομιλίας Συστατικό μετάφρασης λέξεων Συστατικό απεικόνισης κειμένου Συστατικό για σύγχρονη απομακρυσμένη συνομιλία Συνθέτη ομιλίας Συστατικό μετάφρασης προτάσεων Συνθέτη ομιλίας Συστατικό αποστολής ηλεκτρονικών μηνυμάτων Συστατικό μετάφρασης κειμένων Πίνακας 5: Πίνακας τύπων δεδομένων μηνυμάτων επικοινωνίας μεταξύ συστατικών Τα δεδομένα του χρήστη δεν είναι το μόνο περιεχόμενο των μηνυμάτων που πρέπει να ανταλλάσσονται μεταξύ των συστατικών ενός Βοηθήματος που βασίζεται στον ΟΔΥΣΣΕΑ. Πρέπει να ανταλλάσσεται και κάποια πληροφορία για το συγχρονισμό και την τοποθέτηση των συστατικών σε σειρά. Αυτό συμβαίνει γιατί έτσι όπως σχεδιάζεται η επικοινωνία μεταξύ των συστατικών σαν ένα είδος "Πίνακα Ανακοινώσεων" στον οποίο μπορούν να αφήνουν μηνύματα οι Εκδότες και από τον οποίο μπορούν να διαβάζουν μηνύματα οι Συνδρομητές, υπάρχει ο κίνδυνος "μπερδέματος" των μηνυμάτων. Σίγουρα σε διάφορες περιπτώσεις υπάρχει η ανάγκη κάποιοι Συνδρομητές να λαμβάνουν Μηνύματα Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 83 από 163

84 συγκεκριμένων Εκδοτών και όχι άλλων εκτός από αυτούς. Επίσης, μπορεί να απαιτείται μηνύματα κάποιον Εκδοτών να λαμβάνονται μόνο από μερικούς ή έναν συγκεκριμένο Συνδρομητή. Παρουσιάζεται λοιπόν η ανάγκη για "φιλτράρισμα" των μηνυμάτων, μια δυνατότητα που δίνεται από τις Υπηρεσίες Γεγονότων του COM+. Για να επιτευχθεί όμως αυτό το φιλτράρισμα χρειάζεται να είναι γνωστό κάποιο στοιχείο που αποκαλύπτει την ταυτότητα τουλάχιστο των Εκδοτών δεδομένων. Αυτό, από τη φύση του ΟΔΥΣΣΕΑ δεν υποστηρίζεται εγγενώς, μια και ένα βασικό χαρακτηριστικό του πλαισίου είναι η "απομόνωση" των συστατικών μεταξύ τους και η έλλειψη γνώσης της ύπαρξης του ενός για το άλλο, πόσο μάλιστα της ταυτότητάς του. Έτσι λοιπόν πάρθηκε η απόφαση τα μηνύματα μεταξύ των συστατικών να περιέχουν εκτός από τα δεδομένα του χρήστη και κάποιο στοιχείο για την ταυτότητα του αποστολέα. Αυτό το στοιχείο πρέπει να χαρακτηρίζει με μοναδικό τρόπο τον κάθε Εκδότη. Τέτοιο στοιχείο είναι το Class ID που έχει κάθε κλάση συστατικού. Είναι μια σειρά αριθμών και χαρακτήρων που δημιουργείται βάση κατάλληλου αλγορίθμου από το λειτουργικό σύστημα κατά τη δήλωση μιας κλάσης σε αυτό και ανήκει στην κλάση για όλη τη διάρκεια της ζωής της, μια και ενσωματώνεται στο αρχείο που την περιέχει. Όταν σε ένα εργαλείο ή γλώσσα προγραμματισμού, ο προγραμματιστής δημιουργεί μια κλάση, αυτόματα ανατίθεται σε αυτήν αυτό το μοναδικό Class ID. Όταν η κλάση ή το πρόγραμμα που την περιέχει εγκατασταθεί ακόμη και σε ένα άλλο σύστημα από αυτό στο οποίο δημιουργήθηκε, το Class ID της παραμένει το ίδιο στο νέο σύστημα. Είναι λοιπόν ένα στοιχείο της ταυτότητας μιας κλάσης Εκδότη, που μπορεί να το γνωρίζει και ο προγραμματιστής που δημιουργεί την κλάση, αλλά και ο Πωλητής που την ενσωματώνει μαζί με το συστατικό που την περιέχει σε ένα Βοήθημα Επικοινωνίας. Έτσι, το μήνυμα επικοινωνίας μεταξύ δύο συστατικών περιέχει δύο πεδία δεδομένων. Και τα δύο είναι αλφαριθμητικές σειρές και το ένα πρέπει να περιέχει τα δεδομένα του χρήστη σε οποιονδήποτε τύπο από αυτούς που αναφέρθηκαν και το άλλο να περιέχει το Class ID του αποστολέα ή του Εκδότη (Σχήμα 23). Η μορφή του μηνύματος πέρα από τη δομή των πεδίων (παραμέτρων) που περιέχει δεν μας ενδιαφέρει σε πιο χαμηλό επίπεδο, μια και όλα τα θέματα του πακεταρίσματος και της μεταφοράς του τα αναλαμβάνει το λειτουργικό και η μορφή δε γίνεται φανερή ούτε καν στον προγραμματιστή. Μήνυμα Επικοινωνίας μεταξύ συστατικών του ΟΔΥΣΣΕΑ Πηγή: Συστατικό Εκδότης Δεδομένα χρήστη (αλφαριθμητική σειρά) Class ID Εκδότη (αλφαριθμητική σειρά) Σχήμα 23: Δομή ενός μηνύματος επικοινωνίας μεταξύ συστατικών του ΟΔΥΣΣΕΑ Σελίδα 84 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

85 7.5. Διεπαφή επικοινωνίας των συστατικών Όπως έχει περιγραφεί, η κλάση γεγονότων είναι απλά μια δήλωση διεπαφών και μεθόδων, χωρίς καμία υλοποίηση. Στην ουσία περιέχει άδειες κλάσεις και ρουτίνες, στις οποίες καθορίζονται μόνο οι μεταβλητές (arguments) και τα ονόματα των κλάσεων και των ρουτινών. Η υλοποίηση στα πλαίσια της υπηρεσίας γεγονότων γίνεται από τον εκάστοτε Συνδρομητή που έχει δηλώσει ότι υλοποιεί την συγκεκριμένη διεπαφή. Από τη μεριά του Εκδότη, η σχέση του με την κλάση γεγονότων είναι απλά ότι καλεί κάποιες από τις μεθόδους της. Η βασική λειτουργικότητα της κλάσης γεγονότων σε συνδυασμό με την υπηρεσία γεγονότων είναι ότι, όταν ένας Εκδότης καλεί μια μέθοδο σε ένα αντικείμενο της διεπαφής, τότε η υπηρεσία γεγονότων αναλαμβάνει να καλέσει την αντίστοιχη υλοποιημένη μέθοδο των συνδρομητών σε αυτήν τη διεπαφή, απομονώνοντας έτσι τους Εκδότες από τους Συνδρομητές. Η συγκεκριμένη διεπαφή που σχεδιάστηκε στα πλαίσια του ΟΔΥΣΣΕΑ, αποτελείται από τέσσερις κλάσεις, οι οποίες εξυπηρετούν την επικοινωνία με τέσσερις αντίστοιχους τύπους δεδομένων (Σχήμα 24). Ο ΟΔΥΣΣΕΑΣ έχει σχεδιαστεί ώστε να υποστηρίζει τους εξής τύπους δεδομένων: Χαρακτήρας, Λέξη, Πρόταση, Έγγραφο. Έτσι τα δεδομένα που ανταλλάσσονται μεταξύ των συστατικών του ΟΔΥΣΣΕΑ είναι πάντα αλφαριθμητικές σειρές (strings), σε τέσσερις διαφορετικές διεπαφές, δηλαδή τέσσερις διαφορετικές κλάσεις γεγονότων, ανάλογα με το μέγεθος και τη λειτουργικότητα των δεδομένων. Προγραμματιστικά δεν υπάρχει καμία διαφορά μεταξύ των τεσσάρων τύπων δεδομένων εκτός από το όνομα των αντίστοιχων κλάσεων. Ο διαχωρισμός είναι καθαρά σε λογικό και λειτουργικό επίπεδο. Αυτό σημαίνει ότι τίποτα δεν εμποδίζει κάποιον να στείλει μια ολόκληρη πρόταση στη διεπαφή του χαρακτήρα, αλλά δίνεται αυστηρή οδηγία να μη γίνεται κάτι τέτοιο. Επίσης, είναι φανερό ότι τέτοιος έλεγχος δεν θα ήταν εφικτός προγραμματιστικά, γιατί δεν θα επιτρεπόταν, για παράδειγμα στο άρθρο «ο» να αποσταλεί ως λέξη μια που αποτελεί έναν μόνο χαρακτήρα. Σε λογικό επίπεδο όμως μπορεί να αποτελεί και ολόκληρη λέξη. Διεπαφή Επικοινωνίας Συστατικών Χαρακτήρας ΕΚΔΟΤΗΣ Λέξη Πρόταση Έγγραφο ΣΥΝΔΡΟΜΗΤΗΣ Σχήμα 24: Η διεπαφή για την επικοινωνία μεταξύ των συστατικών του ΟΔΥΣΣΕΑ. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 85 από 163

86 7.6. Πρόγραμμα εκκίνησης του Βοηθήματος Επικοινωνίας Όπως προβλέπεται από τον ΟΔΥΣΣΕΑ, όλα τα συστατικά που συνθέτουν ένα Βοήθημα Διαπροσωπικής Επικοινωνίας, πακετάρονται σε μορφή αρχείων βιβλιοθηκών δυναμικής σύνδεσης (DLLs). Είναι γνωστό ότι τέτοια αρχεία δεν είναι εκτελέσιμα, δεν μπορούν δηλαδή να ενεργοποιηθούν εκτός αν κάποιο άλλο πρόγραμμα τα καλέσει. Η μέθοδος ενεργοποίησης πολλών από αυτά τα αρχεία είναι η κλήση τους από την υπηρεσία γεγονότων του λειτουργικού συστήματος, κάτι που γίνεται αυτόματα και με διαφάνεια μόλις Εκδοθούν δεδομένα. Υπάρχουν όμως και συστατικά που θα πρέπει να έχουν κάποια διεπαφή χρήστη που θα πρέπει να ενεργοποιείται κατά την εκκίνηση του Βοηθήματος πριν την έκδοση οποιονδήποτε μηνυμάτων και θα πρέπει τέλος πάντων να ενεργοποιείται κάποιο αρχικό συστατικό Εκδότης για να μπορούν να εκδοθούν μηνύματα που θα ενεργοποιήσουν και τα υπόλοιπα συστατικά. Εκτέλεση προγράμματος εκκίνησης Ενεργοποίηση διεπαφών χρήσης συστατικών εισόδου Αποστολή μηνυμάτων μέσω της Υπηρεσίας Γεγονότων Ενεργοποίηση ενδιάμεσων συστατικών και συστατικών εξόδου Τερματισμός προγράμματος εκκίνησης Σχήμα 25: Βασική Λειτουργία Βοηθήματος Επικοινωνίας Σελίδα 86 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

87 Θα πρέπει λοιπόν στα πλαίσια του ΟΔΥΣΣΕΑ να αναπτυχθεί ένα αρχικό πρόγραμμα εκκίνησης του Βοηθήματος Διαπροσωπικής Επικοινωνίας, το οποίο θα εγκαθίσταται μαζί με τα συστατικά του Βοηθήματος στον υπολογιστή του τελικού χρήστη. Αυτό το πρόγραμμα θα πρέπει να είναι φυσικά σε εκτελέσιμη μορφή ώστε να μπορεί να ενεργοποιηθεί με μια απλή ενέργεια του χρήστη (για παράδειγμα με διπλό κλικ σε ένα εικονίδιο) ή αυτόματα (αν εισαχθεί στο μενού προγραμμάτων εκκίνησης Start up menu των Windows). Λειτουργίες που θα πρέπει να εκτελεί αυτό το πρόγραμμα είναι οι εξής: Εκκίνηση Βοηθήματος Επικοινωνίας. Εύρεση των συστατικών που πρέπει να ενεργοποιηθούν κατά την εκκίνηση του Βοηθήματος. Ενεργοποίηση αυτών των συστατικών (διεπαφών χρήσεων Εκδοτών). Τερματισμός της λειτουργίας του Βοηθήματος Διαπροσωπικής Επικοινωνίας. Η λειτουργία του Βοηθήματος διαπροσωπικής Επικοινωνίας με την προσθήκη αυτού του προγράμματος εκκίνησης συνοψίζεται στο Σχήμα Διαδικασία εγκατάστασης Βοηθήματος Επικοινωνίας Βασικό προαπαιτούμενο για την εγκατάσταση ενός Βοηθήματος Διαπροσωπικής Επικοινωνίας είναι προφανώς να είναι γνωστή η σύνθεση και η επιθυμητή λειτουργικότητα του συστήματος. Η εγκατάσταση αυτή γίνεται μετά από προσεκτική επιλογή των διαθεσίμων συστατικών που ικανοποιούν τις απαιτήσεις του εκάστοτε τελικού χρήστη δηλαδή του Ατόμου με Αναπηρία [2], [3]. Χρειάζεται λοιπόν, από την πλευρά του προσώπου που εγκαθιστά την εφαρμογή, πολύ καλή γνώση τόσο των αναγκών του χρήστη, όσο και των χαρακτηριστικών των συστατικών που έχει στη διάθεσή του. Πρέπει να γίνει η αντιστοίχηση των απαιτήσεων των χρηστών σε υπηρεσίες του συστήματος και να εντοπιστούν τα συστατικά που προσφέρουν μέσω της λειτουργικότητάς τους αυτές τις υπηρεσίες είτε μόνα τους είτε σε συνεργασία με άλλα. Η εγκατάσταση του Βοηθήματος Διαπροσωπικής επικοινωνίας έχει σχεδιαστεί έτσι ώστε να διενεργείται από τους ΠΩΛΗΤΕΣ των συστημάτων αυτών. Όλη η διαδικασία βασίζεται στη χρήση της Υπηρεσίας Συστατικών των Windows 2000 (Component Services). Όπως ήδη αναφέρθηκε, πρόκειται για μια διεπαφή χρήσης του λειτουργικού συστήματος όπου δίνεται η ευκαιρία στο χρήστη της να εγκαταστήσει και να ρυθμίσει διαχειριστικά εφαρμογές COM+ και να επέμβει στα περιεχόμενα του Καταλόγου των Συστατικών (Component Catalog). Με βάση την τεχνολογία και τις υπηρεσίες του συστήματος που παρέχονται από την ενσωμάτωση του COM+, ο Κατάλογος αυτός των Συστατικών (Component Catalog), παρέχει τη δυνατότητα να ικανοποιηθούν κάποιες από τις βασικότερες αρχικές απαιτήσεις που έπρεπε να καλύψει το πλαίσιο ΟΔΥΣΣΕΑΣ. Οι δυνατότητες που δίνει ο Κατάλογος των Συστατικών και αφορούν άμεσα το πλαίσιο ΟΔΥΣΣΕΑΣ είναι οι εξής: Δυνατότητα οπτικής ομαδοποίησης των συστατικών μέσα σε μία "εφαρμογή". Ο όρος εφαρμογή εδώ αναφέρεται σε μία σύνθεση από ένα ή περισσότερα συστατικά που λειτουργούν συνδυασμένα και σε συνεργασία για να επιτύχουν την επιθυμητή λειτουργικότητα ενός συστήματος λογισμικού. Η "εφαρμογή" περιλαμβάνει στην ουσία όλη την υποδομή που προσφέρει το λειτουργικό σύστημα και η τεχνολογία Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 87 από 163

88 COM+, ώστε να επιτευχθεί η διαλειτουργικότητα του Μοντέλου Συστατικών. Μόλις στον Κατάλογο Συστατικών δηλωθεί από τον Πωλητή μια νέα εφαρμογή προετοιμάζεται από το λειτουργικό σύστημα όλη η υποδομή για να λειτουργήσουν τα συστατικά της εφαρμογής αυτής που θα προστεθούν στη συνέχεια και όλες οι υπηρεσίες που απαιτούνται για την επικοινωνία και τη συνεργασία τους. Δυνατότητα πρόσθεσης συστατικών λογισμικού στην εφαρμογή. Τα συστατικά λογισμικού προστίθενται επίσης με διαχειριστικό τρόπο στην εφαρμογή συνθέτοντας έτσι το ολοκληρωμένο σύστημα. Είναι μεγάλο πλεονέκτημα ότι και σε ένα ήδη υπάρχον σύστημα μπορούν να προστεθούν συστατικά εκ των υστέρων. Αυτό σημαίνει ότι μπορεί να μεταβληθεί διαχειριστικά η λειτουργικότητα του Βοηθήματος Διαπροσωπικής Επικοινωνίας προσθέτοντας υπηρεσίες και λειτουργικότητες που αρχικά δεν υπήρχαν. Δυνατότητα αφαίρεσης συστατικών από την εφαρμογή. Η απαίτηση του ΟΔΥΣΣΕΑ για δυνατότητα και ευκολία στην τροποποίηση του Βοηθήματος Επικοινωνίας συμπληρώνεται από αυτό το χαρακτηριστικό. Εκτός λοιπόν από τη δυνατότητα πρόσθεσης λειτουργικοτήτων στην εφαρμογή μπορεί ο πωλητής διαχειριστικά να αφαιρέσει και συστατικά με τις αντίστοιχες λειτουργικότητες όταν αυτές δεν χρειάζονται πια. Δυνατότητα ρύθμισης της επικοινωνίας των συστατικών. Μέσα από τη διαχείριση των Συνδρομών στην Υπηρεσία Γεγονότων του COM+, ο πωλητής έχει τη δυνατότητα να προσδιορίσει ποια συστατικά θα επικοινωνούν με ποια. Κάποια από τα συστατικά, σύμφωνα με το σχεδιασμό του ΟΔΥΣΣΕΑ είναι Εκδότες δεδομένων, κάποια άλλα είναι Συνδρομητές σε γεγονότα και λαμβάνουν τα δεδομένα αυτά και τέλος υπάρχουν συστατικά του Βοηθήματος Επικοινωνίας που έχουν τη λειτουργικότητα του Εκδότη και του Συνδρομητή ταυτόχρονα. Ο πωλητής έχει τη δυνατότητα μέσα από τις ρυθμίσεις των φίλτρων των Συνδρομητών να επιλέξει ποιον ή ποιους Εκδότες ενός συγκεκριμένου γεγονότος θα "ακούει" κάθε Συνδρομητής σε αυτό. Για να εγκαταστήσει ένας Πωλητής ένα σύστημα Βοηθήματος Διαπροσωπικής Επικοινωνίας θα πρέπει να αλληλεπιδράσει με την Υπηρεσία Συστατικών των Windows 2000 και να χρησιμοποιήσει τις δυνατότητες που αναφέρθηκαν. Η διαδικασίες εγκατάστασης μιας εφαρμογής COM+, προσθαφαίρεσης συστατικών και ρύθμισης της επικοινωνίας μεταξύ τους είναι αυτές που θα πρέπει να εκτελεί ένας πωλητής για να μπορεί να εγκαθιστά με επιτυχία ένα Βοήθημα Επικοινωνίας. Η πλήρης διαδικασία περιλαμβάνεται στο Εγχειρίδιο Χρήσης των Πωλητών που περιλαμβάνεται στην υλοποίηση του Πλαισίου Δοκιμαστικά συστατικά ελέγχου και αναφοράς Για λόγους δοκιμών και ελέγχων, θα πρέπει ο ΟΔΥΣΣΕΑΣ να παρέχει δοκιμαστικά συστατικά στους Προγραμματιστές. Με τη βοήθεια αυτών των συστατικών θα μπορούν να ελέγχουν αν τα δικά τους συστατικά είναι συμβατά με το πλαίσιο ΟΔΥΣΣΕΑΣ. Θα πρέπει να δίνουν την δυνατότητα στους προγραμματιστές να ελέγχουν αν συστατικά τους μπορούν να Εκδώσουν δεδομένα και να παραλάβουν δεδομένα μέσα από την Υπηρεσία Γεγονότων και ακολουθώντας τις τυποποιήσεις και οδηγίες του ΟΔΥΣΣΕΑ. Έτσι, θα πρέπει να κατασκευαστούν ένα συστατικό με δυνατότητες έκδοσης σε γεγονότα, και ένα με δυνατότητες Συνδρομής σε γεγονότα. Επίσης, χρειάζεται και η δημιουργία ενός Σελίδα 88 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

89 συστατικού με συνδυασμένες δυνατότητες Έκδοσης και Συνδρομής για να δοκιμάζονται σενάρια συγχρονισμού και τοποθέτησης συστατικών σε σειρά (Πίνακας 6). Εκτός από τη λειτουργικότητά τους ως δοκιμαστικά συστατικά, τα τρία αυτά συστατικά θα πρέπει να αποτελούν και προγραμματιστικά υποδείγματα για τη χρήση όλων των υπηρεσιών του ΟΔΥΣΣΕΑ. Θα πρέπει ο κώδικάς τους να είναι ελεύθερα διαθέσιμος, ώστε να χρησιμεύει σαν δείγμα σωστής και αποτελεσματικής εφαρμογής όλων των τυποποιήσεων και οδηγιών του ΟΔΥΣΣΕΑ και των υπηρεσιών του συστήματος που θέτει ο ΟΔΥΣΣΕΑΣ ως υποδομή σε ένα Βοήθημα Επικοινωνίας. Δοκιμαστικό Συστατικό Εισόδου (Εκδότης) Δοκιμαστικό Συστατικό Εξόδου (Συνδρομητής) Δυνατότητα έκδοσης γεγονότων Αποστολή του δικού του Class ID σε κάθε μήνυμα Υποστήριξη όλων των διεπαφών του ΟΔΥΣΣΕΑ Δυνατότητα επιλογής από τον χρήστη των δεδομένων που Εκδίδονται Δυνατότητα συνδρομής σε γεγονότα Δυνατότητα απεικόνισης των δεδομένων που παραλαμβάνονται Δυνατότητα απεικόνισης του Class ID του Εκδότη Υποστήριξη όλων των διεπαφών του ΟΔΥΣΣΕΑ Δοκιμαστικό Ενδιάμεσο Συστατικό Δυνατότητα Έκδοσης γεγονότων σε όλες τις διεπαφές του ΟΔΥΣΣΕΑ Δυνατότητα Συνδρομής σε γεγονότα σε όλες τις διεπαφές του ΟΔΥΣΣΕΑ Στοιχειώδης επεξεργασία των δεδομένων που έρχονται στην είσοδο πριν την αποστολή τους στην έξοδο Δυνατότητα απεικόνισης των δεδομένων πριν και μετά την επεξεργασία τους Πίνακας 6: Προδιαγραφές δοκιμαστικών συστατικών του ΟΔΥΣΣΕΑ 7.9. Ο ΟΔΥΣΣΕΑΣ στο Διαδίκτυο Ο ΟΔΥΣΣΕΑΣ θα έχει φυσικά το δικό του τόπο στο Διαδίκτυο. Σε αυτόν τον τόπο θα είναι διαθέσιμες όλες οι τυποποιήσεις και οι οδηγίες που θέτει το πλαίσιο και αναλύονται στην Υλοποίησή του. Εκτός από αυτά θα είναι διαθέσιμα και τα δοκιμαστικά συστατικά του πλαισίου και όλα τα εργαλεία που αναπτύσσονται κατά την υλοποίησή του. Τέλος ο τόπος του ΟΔΥΣΣΕΑ στο Διαδίκτυο είναι μέρος του ίδιου του πλαισίου. Εκεί έχει σχεδιαστεί να συγκεντρώνονται τα συστατικά που κατασκευάζονται από τους Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 89 από 163

90 ανεξάρτητους κατασκευαστές. Θα περιλαμβάνεται περιγραφή τους, προδιαγραφές τους και οδηγίες χρήσης για το καθένα από αυτά. Θα λειτουργεί αυτός ο τόπος ως μία βάση δεδομένων για τα συστατικά που είναι συμβατά με το πλαίσιο ΟΔΥΣΣΕΑΣ. Θα είναι μια πηγή πληροφοριών για τους προγραμματιστές, τους κατασκευαστές και τους χρήστες Βοηθημάτων Διαπροσωπικής Επικοινωνίας και για οποιονδήποτε άλλον ενδιαφερόμενο. Έτσι, σχεδιάζεται ένας τόπος που θα περιέχει τα εξής: Το σχεδιασμό του πλαισίου ΟΔΥΣΣΕΑΣ. Την Υλοποίηση του πλαισίου ΟΔΥΣΣΕΑΣ. Βάση δεδομένων με τα συστατικά Βοηθημάτων Διαπροσωπικής Επικοινωνίας που είναι συμβατά με τον ΟΔΥΣΣΕΑ. Περιγραφή και τεχνικές εκθέσεις Ολοκληρωμένων Βοηθημάτων Διαπροσωπικής Επικοινωνίας που κατασκευάστηκαν σύμφωνα με το πλαίσιο ΟΔΥΣΣΕΑΣ. Τα ελεύθερα διανεμόμενα δοκιμαστικά συστατικά του ΟΔΥΣΣΕΑ, καθώς και τον κώδικά τους. Τις διεπαφές που χρησιμοποιούνται στον ΟΔΥΣΣΕΑ για την επικοινωνία των συστατικών και τον κώδικά τους. Το πρόγραμμα εγκατάστασης Βοηθημάτων Διαπροσωπικής Επικοινωνίας και το Εγχειρίδιο Χρήσης του. Φυσικά οποιαδήποτε συστατικά περιέχονται στον τόπο αυτό, θα συνοδεύονται με πλήρη τεκμηρίωσή τους που θα περιλαμβάνει: Γενική περιγραφή τους Ανάλυση της λειτουργικότητας και των υπηρεσιών που προσφέρουν Δυνατότητες συνεργασίας τους με άλλα συστατικά Διεπαφές που υλοποιούν Οδηγίες χρήσης τους Οδηγίες για την εγκατάστασή τους Σελίδα 90 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

91 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» -ΜΕΡΟΣ Β: Υλοποίηση του Πλαισίου- Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 91 από 163

92 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» 1. Εισαγωγή Το πλαίσιο Σχεδιασμού και Ανάπτυξης Βοηθημάτων Διαπροσωπικής Επικοινωνίας, που εν συντομία ονομάζεται «ΟΔΥΣΣΕΑΣ» και του οποίου η Υλοποίηση θα περιγραφεί εδώ, κι έχει ως στόχο την μελέτη και ανάπτυξη μιας νέας σταθερής πλατφόρμας για την γρήγορη και με μικρό κόστος υλοποίηση από διάφορους κατασκευαστές ευέλικτων και βελτιωμένων επικοινωνιακών βοηθημάτων που βασίζονται σε ηλεκτρονικό υπολογιστή. Αυτό επιτυγχάνεται με την υιοθέτηση συγκεκριμένων τυποποιήσεων, τη θέσπιση αυστηρών προδιαγραφών και την ανάπτυξη μιας αρθρωτής αρχιτεκτονικής και των σχετικών βοηθητικών εργαλείων ανάπτυξης λογισμικού. Όλα όσα αναφέρονται στην σύντομη παρουσίαση του πλαισίου ΟΔΥΣΣΕΑΣ στην εισαγωγή αυτή, αναλύονται με λεπτομέρεια στα επιμέρους κεφάλαια της παρούσας εργασίας. Τα Συστήματα Εναλλακτικής και Επαυξητικής Επικοινωνίας ή Βοηθήματα Διαπροσωπικής Επικοινωνίας απευθύνονται σε χρήστες Άτομα Με Αναπηρία (ΑΜΑ) [2]. Τα Βοηθήματα Διαπροσωπικής Επικοινωνίας που μας απασχολούν σε αυτό το έργο βασίζονται σε ηλεκτρονικούς υπολογιστές και είναι συχνά πολύπλοκα συστήματα που πολλές φορές έχουν σαν έξοδο φωνή και επικεντρώνονται στις ανάγκες κάποιου συγκεκριμένου χρήστη. Μετά από μια αρχική εκτίμηση των επικοινωνιακών αναγκών του χρήστη και λαμβάνοντας υπ όψη την κατάσταση των νευρολογικών του λειτουργιών, τις δυνατότητες κινήσεών του καθώς και τις γλωσσικές του ικανότητες, καταρτίζεται ένα πρόγραμμα επανένταξης το οποίο συχνά περιλαμβάνει τη χρήση εξοπλισμού. Ο εξοπλισμός αυτός δεν είναι ευρέως διαδεδομένος στη χώρα μας και τα συστήματα της αγοράς του εξωτερικού παρουσιάζουν δυο βασικά μειονεκτήματα: έχουν μεγάλο κόστος και δεν υποστηρίζουν την Ελληνική γλώσσα. Τα βοηθήματα αυτά πρέπει να παρουσιάζουν μεγάλη ευελιξία και προσαρμοστικότητα γιατί συνήθως πριν ολοκληρωθεί το πρόγραμμα επανένταξης μεταβάλλουν τα χαρακτηριστικά τους για να ικανοποιήσουν τις αυξημένες επικοινωνιακές ανάγκες του χρήστη. Για εκείνους που δεν μπορούν αν χρησιμοποιήσουν το πληκτρολόγιο υπάρχουν εναλλακτικές μέθοδοι όπως η χρήση του ποδιού, του κεφαλιού ή ακόμα και της κίνησης των βλεφάρων μέσω ειδικών συσκευών και διακοπτών. Το επικοινωνιακό βοήθημα θα πρέπει να παρέχει άμεση πρόσβαση σε προτάσεις ζωτικές για την ικανοποίηση καθημερινών αναγκών καθώς και σε προτάσεις χρήσιμες στην καθημερινή επικοινωνία. Ένας από τους σημαντικούς παράγοντες σε ένα σύστημα επικοινωνίας είναι η ταχύτητα επικοινωνίας που μπορεί να επιτευχθεί με αυτό. Θα πρέπει να τονίσουμε από την αρχή ότι ο ΟΔΥΣΣΕΑΣ δεν είναι ένα Βοήθημα Επικοινωνίας. Το μονοπάτι της πληροφορίας ανάμεσα στον άνθρωπο και τον υπολογιστή που είναι από τη φύση του χαμηλού ρυθμού επιβραδύνεται ακόμα περισσότερο από την αναπηρία του χρήστη. Αυτό είναι ίσως και το σημαντικότερο τεχνικό πρόβλημα στην ανάπτυξη της συνεργασίας του ανθρώπου με τη μηχανή, μιας συνεργασίας αρκετά καλής, ώστε να μπορέσει να αποδώσει αρκετά, ώστε ο χρήστης να μπορεί να πάρει μέρος σε μια συζήτηση. Χρειάζεται εντατική έρευνα για να μπορέσει να βελτιωθεί ή διεπαφή του χρήστη ώστε να μειωθεί στο ελάχιστο ή απαιτούμενη ροή πληροφορίας ανάμεσα στον άνθρωπο και τη μηχανή, καθώς και για τη δημιουργία εναλλακτικών καναλιών διεπαφής, τα οποία θα δώσουν στον χρήστη τη δυνατότητα να κωδικοποιεί την πληροφορία πιο εύκολα και γρήγορα. Ένα αρθρωτό επικοινωνιακό βοήθημα πρέπει να μπορεί να αντιμετωπίσει επαρκώς χρήστες με προβλήματα κίνησης, αντίληψης και διανόησης. Τα ειδικά προβλήματα του Σελίδα 92 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

93 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» ατόμου πρέπει να αντιμετωπιστούν όταν δημιουργείται μια ειδική λύση, ενώ παράλληλα το επικοινωνιακό βοήθημα που χρησιμοποιείται θα πρέπει να ταιριάζει με την διανοητική ικανότητα του ατόμου που το χρησιμοποιεί. Είναι λοιπόν αδύνατο να χρησιμοποιηθούν συγκεκριμένοι απλοί κανόνες στην διαδικασία αυτή. Απαιτείται συχνά η χρησιμοποίηση μιας μεθόδου δοκιμής και σφάλματος και έτσι η χρησιμοποιούμενη τεχνολογία πρέπει να επιτρέπει τις γρήγορες αλλαγές. Πολλά διαφορετικά χαρακτηριστικά χρειάζονται για να ικανοποιηθούν οι φυσικές ανάγκες, τα νοητικά και γλωσσικά επίπεδα και οι επικοινωνιακές ανάγκες των ανθρώπων που χρησιμοποιούν αυτά τα βοηθήματα. Επιπλέον, οι χρήστες υποβοηθητικής τεχνολογίας (assistive technology) συχνά κριτικάρουν την έλλειψη συμβατότητας και ολοκλήρωσης διαφόρων συσκευών. Η χρήση ενός συνδυασμού από συσκευές οδηγεί σε μεγάλες δυσκολίες στην καθημερινή χρήση. Η σχεδίαση και ανάπτυξη των ήδη υπαρχόντων επικοινωνιακών βοηθημάτων πάσχει από την έλλειψη μιας γενικής τεχνικής λύσης που θα βοηθούσε την ανάπτυξη προσαρμοσμένων στο χρήστη και λειτουργικά ευέλικτων συστημάτων με βάση γενικών κριτηρίων και εργαλείων. Η ιδανική τεχνολογική λύση θα ήταν αυτή που θα μπορούσε να επικεντρώσει στον συγκεκριμένο χρήστη, χρησιμοποιώντας της ειδικές του ικανότητες στο μέγιστο και παράλληλα να έχει μόνο τα ειδικά χαρακτηριστικά, τα οποία εκείνος χρειάζεται. Όμως δεν είναι πρακτικό για τους προγραμματιστές να αναπτύσσουν πολλά ειδικά για τον χρήστη συστήματα. Έτσι μπορούν να ακολουθηθούν οι ακόλουθοι δρόμοι: Η κατασκευή περιορισμένων συστημάτων τα οποία ικανοποιούν ανάγκες συγκεκριμένων ομάδων πελατών. Η ανάπτυξη παραμετρικών συστημάτων για όλες τις περιπτώσεις στις παραμέτρους των οποίων δίδονται τιμές ώστε να καλύψουν τις συγκεκριμένες ανάγκες κάποιου χρήστη. Η ανάπτυξη αρθρωτής αρχιτεκτονικής η οποία υποστηρίζει εξειδικευμένα τμήματα - συστατικά (components) για μικρότερες ομάδες πιθανών χρηστών. Η πρώτη προσέγγιση είναι η πιο εύκολη να επιτευχθεί τεχνικά, ενώ επιτυγχάνεται ευκολία χρήσης και αποτελεσματικότητα. Η απαιτήσεις μπορούν να ικανοποιηθούν και να επανεπεξεργαστούν όπως συνήθως χρειάζεται, μέσα από μια διαρκή διαδικασία αξιολόγησης με κάποια ομάδα σταθερών πελατών. Το πρόβλημα είναι ότι παράγονται ακριβά προϊόντα λόγω των μικρών αριθμών παραγωγής. Επίσης, θα υπάρχουν πάντα μερικοί πελάτες οι οποίοι παραβλέπονται λόγω τις ειδικότητας των αναγκών τους. Οι τελευταίες δύο προσεγγίσεις έχουν τη δυνατότητα να καλύψουν μεγαλύτερες ομάδες χρηστών. Η κάθε μια από αυτές έχει τα δικά της πλεονεκτήματα και μειονεκτήματα. Στην δεύτερη από τις τρεις προσέγγιση, ο υπεύθυνος για την ανάπτυξη μπορεί να διατηρήσει τον έλεγχο για όλα τα θέματα που αφορούν το σύστημα και έτσι να εγγυηθεί έλεγχο της ποιότητας. Παραταύτα, ένα τέτοιο σύστημα τείνει να γίνει πολύπλοκο και ο πελάτης πρέπει να αγοράσει το όλο πακέτο. Ο μεγάλος αριθμός παραμέτρων προσαρμογής επίσης μπορεί να οδηγήσει τον πελάτη σε αδιέξοδο μιας και θα είναι δύσκολο γι αυτόν να καταλάβει ποιές παράμετροι θα πρέπει να ρυθμιστούν και ποιές όχι. Η αρθρωτή προσέγγιση είναι η καλύτερη για να ακολουθηθεί για ένα σύνολο από λόγους. Ο πιο σημαντικός είναι το γεγονός ότι οι χρήστες θα μπορούσαν στις περισσότερες περιπτώσεις να αγοράσουν μόνο τις λειτουργίες εκείνες που τους είναι απαραίτητες. Αυτό θα μπορούσε να μεταφραστεί σε μικρότερο κόστος γιατί είναι ευκολότερο να αναπτυχθούν Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 93 από 163

94 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» πολλά μικρά τμήματα λογισμικού και υλικού με περιορισμένες δυνατότητες. Επίσης, η δυσκολία και το κόστος προσαρμογής είναι μικρότερο γιατί μόνο σχετικοί με το χρήστη παράμετροι πρέπει να κατανοηθούν και να ρυθμιστούν. Αφού οι χρήστες δεν έχουν πρόσβαση σε χαρακτηριστικά που δεν τους είναι γνωστά, είναι λιγότερο πιθανό να μπερδευτούν από αυτά. Μια αξιόπιστη αρθρωτή σχεδίαση θα μπορούσε να λύσει το πρόβλημα των αναγκών του χρήστη καθώς αυτές αλλάζουν με τον χρόνο. Δυστυχώς, τα αρθρωτά συστήματα δεν είναι εύκολο να υλοποιηθούν. Αυτό συμβαίνει γιατί οι υπεύθυνοι ανάπτυξης δεν μπορούν να γνωρίζουν πώς διάφορα τμήματα μπορούν να συνδυαστούν ή ακόμα μπορεί και να μην είναι γνωστή σε αυτούς η ύπαρξη κάποιου ήδη έτοιμου τμήματος. Έτσι τα διάφορα τμήματα θα πρέπει να καταγραφούν και να χωριστούν σε κατηγορίες με κοινούς στόχους. Σε κάθε τέτοιο συστατικό (component) ή τμήμα ενός βοηθήματος χρειάζεται μια λογική ισορροπία ανάμεσα στην ευελιξία και στα τυποποιημένα χαρακτηριστικά. Ο ΟΔΥΣΣΕΑΣ φιλοδοξεί λοιπόν να δώσει λύσεις στα εξής σημαντικά προβλήματα Βοηθημάτων Επικοινωνίας που σχετίζονται με: Την έλλειψη ποικιλίας σε Βοηθήματα Επικοινωνίας στην αγορά, ιδιαίτερα την Ελληνική Την ακριβή τιμή τέτοιων προϊόντων. Τις μεγάλες ανάγκες παραμετροποίησης. Τις μεταβαλλόμενες απαιτήσεις των χρηστών. Τις γρήγορες αλλαγές στην τεχνολογία λογισμικού και υλικού. Την έλλειψη επαναχρησιμοποίησης κώδικα και συστατικών. Τον κατακερματισμό της αγοράς. Την έλλειψη συμβατότητας μεταξύ των διαφόρων συστατικών ενός Βοηθήματος Επικοινωνίας. Την αδυναμία συνεργασίας των κατασκευαστών. Την έλλειψη βοηθημάτων που να υποστηρίζουν την Ελληνική γλώσσα. Ο ΟΔΥΣΣΕΑΣ είναι προϊόν έρευνας και εξέλιξης Το πλαίσιο ΟΔΥΣΣΕΑΣ δεν είναι η πρώτη προσπάθεια για την αντιμετώπιση των προβλημάτων της αγοράς λογισμικού Βοηθημάτων Διαπροσωπικής Επικοινωνίας, μέσω της καθιέρωσης νέων κατάλληλων αρχιτεκτονικών και τυποποιήσεων. Γενικά για τον τομέα της τεχνολογίας λογισμικού έχουν υπάρξει προτάσεις και λύσεις όπως μοντέλα αντικειμενοστραφούς προγραμματισμού - OMT, μοντέλα προγραμματισμού με συστατικά - COM και συνδυασμοί των προηγουμένων με εφαρμογή στον κατανεμημένο προγραμματισμό - DCOM, CORBA. Αυτά τα μοντέλα και οι αρχιτεκτονικές θα μελετηθούν στο πλαίσιο της ανάπτυξης του ΟΔΥΣΣΕΑ, και θα συγκριθούν μεταξύ τους. Όπως θα δούμε αναλυτικά στα επόμενα κεφάλαια, τελικά αποφασίστηκε να υιοθετηθεί το τεχνολογικά νεώτερο, αλλά και αρτιότερο μοντέλο, δηλαδή το COM+. Συγκεκριμένα για το χώρο των Βοηθημάτων επικοινωνίας υπήρξαν προτάσεις στο παρελθόν, όπως αυτές του έργου ACCESS, το οποίο χρηματοδοτήθηκε από το Πρόγραμμα TIDE της Ευρωπαϊκής Ένωσης, και της αρχιτεκτονικής ATIC που προέκυψε από αυτό. Σελίδα 94 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

95 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Στα πλαίσια αυτού του έργου αναπτύχθηκε ένα πλαίσιο που περιελάμβανε μια αυτοσχέδια (proprietary) αρχιτεκτονική, πρωτόκολλο επικοινωνίας μεταξύ συστατικών και έναν αυτοσχέδιο διαχειριστή των συστατικών και των μηνυμάτων που έπρεπε να ανταλλάσσονται μεταξύ τους. Όλα αυτά μαζί κάλυπταν τις ανάγκες για μια νέα προσέγγιση στην τυποποίηση και υποβοήθηση της δημιουργίας Βοηθημάτων Επικοινωνίας με βάση τις τότε (1995) δυνατότητες της τεχνολογίας λογισμικού. Ο ΟΔΥΣΣΕΑΣ δεν απορρίπτει τα επιτεύγματα τέτοιων παλαιότερων προσπαθειών, αλλά προχωρά ένα βήμα παραπάνω. Προσαρμόζει τις βασικές αρχές τους στη σημερινή τεχνολογία, εξελίσσει και απλοποιεί τις αρχιτεκτονικές και τις τυποποιήσεις που προτάθηκαν. Μια επίσης σημαντική προσπάθεια του παρελθόντος που μελετήθηκε στα πλαίσια του ΟΔΥΣΣΕΑ είναι και το ονομαζόμενο Comspec. Επρόκειτο για μια διαφορετική προσέγγιση που βασιζόταν στην φιλοσοφία της γεννήτριας εφαρμογών, ενός πακέτου λογισμικού που προσφέρει ένα πλήρες περιβάλλον ανάπτυξης Βοηθημάτων Επικοινωνίας με κατάλληλα εργαλεία και μεθοδολογίες. Αυτή η προσέγγιση θεωρήθηκε πολύ περιοριστική ως προς τις δυνατότητές της, μια και παρήγαγε πολύ συγκεκριμένους τύπους Βοηθημάτων και πολύ πολύπλοκη και χρονοβόρα για την δημιουργία μιας παρεμφερούς υποδομής. Προτιμήθηκε να αφεθεί μεγαλύτερη ελευθερία στους κατασκευαστές που σε τελική ανάλυση πρέπει να πεισθούν για την αποτελεσματικότητα, τις δυνατότητες και την ευκολία χρήσης ενός πλαισίου ανάπτυξης Βοηθημάτων Επικοινωνίας. Ο ΟΔΥΣΣΑΣ βασίζεται στις νέες τεχνολογίες. Το πλαίσιο «ΟΔΥΣΣΕΑΣ» αναπτύχθηκε έτσι, ώστε να υποστηρίζει τις νέες τεχνολογίες αιχμής που κυριαρχούν στον τομέα της τεχνολογίας λογισμικού. Έτσι, σχεδιάστηκε ώστε να υποστηρίζει την πλατφόρμα των προσωπικών υπολογιστών που είναι εφοδιασμένοι με το λειτουργικό σύστημα Windows Εκμεταλλεύεται πλήρως τις τεχνολογικές καινοτομίες που προσφέρει αυτό το λειτουργικό σύστημα σε όλες τους τις εκδόσεις, όπως το COM+ και τα Component Services. Ενθαρρύνει την ανάπτυξη συστατικών σε μοντέρνα εργαλεία ή γλώσσες προγραμματισμού όπως η Microsoft Visual Basic, η Microsoft Visual C++ και η Java. Σημαντικό είναι το γεγονός ότι προτείνει τη χρησιμοποίηση μοντέρνων και ευρέως διαδεδομένων τεχνικών προγραμματισμού όπως ο αντικειμενοστραφής προγραμματισμός, ο προγραμματισμός που βασίζεται σε συστατικά και ο κατανεμημένος προγραμματισμός. Κυρίως όμως, είναι έτσι σχεδιασμένος ώστε να έχει ως εγγενές χαρακτηριστικό του την υποστήριξη του Διαδικτύου και των υπηρεσιών του. Ο ΟΔΥΣΣΕΑΣ επικεντρώνεται στην Τεχνολογία Λογισμικού. Το πλαίσιο ΟΔΥΣΣΕΑΣ στην πραγματικότητα προτείνει μια σειρά από οδηγίες που απευθύνονται στους κατασκευαστές Βοηθημάτων Επικοινωνίας ή τμημάτων τέτοιων εφαρμογών, ώστε να κατασκευάζονται αποδοτικά, διαδραστικά, αρθρωτά, επεκτάσιμα και επαναχρησιμοποιούμενα τμήματα λογισμικού. Επίσης, προσφέρει υλοποιημένα τμήματα λογισμικού για τη δοκιμή των προτεινόμενων τεχνολογιών και αρχιτεκτονικών, τα οποία χρησιμεύουν και ως πρότυπα υποδείγματα για τον τρόπο που θα πρέπει να κατασκευάζονται τμήματα Βοηθημάτων Επικοινωνίας. Το πλαίσιο περιλαμβάνει πλήρη περιγραφή των τεχνικών προγραμματισμού και των τυποποιήσεων που πρέπει να ακολουθηθούν, ώστε να παραχθούν από ανεξάρτητους κατασκευαστές τμήματα λογισμικού που θα μπορούν να συνεργάζονται μεταξύ τους με σκοπό να ολοκληρώνονται σε ένα ενιαίο και λειτουργικό Βοήθημα Επικοινωνίας. Αυτά τα τμήματα λογισμικού λέγονται συστατικά (components). Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 95 από 163

96 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Τέλος, ο ΟΔΥΣΣΕΑΣ προσφέρει ένα εκτελέσιμο πρόγραμμα το οποίο χρησιμεύει για την εκκίνηση του βοηθήματος Διαπροσωπικής Επικοινωνίας και τον συγχρονισμό και την ταξινόμηση (ή την «ενορχήστρωση») των συστατικών που το αποτελούν. Όλα αυτά που αναφέρθηκαν και θα περιγραφούν με λεπτομέρεια στα επόμενα κεφάλαια, αφορούν την κύρια ομάδα χρηστών στην οποία απευθύνεται το «πλαίσιο ΟΔΥΣΣΕΑΣ» και είναι οι προγραμματιστές ή οι κατασκευαστές λογισμικού. Υπάρχει όμως και μια δεύτερη ομάδα χρηστών στην οποία απευθύνεται ο ΟΔΥΣΣΕΑΣ και αυτή είναι οι πωλητές ή ολοκληρωτές Βοηθημάτων Διαπροσωπικής Επικοινωνίας. Για αυτή την ομάδα χρηστών, το πλαίσιο ΟΔΥΣΣΕΑΣ προσφέρει ένα «Εγχειρίδιο Χρήσης» όπου περιγράφονται με λεπτομέρεια οι διαδικασίες που πρέπει να ακολουθηθούν για την σύνθεση και το συγχρονισμό των έτοιμων συστατικών ενός Βοηθήματος Επικοινωνίας, καθώς και όλες οι διαχειριστικές ενέργειες που πρέπει να γίνουν για τη σωστή του λειτουργία στο στάδιο της εγκατάστασής του στον ηλεκτρονικό υπολογιστή του ΑΜΑ χρήστη. Ο ΟΔΥΣΣΕΑΣ και το Διαδίκτυο Η σχέση του πλαισίου ΟΔΥΣΣΕΑΣ με το Διαδίκτυο δεν περιορίζεται στην εγγενή υποστήριξη του Διαδικτύου από την αρχιτεκτονική του. Το πλαίσιο χρησιμοποιεί το Διαδίκτυο ως ένα πολύτιμο εργαλείο. Τα προϊόντα της υλοποίησης του ΟΔΥΣΣΕΑ, πρέπει να βρίσκονται διαθέσιμα στο Διαδίκτυο για να χρησιμοποιούνται από τους κατασκευαστές και τους πωλητές Βοηθημάτων Διαπροσωπικής Επικοινωνίας. Συγκεκριμένα διανέμονται ελεύθερα από το Διαδίκτυο τμήματα λογισμικού (βιβλιοθήκες, έτοιμα συστατικά δοκιμών και συστατικά αναφοράς) που αναπτύχθηκαν και έχουν σκοπό: την τυποποίηση της επικοινωνίας μεταξύ των συστατικών (βιβλιοθήκη Interface.dll) τον έλεγχο της συμβατότητας των συστατικών (υλοποιημένα συστατικά εισόδου, εξόδου και ενδιάμεσα συστατικά) την υποβοήθηση συγγραφής κώδικα για συστατικά του ΟΔΥΣΣΕΑ (in1.dll, out1.dll, MidComponent1.dll) την εκκίνηση ενός βοηθήματος Διαπροσωπικής Επικοινωνίας και των συστατικών του (Communicator.exe) Φυσικά τα συστατικά και οι βιβλιοθήκες που αναφέρθηκαν είναι διαθέσιμα και ως δυαδικά αρχεία, αλλά και ως κώδικας. Δεν είναι όμως μόνο αυτό. Διαθέσιμα στο Διαδίκτυο βρίσκονται και όλες οι τυποποιήσεις και οι οδηγίες που δίνει ο ΟΔΥΣΣΕΑΣ προς του κατασκευαστές, αλλά και το εγχειρίδιο χρήσης για την Εγκατάσταση Βοηθημάτων Διαπροσωπικής Επικοινωνίας που βασίζονται στο πλαίσιο ΟΔΥΣΣΕΑΣ. Τέλος ο ρόλος του Διαδικτύου είναι σημαντικότατος γιατί εκεί υπολογίζεται ότι θα συγκεντρώνεται κάθε νέα πληροφορία για νέα διαθέσιμα συστατικά Βοηθημάτων Διαπροσωπικής Επικοινωνίας, είτε αυτά κατασκευαστούν στα πλαίσια της παρούσας εργασίας, είτε ανεξάρτητα από τρίτους κατασκευαστές. Θα είναι η πηγή για τους πωλητές και για κάθε ενδιαφερόμενο, όπου μπορούν να δουν τι υπάρχει διαθέσιμο για τη σύνθεση ενός πλήρους βοηθήματος, αλλά και τον τρόπο που θα γίνει η σύνθεση αυτή. Η δομή του δεύτερου μέρους της εργασίας Στο δεύτερο μέρος της εργασίας σκοπεύουμε να περιγράψουμε την υλοποίηση του πλαισίου ΟΔΥΣΣΕΑΣ, και να εκθέσουμε τις τυποποιήσεις και τις οδηγίες του. Επιπλέον, Σελίδα 96 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

97 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» θα δοθεί ο κώδικας για όλα τα τμήματα λογισμικού που αναπτύχθηκαν στα πλαίσια του ΟΔΥΣΣΕΑ, καθώς και το Εγχειρίδιο Χρήσης. Το δεύτερο μέρος της εργασίας αποτελείται από πέντε κεφάλαια, το πρώτο από τα οποία είναι αυτή η Εισαγωγή. Στο δεύτερο κεφάλαιο περιλαμβάνονται οι τυποποιήσεις και οι οδηγίες που παρέχει το πλαίσιο ΟΔΥΣΣΕΑΣ στους κατασκευαστές συστατικών για Βοηθήματα Διαπροσωπικής Επικοινωνίας. Στις τυποποιήσει περιλαμβάνονται η γενική τυποποίηση για εφαρμογές των Windows 2000, η τυποποίηση για το μοντέλο αντικειμένων και συστατικών και η τυποποίηση για τις υπηρεσίες συστατικών. Στις οδηγίες περιλαμβάνονται προδιαγραφές που ρητά ζητά ο ΟΔΥΣΣΕΑΣ να έχουν τα συστατικά του, όπως για παράδειγμα συγκεκριμένη μορφή αρχείων συγκεκριμένο μοντέλο νημάτων (threading model) και συγκεκριμένη ονοματολογία των κλάσεών τους. Τέλος στο δεύτερο κεφάλαιο περιγράφεται και η υλοποίηση της βασικής διεπαφής επικοινωνίας του ΟΔΥΣΣΕΑ. Το τρίτο κεφάλαιο αποτελεί το Εγχειρίδιο Χρήσης που αφορά τους πωλητές Βοηθημάτων Διαπροσωπικής Επικοινωνίας. Περιέχει λεπτομερείς οδηγίες για τις διαδικασίες εγκατάστασης Βοηθημάτων Διαπροσωπικής Επικοινωνίας και των συστατικών τους. Το Εγχειρίδιο Χρήσης καλύπτει τυπικές περιπτώσεις εγκατάσταση απλών Βοηθημάτων με μικρό αριθμό συστατικών, αλλά και περιπτώσεις πιο σύνθετων Βοηθημάτων με μεγάλο αριθμό συστατικών, όπου παρουσιάζεται η ανάγκη για συγχρονισμό και τοποθέτηση σε σειρά των μηνυμάτων μεταξύ των συστατικών. Το τέταρτο κεφάλαιο ασχολείται με την υλοποίηση των δοκιμαστικών συστατικών που αποτελούν εργαλεία του πλαισίου ΟΔΥΣΣΕΑΣ. Ένας σκοπός που εξυπηρετούν αυτά τα εργαλεία, είναι η διευκόλυνση της αποσφαλμάτωσης της λειτουργίας των συστατικών τρίτων κατασκευαστών, μέσω του ελέγχου της λειτουργίας τους με τη χρήση των δοκιμαστικών συστατικών. Ένας δεύτερος είναι ο έλεγχος της συμβατότητας συστατικών με το πλαίσιο ΟΔΥΣΣΕΑΣ μέσω της σωστής συνεργασίας τους με τα δοκιμαστικά συστατικά. Τέλος αυτά τα συστατικά χρησιμεύουν ως πρότυπα για τον τρόπο που πρέπει να χρησιμοποιούνται κατά τον προγραμματισμό οι υπηρεσίες του συστήματος και οι διεπαφές του ΟΔΥΣΣΕΑ. Ο κώδικας αυτών των συστατικών διανέμεται ελεύθερα και παρουσιάζεται στο κεφάλαιο αυτό. Το έκτο κεφάλαιο περιλαμβάνει τα συμπεράσματα από την επιτυχημένη προσπάθεια υλοποίησης του ΟΔΥΣΣΕΑ, αλλά και προβλήματα που συνάντησε η ομάδα ανάπτυξης κατά την υλοποίηση αυτή. Τέλος αναφέρονται μελλοντικά σχέδια βελτίωσης του πλαισίου και μελλοντικές δυνατότητες που μπορούν να ενσωματωθούν σε αυτό. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 97 από 163

98

99 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» 2. Ο ΟΔΥΣΣΕΑΣ για τους Προγραμματιστές 2.1. Γενικές Τυποποιήσεις Τυποποίηση για Εφαρμογές των Windows 2000 MSDN Library: "Application Specification for Windows 2000 for Desktop Applications" Ο "Οδηγός Σχεδίασης για την κατασκευή Εφαρμογών", αναπτύχθηκε από τη Microsoft Corporation σε συνεργασία με πελάτες της και τρίτους κατασκευαστές για γίνει ο τεχνικός καθορισμός του μοντέλου των εφαρμογών για τα Windows Αυτή η τυποποίηση θα βοηθήσει τους κατασκευαστές λογισμικού να εκμεταλλευτούν τις νέες τεχνολογίες των Windows 2000 έτσι ώστε οι εφαρμογές τους να είναι πιο εύκολες στη διαχείριση, πιο αξιόπιστες και να μειωθεί το κόστος κτήσης τους για τους τελικούς πελάτες. Προορίζεται για κατασκευαστές όλων των ειδών, συμπεριλαμβανομένων και των ανεξάρτητων πωλητών λογισμικού και των εταιριών κατασκευής εφαρμογών. Τα βασικά πλεονεκτήματα που προσφέρει η υιοθέτηση αυτής της τυποποίησης για τα βοηθήματα Διαπροσωπικής Επικοινωνίας είναι τα εξής: Παρέχει μια συμπαγή, αυτοσυντηρούμενη εγκατάσταση που βοηθά στην αποφυγή των διενέξεων μεταξύ διαμοιραζόμενων συστατικών και επιτρέπει την καλύτερη συνύπαρξη των εφαρμογών. Επιτρέπει την ευκολότερη ανάπτυξη και συντήρηση του λογισμικού. Επιτρέπει τη σωστή συντήρηση των προτιμήσεων του χρήστη και των ρυθμίσεων του υπολογιστή. Υποστηρίζει την τεχνολογία διαχείρισης ενέργειας OnNow για την καλύτερη λειτουργία των εφαρμογών σε φορητούς υπολογιστές. Υποστηρίζει τις τυποποιήσεις προσβασιμότητας (accessibility standards) για τη μείωση του κόστους υποστήριξης και εκπαίδευσης. Τα στοιχεία της τυποποίησης τα οποία μας ενδιαφέρουν ιδιαίτερα είναι τα εξής: Για τα βασικά στοιχεία των Windows: Ένα προϊόν που συμμορφώνεται με την τυποποίηση δεν επηρεάζει αρνητικά την αξιοπιστία του λειτουργικού συστήματος. Πρέπει να επιτυγχάνεται η πρωταρχική λειτουργικότητα και να διατηρείται η σταθερότητα του λειτουργικού συστήματος. Πρέπει να παρέχονται 32μπιτα συστατικά. Πρέπει να υποστηρίζονται μακριά ονόματα αρχείων και διαδρομές UNC (Universal Naming Convention). Πρέπει να υποστηρίζονται εκτυπωτές με μακριά ονόματα αρχείων και διαδρομές UNC. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 99 από 163

100 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Δεν πρέπει να γίνεται εγγραφή ή ανάγνωση στα αρχεία Autoexec.bat, Config.sys, Win.ini, System.ini. Πρέπει να διασφαλιστεί ότι τα μη κρυφά αρχεία που βρίσκονται έξω από τον φάκελο της εφαρμογής έχουν τύπο αρχείου συσχετισμένο με εικονίδιο, περιγραφή και ενέργεια. Αν γίνεται έλεγχος της έκδοσης των Windows, αυτή να γίνεται σωστά. Πρέπει να υποστηρίζεται η λειτουργία AutoPlay για τα CD. Για τις υπηρεσίες του Windows Installer: Τα θέματα εγκατάστασης και απεγκατάστασης είναι οι πιο κοινές πηγές προβλημάτων διαλειτουργικότητας των εφαρμογών. Οι παρακάτω απαιτήσεις βοηθούν στη διασφάλιση ότι οι διαδικασίες της εγκατάστασης και της απεγκατάστασης θα είναι επιτυχείς και ότι η εφαρμογή θα συνυπάρχει με φιλικό τρόπο με άλλες εφαρμογές. Η υπηρεσία Windows Installer είναι ένα συστατικό (component) του λειτουργικού συστήματος που διαχειρίζεται κεντρικά τις ρυθμίσεις της εγκατάστασης εφαρμογών, όπως επίσης και της απεγκατάστασης. Η χρήση της υπηρεσίας Windows Installer επιτρέπει στο λειτουργικό σύστημα να διαχειρίζεται τη ρύθμιση των εφαρμογών. Συνίσταται οποιαδήποτε διαδικασία εγκατάστασης να γίνεται με τη χρήση πακέτου που βασίζεται στο Windows Installer. Πρέπει να ακολουθούνται οι κανόνες που αφορούν το διαχωρισμό των εφαρμογών σε συστατικά και η διαχείρισή τους. Πρέπει να καθορίζονται και να δηλώνονται σωστά τα διαμοιραζόμενα συστατικά. Η εγκατάσταση πρέπει να γίνεται στον κατάλογο Program Files. Πρέπει να υποστηρίζεται σωστά η λειτουργία της Προσθαφαίρεσης Προγραμμάτων. Πρέπει να προβλέπεται η καθαρή απεγκατάσταση. Για το διαμοιρασμό των συστατικών: Ένα επίσης ευαίσθητο και επικίνδυνο θέμα για τη σταθερότητα του συστήματος και τη σωστή λειτουργία των εφαρμογών είναι αυτό του διαμοιρασμού των συστατικών. Υπάρχουν περιπτώσεις όπου παραπάνω από μία εφαρμογές μπορεί να χρησιμοποιούν το ίδιο συστατικό (component). Το πρόβλημα παρουσιάζεται όταν δύο εφαρμογές πρέπει να λειτουργούν με διαφορετική έκδοση του ίδιου συστατικού. Τότε είναι πολύ πιθανό μία από τις δύο ή περισσότερες εφαρμογές να χάσει τη συμβατότητά της με το νέο συστατικό (component) και να σταματήσει να λειτουργεί κανονικά. Τα Windows 2000 εισάγουν ένα νέο τύπο διαμοιρασμού που λέγεται side by side διαμοιρασμός και ελαχιστοποιεί αυτήν την ευθραυστότητα των εφαρμογών. Ο side by side διαμοιρασμός επιτρέπει σε διαφορετικές Εκδόσεις του ίδιου COM ή Win32 συστατικού να τρέχουν ταυτόχρονα στη μνήμη. Αυτό σημαίνει ότι οι εφαρμογές μπορούν να χρησιμοποιούν τα συγκεκριμένα συστατικά για τα οποία σχεδιάστηκαν και με τα οποία δοκιμάστηκαν, ακόμα κι αν μια άλλη εφαρμογή χρειάζεται μια διαφορετική έκδοση του ίδιου συστατικού. Τα side by side συστατικά είναι συνηθισμένα COM ή Win32 συστατικά εκτός του ότι: Εγκαθίστανται στο φάκελο της εφαρμογής και όχι σε αυτόν του συστήματος. Σελίδα 100 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

101 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Πρέπει να δηλώνονται σωστά στο σύστημα, ώστε να μη συγκρούονται με άλλες Εκδόσεις του συστατικού που μπορεί να υπάρχουν. Οι απαιτήσεις είναι οι εξής: Στα Windows 2000 δεν θα πρέπει να επιχειρείται η αντικατάσταση αρχείων που προστατεύονται από την Προστασία Αρχείων των Windows (Windows File Protection). Οι κατασκευαστές των συστατικών πρέπει να χρησιμοποιούν τις side by side τεχνικές και τους ανάλογους κανόνες. Για τη διεπαφή χρήσης: Η συνέπεια και η προσβασιμότητα στις εφαρμογές που βασίζονται στα Windows βοηθούν στην εμπιστοσύνη του χρήση προς το σύστημα και στην φιλικότητα της εφαρμογής προς τον χρήστη. Η συμμόρφωση με τις τυποποιήσεις για τη Διεπαφή Χρήσης επιτρέπει τη χρήση εξελιγμένων εργαλείων αυτοματισμού, όπως εργαλεία δοκιμών, εργαλεία αυτοματοποίησης εργασιών όπως οι έξυπνοι agents, κι την υποστήριξη νέων μεθόδων εισόδου όπως την είσοδο φωνής. Είναι πολύ βασικό να είναι η σχεδίαση προσανατολισμένη στο χρήστη, ανθρωποκεντρική και με υποστήριξη για άτομα με Αναπηρία. Οι απαιτήσεις είναι οι εξής: Πρέπει να υποστηρίζονται οι τυπικές ρυθμίσεις του συστήματος για τα μεγέθη, τα χρώματα, τις γραμματοσειρές και την είσοδο. Πρέπει να διασφαλίζεται η συμβατότητα με την επιλογή της Υψηλής Αντίθεσης. Πρέπει να παρέχεται τεκμηριωμένη πρόσβαση από το πληκτρολόγιο σε όλες τις λειτουργίες. Πρέπει να γίνεται φανερή η θέση της εστίασης του πληκτρολογίου. Δεν πρέπει να στηρίζεται η αλληλεπίδραση μόνο στον ήχο. Δεν πρέπει να τοποθετούνται στον Κατάλογο Επιλογών Έναρξης (Start Menu) συντομεύσεις σε έγγραφα, βοήθεια ή απεγκαταστάσεις. Για τη Διαχείριση Ενέργειας: Η σχεδίαση OnNow είναι ένα σύνολο από προδιαγραφές για το hardware του συστήματος και τις εφαρμογές λογισμικού, οι οποίες επιτρέπουν σε έναν υπολογιστή να προσφέρει τη δυνατότητα της άλεσης διαθεσιμότητας που περιμένουν οι χρήστες από όλες τις ηλεκτρονικές συσκευές τους. Οι εφαρμογές πρέπει να συμμετέχουν στις αποφάσεις του συστήματος σχετικά με τη διαχείριση ενέργειας και να ανταποκρίνονται χωρίς σφάλματα στα σενάρια διακοπής και αποκατάστασης της τροφοδοσίας του συστήματος. Αυτή η συμμετοχή περιλαμβάνει τη σωστή ανταπόκριση σε γεγονότα όπως αιτήσεις sleep και ειδοποιήσεις wake, έτσι ώστε να διατηρούνται τα δεδομένα των χρηστών και των εφαρμογών ανέπαφα. Η τεχνολογία OnNow μειώνει την κατανάλωση ενέργειας μέσω της Διεπαφής Προχωρημένων Ρυθμίσεων και Ενέργειας (Advanced Configuration and Power Interface ACPI). Το σύστημα έχει την ικανότητα να έρχεται σε μια κατάσταση χαμηλής κατανάλωσης ενέργειας (ή sleep mode) στην οποία φαίνεται να είναι κλειστό, ενώ στην ουσία είναι τροφοδοτούμενο με ενέργεια αρκετή για να του επιτραπεί να επανέλθει (ή να Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 101 από 163

102 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» "ξυπνήσει wake"). Ο υπολογιστής μπορεί να είναι άμεσα διαθέσιμος στο χρήστη μια και μπορεί να επανέλθει γρήγορα από μια κατάσταση χαμηλής κατανάλωσης σε μια πλήρως λειτουργική κατάσταση. Οι απαιτήσεις είναι οι εξής: Για τις εφαρμογές στις οποίες επιτρέπεται να εμποδίζουν τη διαδικασία sleep (χαμηλής κατανάλωσης ενέργειας) όταν είναι απασχολημένες, πρέπει να γίνεται φανερή η ιδιότητα απασχολημένη εφαρμογής (busy application). Πρέπει να υποστηρίζονται σωστά οι αιτήσεις sleep και wake (να επιτρέπονται στην περίπτωση της "αποσυνδεδεμένης" ή "μη απασχολημένης" κατάστασης και να διαχειρίζονται σωστά στην αντίθετη περίπτωση "συνδεδεμένης" ή "απασχολημένης" κατάστασης. Θα πρέπει να αντιμετωπίζεται η διαδικασία πτώσης της κατανάλωσης ενέργειας και η διαδικασία επαναφοράς του συστήματος χωρίς την απώλεια δεδομένων. Θα πρέπει να αντιμετωπίζεται η απρόβλεπτη απώλεια ενέργειας του συστήματος με σωστό τρόπο. Σελίδα 102 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

103 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Τυποποίηση Μοντέλου Αντικειμένων και Συστατικών (COM) MSDN Library: "Component Object Model (COM)" Η τυποποίηση αυτή έχει περιγραφεί στο κεφάλαιο COM (Component Object Model) του Α μέρους και είναι διαθέσιμη στο Διαδίκτυο στην on-line βιβλιοθήκη της Microsoft: MSDN Library/Specifications/Component Object Model (COM) Specification 0.9. Ηλεκτρονική διεύθυνση Σχήμα 26: Τα περιεχόμενα της τυποποίησης του CΟΜ στην ηλεκτρονική βιβλιοθήκη της Microsoft. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 103 από 163

104 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Επέκταση τυποποίησης Μοντέλου Αντικειμένων και Συστατικών (COM+) MSDN Library: "COM+" Η τυποποίηση αυτή έχει περιγραφεί στο κεφάλαιο COM+ (Component Services) του A μέρους της παρούσας εργασίας και είναι διαθέσιμη στο Διαδίκτυο στην on-line βιβλιοθήκη της Microsoft: MSDN Library/Platform SDK/Component Services/COM+ (Component Services). Ηλεκτρονική διεύθυνση default.asp. Σχήμα 27: Τα περιεχόμενα της τυποποίησης του CΟΜ+ στην ηλεκτρονική βιβλιοθήκη της Microsoft. Σελίδα 104 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

105 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» 2.2. Ειδικές Οδηγίες του ΟΔΥΣΣΕΑ Μορφή Συστατικών DLL Βασικότερη από όλες τις προδιαγραφές που θέτει ο ΟΔΥΣΣΕΑΣ στους κατασκευαστές των συστατικών του Βοηθήματος Διαπροσωπικής Επικοινωνίας είναι τα προϊόντα τους να έρχονται σε μορφή αρχείων DLL (Βιβλιοθήκες Δυναμικής Σύνδεσης - Dynamic Link Libraries). Ο κύριος λόγος για τη θέσπιση αυτής της προδιαγραφής είναι ότι, σύμφωνα με το σχεδιασμό του ΟΔΥΣΣΕΑ, όλα τα συστατικά που πρόκειται να ενσωματωθούν σε μια ολοκληρωμένη εφαρμογή, δηλώνονται στο Component Services των Windows Για να δηλωθεί οποιοδήποτε συστατικό (component) ως μέρος μιας εφαρμογής στο Component Services πρέπει να είναι σε μορφή DLL. Σχήμα 28: Πλαίσιο διαλόγου για την εκκίνηση της δημιουργίας ενός ActiveX DLL στη Microsoft Visual Basic 6.0. Φυσικά ο προγραμματισμός κάθε τέτοιου συστατικού πρέπει να γίνει με τα μοντέρνα εργαλεία και γλώσσες προγραμματισμού που μπορούν να υποστηρίξουν τη δημιουργία τέτοιας μορφής αρχείων, αλλά και παράγουν αρχεία συμβατά με τις τυποποιήσεις του COM και του COM+. Αυτή τη συμβατότητα μπορεί να την ελέγξει κάποιος προγραμματιστής δοκιμάζοντας να δηλώσει ως νέο συστατικό σε μια εφαρμογή στα Component Services. Κατά τη διάρκεια αυτής της διαδικασίας φαίνεται αν το σύστημα αναγνωρίζει το συστατικό ως ένα DLL συμβατό με COM+ και αν υπάρχει κάποιο σοβαρό πρόβλημα συμβατότητας το σύστημα ειδοποιεί το χρήστη με μηνύματα σφάλματος. Ένα Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 105 από 163

106 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» περαιτέρω βήμα για τον έλεγχο των συστατικών με το πλαίσιο ΟΔΥΣΣΕΑΣ είναι να προμηθευτεί ο κατασκευαστής το δοκιμαστικό πρόγραμμα φόρτωσης των συστατικών και τα δοκιμαστικά προγράμματα αποστολής και λήψης COM+ Events που έχουν ήδη περιγραφεί και να ακολουθήσει τις διαδικασίες φόρτωσης και εκκίνησης του Βοηθήματος Διαπροσωπικής Επικοινωνίας, όπως θα έκανε και σε πραγματικές συνθήκες ένας πωλητής ενός τέτοιου συστήματος. Όλα αυτά τα προγράμματα είναι ελεύθερα προς διανομή στο Διαδικτυακό τόπο του έργου. Σχήμα 29: Πλαίσιο διαλόγου για την κατασκευή ενός DLL εφαρμογής ATL COM στη Microsoft Visual C Σελίδα 106 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

107 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Διεπαφή χρήσης η κλάση Activate Κάθε συστατικό που είναι συμβατό με το Πλαίσιο Ανάπτυξης Εφαρμογών ΟΔΥΣΣΕΑΣ και πρέπει να εμφανίζει μια διεπαφή χρήσης κατά τη λειτουργία του, θα πρέπει οπωσδήποτε να περιέχει μια κλάση με το όνομα Activate. Το όνομα της κλάσης αυτής είναι αυστηρά καθορισμένο από τις προδιαγραφές του ΟΔΥΣΣΕΑ και πρέπει να χρησιμοποιείται μόνο για τη λειτουργία που περιγράφεται εδώ. Επίσης, πρέπει να σημειωθεί ότι είναι case-sensitive, που σημαίνει ότι το πρώτο γράμμα πρέπει οπωσδήποτε να είναι κεφαλαίο και τα υπόλοιπα πεζά όπως ακριβώς γράφηκε παραπάνω. Αν και κάθε αντικείμενο που συμμετέχει στην «ορχήστρα» των συστατικών ενός Βοηθήματος Διαπροσωπικής Επικοινωνίας βασισμένου στον ΟΔΥΣΣΕΑ έχει τον τυπικό τρόπο ενεργοποίησης μέσω της υπηρεσίας γεγονότων των Windows 2000, τα αντικείμενα που αντιπροσωπεύουν τις αρχικές διεπαφές χρήσης των συστατικών δεν μπορούν να ξεκινούν με τον ίδιο αυτόματο τρόπο. Αυτό είναι λογικό μια και κατά τον αυτόματο τρόπο ενεργοποίησης των επιθυμητών αντικειμένων που συμμετέχουν κατά οποιοδήποτε τρόπο στις υπηρεσίες γεγονότων (είτε ως Εκδότες είτε ως Συνδρομητές) χρειάζεται κάποιο ερέθισμα από τον χρήστη για να εκκινηθούν οι διαδικασίες του συστήματος. Και βέβαια για μπορέσει να δώσει ο χρήστης είσοδο στο Βοήθημα Διαπροσωπικής Επικοινωνίας θα πρέπει να υπάρχει ήδη κάποια ενεργοποιημένη διεπαφή χρήσης. Επίσης, αυτή η διεπαφή χρήσης θα πρέπει να είναι ολοκληρωμένη μπροστά στον χρήστη κατά τη διάρκεια όλης της αλληλεπίδρασής του με το σύστημα. Το πρόβλημα ήταν λοιπόν πως θα ξεδίπλωναν όλα τα συστατικά το καθένα τη δική του διεπαφή χρήσης, συνθέτοντας έτσι την ολοκληρωμένη διεπαφή χρήσης του Βοηθήματος. Ακόμη, θα έπρεπε η εμφάνιση όλων αυτών των διεπαφών χρήσης να γίνεται ταυτόχρονα και αυτόματα κατά την εκκίνηση του Βοηθήματος, χωρίς βέβαια να απαιτείται από τον πιθανώς μειωμένων δυνατοτήτων χρήστη να ενεργοποιήσει το κάθε συστατικό που χρειάζεται ξεχωριστά. Αυτό το πρόβλημα ήρθε να λύσει η κλάση Activate. Κατασκευάστηκε ένα πρόγραμμα εκκίνησης του Βοηθήματος το οποίο μεταξύ άλλων λειτουργιών ανέλαβε και το καθήκον της ενεργοποίησης των αρχικών διεπαφών χρήσης όλων των χρησιμοποιούμενων συστατικών. Αυτό το πρόγραμμα, το οποίο γράφτηκε στη γλώσσα Microsoft Visual Basic 6.0 (Service Pack 4), ενεργοποιεί την κλάση Activate με την εξής διαδικασία: Ανοίγει το Component Catalog του λειτουργικού συστήματος. Αναζητά την εφαρμογή με το όνομα AENEAS. Μέσα στη συγκεκριμένη εφαρμογή αναζητά όλα τα συστατικά (αντικείμενα) που το όνομά τους καταλήγει σε.activate. Σημείωση: Κάθε DLL που εγκαθίσταται στα Component Services των Windows 2000 μπορεί να έχει πολλές κλάσεις και κατ επέκταση πολλά αντικείμενα ενσωματωμένα. Αυτά φαίνονται και κατά την εγκατάστασή του αλλά και στο Component Catalog. Υπάρχουν εκεί καταχωρήσεις με την εξής μορφή: ΌνομαDLL.ΌνομαΚλάσης Ενεργοποιεί όλα αυτά τα αντικείμενα (μέσω της CreateObject). Αυτό είναι και το πρόγραμμα που πρέπει να εκτελέσει ο τελικός χρήστης για να ξεκινήσει το Βοήθημα Διαπροσωπικής Επικοινωνίας του. Το αποτέλεσμα της παραπάνω διαδικασίας Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 107 από 163

108 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» είναι να εμφανιστούν όλες οι διεπαφές χρήσης των συστατικών που είναι εγκατεστημένα στην εφαρμογή AENEAS. Η τεχνική για να ενεργοποιείται η διεπαφή χρήσης ενός συστατικού κατά την ενεργοποίηση μιας κλάσης του είναι να εισάγεται μέσω προγραμματισμού η εμφάνιση της επιθυμητής φόρμας στη μέθοδο αρχικοποίησης της συγκεκριμένης κλάσης (για τη Visual Basic είναι η Class_Initialize). Βέβαια, μπορεί να υπάρχουν και συστατικά τα οποία δεν απαιτούν την ύπαρξη μιας διεπαφής χρήσης κατά τη λειτουργία τους. Για παράδειγμα, ένα συστατικό Μετατροπής Ασύντακτων Προτάσεων σε συντεταγμένες (π.χ. από «θέλω βλέπω τηλεόραση βράδυ» σε «θέλω να δω τηλεόραση το βράδυ») μπορεί να λειτουργεί στο παρασκήνιο, παρεμβαλλόμενο μεταξύ ενός συστατικού εισόδου (π.χ. ένα Εικονικό Πληκτρολόγιο) και ενός συστατικού εξόδου (π.χ. ένας Συνθέτης Ομιλίας). Το συγκεκριμένο λοιπόν συστατικό μπορεί να λειτουργεί χωρίς να κάνει ποτέ την εμφάνισή του με τη μορφή μιας διεπαφής χρήσης και δε χρειάζεται να έχει την κλάση Activate (βλέπε Σχήμα 10). Η έναρξη της λειτουργίας του, όπου αυτή χρειάζεται γίνεται από το λειτουργικό σύστημα μέσω των υπηρεσιών γεγονότων. Φυσικά πρέπει να έχουν τηρηθεί όλες οι άλλες προδιαγραφές που αφορούν στην λειτουργία ενός συστατικού με αυτόν τον τρόπο. Όταν μια ασύντακτη πρόταση «εκδίδεται» από ένα εικονικό πληκτρολόγιο, δημιουργείται ένα αντικείμενο του συγκεκριμένου συστατικού (μπορεί να συναντηθεί και με το όνομα Parser) το οποίο είναι Συνδρομητής με Συνδρομή στον Εκδότη Εικονικό Πληκτρολόγιο. Στο συγκεκριμένο παράδειγμα, ούτε και το συστατικό εξόδου, δηλαδή ο Συνθέτης Ομιλίας είναι απαραίτητο να έχει την κλάση Activate. Μπορεί και αυτό να λειτουργεί στο παρασκήνιο και να μη χρειάζεται διεπαφή χρήσης κατά την εκκίνησή του. Βέβαια το Εικονικό πληκτρολόγιο χρειάζεται διεπαφή χρήσης για να δίνει ο χρήστης την είσοδο στο Βοήθημα πατώντας τα πλήκτρα του. Συστατικό Εισόδου Εικονικό Πληκτρολόγιο Ενδιάμεσο Συστατικό Μετατροπή ασύντακτων Προτάσεων σε Συντεταγμένες Συστατικό Εξόδου Συνθέτης Ομιλίας Ασύντακτη Πρόταση Συντεταγμένη Πρόταση Είσοδος από χρήστη με πάτημα επιθυμητών πλήκτρων λέξεων. Έξοδος Βοηθήματος: Εκφώνηση της συντεταγμένης πρότασης. Σχήμα 30: Παράδειγμα Βοηθήματος Διαπροσωπικής Επικοινωνίας αποτελούμενου από τρία συστατικά. Σελίδα 108 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

109 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Μοντέλο νημάτων Single Threaded ΠΡΟΣΟΧΗ: Αυτή η οδηγία αναφέρεται σε όσα συστατικά διαθέτουν User Interface κατά το χρόνο εκτέλεσης και ειδικότερα σε όσα η διεπαφή χρήσης τους συμπίπτει με την κλάση Activate. Η οδηγία αυτή αφορά το μοντέλο νημάτων (threading model) των συστατικών που πρόκειται να ενσωματωθούν σε ένα Βοήθημα Διαπροσωπικής Επικοινωνίας που υποστηρίζεται από το πλαίσιο ΟΔΥΣΣΕΑΣ. Τα μοντέλα νημάτων στο COM παρέχουν το μηχανισμό για να συνεργάζονται συστατικά που χρησιμοποιούν διαφορετικές αρχιτεκτονικές νημάτων. Επίσης, παρέχουν υπηρεσίες συγχρονισμού στα συστατικά που τις χρειάζονται. Για παράδειγμα, ένα συγκεκριμένο αντικείμενο μπορεί να είναι σχεδιασμένο να καλείται μόνο από ένα μονό νήμα και μπορεί να μη συγχρονίζει ταυτόχρονες κλήσεις από πελάτες. Αν ένα τέτοιο αντικείμενο καλεστεί ταυτόχρονα από πολλαπλά νήματα, καταρρέει ή προκαλεί σφάλματα. Το COM παρέχει τους μηχανισμούς για τη διαχείριση της διαλειτουργικότητας των αρχιτεκτονικών των νημάτων. Ακόμα και συστατικά που υποστηρίζουν τα νήματα, συχνά χρειάζονται υπηρεσίες συγχρονισμού. Για παράδειγμα, συστατικά που έχουν μια γραφική διεπαφή χρήσης (graphical user interface GUI), όπως τα OLE/ActiveX controls, τα in-place active embeddings, και τα ActiveX documents, απαιτούν συγχρονισμό και σειριακή διάταξη των κλήσεων του COM και των μηνυμάτων των παραθύρων. Το COM παρέχει αυτές τις υπηρεσίες συγχρονισμού έτσι ώστε αυτά τα COM συστατικά να μπορούν να γραφτούν χωρίς πολύπλοκο κώδικα συγχρονισμού. Ένα "διαμέρισμα" ("apartment") έχει αρκετές συσχετιζόμενες όψεις. Πρώτον, είναι μια λογική κατασκευή για να μας βοηθά να σκεφτόμαστε την ταυτόχρονη συνεργασία (concurrency), όπως το πώς τα νήματα σχετίζονται με ένα σύνολο από COM αντικείμενα. Δεύτερον, είναι ένα σύνολο από κανόνες που πρέπει να ακολουθούν οι προγραμματιστές για να επιτυγχάνουν τη συμπεριφορά της ταυτόχρονης συνεργασίας που περιμένουν από το περιβάλλον του COM. Τέλος, είναι κώδικας που παρέχεται από το σύστημα και βοηθά τους προγραμματιστές να διαχειριστούν την ταυτόχρονη συνεργασία σε σχέση με τα αντικείμενα του COM. Ο όρος διαμέρισμα" ("apartment") προέρχεται από μια μεταφορά στην οποία μια διεργασία θεωρείται μια εντελώς διακριτή οντότητα, όπως ένα "κτίριο" που χωρίζεται σε ένα σύνολο από συσχετιζόμενες αλλά διαφορετικές "τοποθεσίες" που λέγονται διαμερίσματα". Ένα διαμέρισμα είναι ένα "λογικό δοχείο" που δημιουργεί μια συσχέτιση μεταξύ αντικειμένων και, σε μερικές περιπτώσεις, νημάτων (threads). Τα νήματα δεν είναι διαμερίσματα, αν και μπορεί να υπάρχει ένα μονό νήμα που είναι λογικά συσχετισμένο με ένα διαμέρισμα στο μοντέλο STA. Τα αντικείμενα δεν είναι διαμερίσματα, αν και κάθε αντικείμενο είναι συσχετισμένο με ένα και μοναδικό διαμέρισμα. Όμως τα διαμερίσματα είναι κάτι περισσότερο από μια λογική κατασκευή: οι κανόνες τους περιγράφουν τη συμπεριφορά του συστήματος COM. Αν δεν ακολουθούνται οι κανόνες των μοντέλων διαμερισμάτων, τα αντικείμενα του COM δεν λειτουργούν σωστά. Τα COM αντικείμενα μπορούν να χρησιμοποιηθούν σε πολλαπλά νήματα μιας διεργασίας. Οι όροι "Διαμέρισμα Μονού Νήματος Single Threaded Apartment STA" και "Διαμέρισμα Πολλαπλών Νημάτων Multi Threaded Apartment MTA" χρησιμοποιούνται για τη δημιουργία ενός εννοιολογικού πλαισίου για την περιγραφή της σχέσης μεταξύ των αντικειμένων και των νημάτων, τις σχέσεις συνεργασίας μεταξύ των Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 109 από 163

110 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» αντικειμένων, τις μεθόδους με τις οποίες οι κλήσεις μεθόδων παραδίδονται στα αντικείμενα και των κανόνων για το πέρασμα δεικτών διεπαφών μεταξύ νημάτων. Τα συστατικά και οι πελάτες τους επιλέγουν μεταξύ των δύο μοντέλων που υποστηρίζονται από το COM: 1) Single-threaded Apartment model (STA): Ένα ή περισσότερα νήματα σε μια διεργασία χρησιμοποιούν το COM και οι κλήσεις στα αντικείμενα του COM συγχρονίζονται από το COM. Οι διεπαφές γίνονται marshaled μεταξύ των νημάτων. Μια εκφυλισμένη περίπτωση του μοντέλου διαμερισμάτων μονού νήματος, όπου μόνο ένα νήμα μέσα σε μια δεδομένη διεργασία χρησιμοποιεί COM, ονομάζεται μοντέλο μονού νήματος (Single-Threaded Model). 2) Multi-threaded Apartment Model (MTA): Ένα ή περισσότερα νήματα χρησιμοποιούν το COM και οι κλήσεις στα COM αντικείμενα που υπακούουν στο MTA γίνονται απ' ευθείας από όλα τα νήματα που υπακούουν στο MTA χωρίς καμία παρέμβαση του κώδικα του συστήματος μεταξύ του καλούντα και του αντικειμένου. Επειδή μπορεί πολλαπλοί ταυτόχρονοι πελάτες να καλούν αντικείμενα λίγο πολύ ταυτόχρονα (ταυτόχρονα σε συστήματα πολλαπλών επεξεργαστών), τα αντικείμενα πρέπει να συγχρονίζουν την εσωτερική τους κατάσταση από μόνα τους. Οι διεπαφές δεν γίνονται marshaled μεταξύ των νημάτων. 3) Το μοντέλο STA και το μοντέλο MTA μπορούν να χρησιμοποιηθούν μαζί στην ίδια διεργασία. Αυτές οι διεργασίες αναφέρονται και ως διεργασίες "μικτού μοντέλου". Ένα συστατικό μπορεί να επιλέξει να υποστηρίξει το μοντέλο STA, το μοντέλο MTA, ή ένα συνδυασμό των δύο χρησιμοποιώντας το μοντέλο των μικτών νημάτων. Για παράδειγμα, ένα αντικείμενο που κάνει μεγάλη χρήση λειτουργιών εισόδου/εξόδου μπορεί να επιλέξει να υποστηρίξει το MTA για να παρέχει τη βέλτιστη απόκριση στους πελάτες επιτρέποντας στις κλήσεις διεπαφών να γίνονται κατά τη διάρκεια της λανθάνουσας κατάστασης της εισόδου/εξόδου. Σε άλλη περίπτωση, ένα αντικείμενο που αλληλεπιδρά με το χρήστη σχεδόν πάντα, επιλέγει να υποστηρίξει το STA για να συγχρονίζουν τις εισερχόμενες κλήσεις του COM με τις ενέργειες της γραφικής διεπαφής χρήσης. Η υποστήριξη του μοντέλου STA είναι ευκολότερη επειδή το COM παρέχει το συγχρονισμό. Η υποστήριξη του μοντέλου MTA δυσκολότερη επειδή το αντικείμενο θα πρέπει να υλοποιεί το συγχρονισμό, αλλά η απόκριση στους πελάτες είναι καλύτερη επειδή ο συγχρονισμός χρησιμοποιείται για μικρότερα τμήματα κώδικα, αντί για όλη την κλήση της διεπαφής που προσφέρει το COM. Στην περίπτωση του ΟΔΥΣΣΕΑ, επιλέχτηκε η χρήση του μοντέλου μονού νήματος (single-threaded model). Ο κύριος λόγος που έγινε αυτό είναι ότι η χρήση οποιουδήποτε άλλου μοντέλου που χρησιμοποιεί διαμερίσματα δεν επιτρέπει την εκκίνηση των παραθύρων των διεπαφών χρήσεων των συστατικών, ως non-modal forms. Modal forms είναι τα παράθυρα ή πλαίσια διαλόγου, τα οποία όταν εμφανίζονται, παίρνουν τον έλεγχο της εφαρμογής και απαιτούν κάποια ενέργεια του χρήστη για να κλείσουν ή να δώσουν τον έλεγχο σε άλλα παράθυρα. Τα modal forms δεν αφήνουν κανένα άλλο παράθυρο ή φόρμα να γίνει ενεργή πριν τα ίδια κλείσουν. Η λειτουργικότητα του Βοηθήματος Διαπροσωπικής Επικοινωνίας απαιτεί να υπάρχουν στην οθόνη πάνω από ένα παράθυρα ταυτόχρονα και να υπάρχει η δυνατότητα καθένα από αυτά να μπορεί να γίνει ενεργό και να κάνει κάποια εργασία. Η φιλοσοφία των modal forms δεν θα επέτρεπε κάτι τέτοιο. Σελίδα 110 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

111 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Σχήμα 31: Πλαίσιο διαλόγου για τον ορισμό του Threading Model του DLL στη Microsoft Visual Basic 6.0 (μενού Project>>Properties) Η αναγκαιότητα χρησιμοποίησης no-modal forms λοιπόν, αναγκάζει το σχεδιασμό του συστήματος να γίνει με βάση το μοντέλο μονού νήματος ώστε να μπορεί το πρόγραμμα εκκίνησης του Βοηθήματος Διαπροσωπικής Επικοινωνίας να μπορεί να ανοίξει πολλά λειτουργικά παράθυρα ταυτόχρονα. Η κατάλληλη ρύθμιση γίνεται στη Visual Basic και στη Visual C++ σε ειδικά πλαίσια διαλόγου, όπως φαίνεται στα Σχήματα 20 και 21 αντίστοιχα. Σχήμα 32: Πλαίσιο διαλόγου για τον ορισμό του Threading Model ενός ATL Object στη Microsoft Visual C (wizard εισαγωγής νέου απλού ATL αντικειμένου σε μία ATL εφαρμογή. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 111 από 163

112 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Βιβλιοθήκη διεπαφής Interface.dll Η βιβλιοθήκη διεπαφών του ΟΔΥΣΣΕΑ είναι ένα αρχείο βιβλιοθήκης δυναμικής σύνδεσης (Dynamic Link Library DLL) που ονομάζεται Interface.dll. Πρόκειται για μια υλοποίηση σε Microsoft Visual Basic 6.0 μιας κλάσης γεγονότων, όπως αυτή περιγράφεται στις τυποποιήσεις του COM+. Συγκεκριμένα, για τη λειτουργία της υπηρεσίας γεγονότων (event service) απαιτείται μία διεπαφή που λέγεται κλάση γεγονότων (Event Class) που τυποποιεί την επικοινωνία μεταξύ των Εκδοτών και των Συνδρομητών. Όπως έχει περιγραφεί η κλάση γεγονότων είναι απλά μια δήλωση διεπαφών και μεθόδων, χωρίς καμία υλοποίηση. Στην ουσία περιέχει άδειες κλάσεις και ρουτίνες, στις οποίες καθορίζονται μόνο οι μεταβλητές (arguments) και τα ονόματα των κλάσεων και των ρουτινών. Η υλοποίηση στα πλαίσια της υπηρεσίας γεγονότων γίνεται από τον εκάστοτε Συνδρομητή που έχει δηλώσει ότι υλοποιεί την συγκεκριμένη διεπαφή. Από τη μεριά του Εκδότη, η σχέση του με την κλάση γεγονότων είναι απλά ότι καλεί κάποιες από τις μεθόδους της. Η βασική λειτουργικότητα της κλάσης γεγονότων σε συνδυασμό με την υπηρεσία γεγονότων είναι ότι όταν ένας Εκδότης καλεί μια μέθοδο σε ένα αντικείμενο της διεπαφής, τότε η υπηρεσία γεγονότων αναλαμβάνει να καλέσει την αντίστοιχη υλοποιημένη μέθοδο των συνδρομητών σε αυτήν τη διεπαφή, απομονώνοντας έτσι τους Εκδότες από τους Συνδρομητές. Η συγκεκριμένη διεπαφή που υλοποιήθηκε στα πλαίσια του ΟΔΥΣΣΕΑ, αποτελείται από τέσσερις κλάσεις, οι οποίες εξυπηρετούν την επικοινωνία με τέσσερις αντίστοιχους τύπους δεδομένων. Ο ΟΔΥΣΣΕΑΣ έχει σχεδιαστεί ώστε να υποστηρίζει τους εξής τύπους δεδομένων: 1. Χαρακτήρας: χρησιμοποιείται για την επικοινωνία συστατικών ανά χαρακτήρα. Για παράδειγμα, θα μπορούσε να στέλνει ένα συστατικό επεξεργαστή κειμένου τον κάθε χαρακτήρα που πληκτρολογεί ο χρήστης, σε ένα συστατικό πρόβλεψης λέξεων, μέσω της κλάσης Interface.Character. 2. Λέξη: χρησιμοποιείται για την επικοινωνία των συστατικών ανά λέξη. Για παράδειγμα, θα μπορούσε ένα συστατικό εικονικού πληκτρολογίου συμβόλων BLISS να στέλνει τη λέξη που αντιστοιχεί σε κάθε σύμβολο που επιλέγει ο χρήστης, σε ένα συστατικό σύνθεσης ομιλίας για να εκφωνηθεί, μέσω της κλάσης Interface.Word. 3. Πρόταση: χρησιμοποιείται για την επικοινωνία μεταξύ των συστατικών με ολόκληρες φράσεις. Για παράδειγμα, ένα συστατικό ελέγχου της σύνταξης και της γραμματικής, θα απαιτούσε από ένα συστατικό εικονικού πληκτρολογίου λέξεων, να του αποστέλλει ολόκληρη την πρόταση αφού πατήσει ο χρήστης ένα κουμπί που δηλώνει ότι τελείωσε με την σύνταξή της, μέσω της κλάσης Interface.Sentence. 4. Έγγραφο: χρησιμοποιείται για την επικοινωνία μεταξύ των συστατικών με ολοκληρωμένα έγγραφα. Για παράδειγμα, ένα συστατικό αποστολής ηλεκτρονικών μηνυμάτων μέσω , θα απαιτούσε από ένα συστατικό σύνταξης μηνυμάτων, να του αποστέλλει ολόκληρη το έγγραφο προς αποστολή αφού πατήσει ο χρήστης ένα κουμπί που δηλώνει ότι τελείωσε με την σύνταξή του, μέσω της κλάσης Interface.Document. Έτσι τα δεδομένα που ανταλλάσσονται μεταξύ των συστατικών του ΟΔΥΣΣΕΑ είναι πάντα αλφαριθμητικές σειρές (strings), σε τέσσερις διαφορετικές διεπαφές, δηλαδή Σελίδα 112 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

113 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» τέσσερις διαφορετικές κλάσεις ανάλογα με το μέγεθος και τη λειτουργικότητα των δεδομένων. Προγραμματιστικά δεν υπάρχει καμία διαφορά μεταξύ των τεσσάρων τύπων δεδομένων εκτός από το όνομα των αντίστοιχων κλάσεων. Ο διαχωρισμός είναι καθαρά σε λογικό και λειτουργικό επίπεδο. Αυτό σημαίνει ότι τίποτα δεν εμποδίζει κάποιον να στείλει μια ολόκληρη πρόταση στη διεπαφή του χαρακτήρα, αλλά δίνεται αυστηρή οδηγία να μη γίνεται κάτι τέτοιο. Επίσης, είναι φανερό ότι τέτοιος έλεγχος δεν θα ήταν εφικτός προγραμματιστικά, γιατί δεν θα επιτρεπόταν, για παράδειγμα στο άρθρο «ο» να αποσταλεί ως λέξη μια που αποτελεί έναν μόνο χαρακτήρα. Σε λογικό επίπεδο όμως μπορεί να αποτελεί και ολόκληρη λέξη. Παρακάτω παρατίθεται ο κώδικας και η δομή για τη διεπαφή του Interface.dll, μια σχηματική απεικόνιση της λειτουργικότητας της διεπαφής και οδηγίες για τη χρήση της. 'Μέθοδος για την επικοινωνία μέσω της διεπαφής Χαρακτήρα Public Sub Communicate(ByVal Data As String, ByVal PubID As String) End Sub 'Μέθοδος για την επικοινωνία μέσω της διεπαφής Λέξης Public Sub Communicate(ByVal Data As String, ByVal PubID As String) End Sub 'Μέθοδος για την επικοινωνία μέσω της διεπαφής Πρότασης Public Sub Communicate(ByVal Data As String, ByVal PubID As String) End Sub 'Μέθοδος για την επικοινωνία μέσω της διεπαφής Εγγράφου Public Sub Communicate(ByVal Data As String, ByVal PubID As String) End Sub 'Μέθοδος για την επικοινωνία μέσω της διεπαφής Χαρακτήρα Public Sub Communicate(ByVal Data As String, ByVal PubID As String) End Sub Κώδικας 1: Η κλάση γεγονότων Interface.dll Σχήμα 33: Η δομή της κλάσης γεγονότων Interface.dll Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 113 από 163

114 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» ΒΙΒΛΙΟΘΗΚΗ ΒΑΣΙΚΩΝ ΔΙΕΠΑΦΩΝ Interface Χαρακτήρας (Character) ΕΚΔΟΤΗΣ (Publisher) Λέξη (Word) ΣΥΝΔΡΟΜΗΤΗΣ (Subscriber) Πρόταση (Sentence) Έγγραφο (Document) Σχήμα 34: Η βασική διεπαφή του ΟΔΥΣΣΕΑ: Το Event Class Interface.dll. Η χρήση της βιβλιοθήκης αυτής είναι πολύ απλή για τους προγραμματιστές: αρκεί να την προμηθευτούν (διανέμεται ελεύθερα) και να την ενσωματώσουν στο περιβάλλον προγραμματισμού τους. Μπορούν να την προσθέσουν στα References στη Microsoft Visual Basic ή να την κάνουν include στη Microsoft Visual C++. Στη συνέχεια, ανάλογα με τη λειτουργικότητα του συστατικού τους μπορούν να χρησιμοποιήσουν τις κλάσεις και τις μεθόδους της. Είναι φανερό ότι αυτή η βιβλιοθήκη του ΟΔΥΣΣΕΑ χρησιμοποιείται για την επικοινωνία μεταξύ των Συστατικών. Έτσι αν ο προγραμματιστής κατασκευάζει ένα συστατικό που θα έχει το ρόλο του Εκδότη, αυτό που πρέπει να κάνει είναι να δημιουργήσει το κατάλληλο αντικείμενο από τη βιβλιοθήκη Interface, ανάλογα με τον τύπο δεδομένων που πρέπει να εκδοθούν. Στη συνέχει αρκεί να εκτελέσει τη μέθοδο Communicate με τα κατάλληλα ορίσματα data και PubID για να εκδώσει τα δεδομένα του στη διεπαφή της υπηρεσίας γεγονότων που επέλεξε. Ένα απλό παράδειγμα για το πως γίνεται αυτό στη Visual Basic δίνεται στον παρακάτω Κώδικα. ΟΝΟΜΑΤΟΛΟΓΙΚΗ ΟΔΗΓΙΑ: Ο κώδικας για τον Εκδότη θα πρέπει να βρίσκεται μέσα σε μια κλάση που λέγεται Publisher. Με αυτόν τον τρόπο θα είναι πιο εύκολη η αναγνώριση της δυνατότητας έκδοσης ενός συστατικού διαχειριστικά (στα Component Services). Αν απαιτείται από τη διάρθρωση του προγράμματος να υπάρχει ειδική μέθοδος για την Έκδοση δεδομένων αυτή θα πρέπει να λέγεται Publish. Σελίδα 114 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

115 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Δήλωση ενός αντικειμένου Dim objeventclass As Object Ανάθεση στο αντικείμενο ενός στιγμιοτύπου κλάσης της Interface, π.χ. του Character Set objeventclass = CreateObject("Interface.Character") Χρησιμοποίηση της μεθόδου Communicate του αντικειμένου, για την έκδοση των δεδομένων data objeventclass.communicate data, PubID Διαγραφή του αντικειμένου από τη μνήμη (αφού τελειώσει την αποστολή ως Εκδότης) Set objeventclass = Nothing Κώδικας 2: Υλοποίηση για έναν Εκδότη στη Visual Basic Αντίστοιχα, για την κατασκευή ενός Συνδρομητή, η διαδικασία είναι εξίσου απλή: Μετά την ενσωμάτωση της βιβλιοθήκης στο περιβάλλον προγραμματισμού, αρκεί η δήλωση ότι πρόκειται να υλοποιηθεί η κατάλληλη διεπαφή και η υλοποίησή της. Στη συνέχεια μέσω της υλοποίησης της μεθόδου Communicate, γίνονται διαθέσιμα στο πρόγραμμα τα δεδομένα που έχουν εκδοθεί στην υπηρεσία γεγονότων και μπορεί να κατασκευαστεί η επιθυμητή λειτουργικότητα και η διαδικασία επεξεργασίας των δεδομένων. Παράδειγμα τέτοιας υλοποίησης στη Visual Basic, δίνεται στον παρακάτω Κώδικα. ΟΝΟΜΑΤΟΛΟΓΙΚΗ ΟΔΗΓΙΑ: Ο κώδικας για τον Συνδρομητή θα πρέπει να βρίσκεται μέσα σε μια κλάση που λέγεται Subscriber. Με αυτόν τον τρόπο θα είναι πιο εύκολη η αναγνώριση της δυνατότητας συνδρομών ενός συστατικού διαχειριστικά (στα Component Services). Αν απαιτείται από τη διάρθρωση του προγράμματος να υπάρχει ειδική μέθοδος για την υλοποίηση της συνδρομής (ανάκτηση δεδομένων) αυτή θα πρέπει να λέγεται Subscribe. Δήλωση ότι πρόκειται να υλοποιηθεί η διεπαφή Interface.Word Implements Interface.Word Χρησιμοποίηση της μεθόδου Communicate της υλοποιούμενης κλάσης για τη επεξεργασία των δεδομένων Private Sub Word_Communicate(ByVal Data As String, ByVal PubID As String) Εδώ μπαίνει ο κώδικας για την επεξεργασία των δεδομένων End Sub Κώδικας 3: Υλοποίηση για έναν Συνδρομητή στη Visual Basic. Βέβαια, μπορούν να χρησιμοποιηθούν στο ίδιο συστατικό, είτε αυτό είναι Εκδότης είτε Συνδρομητής, πολλαπλές διεπαφές. Δηλαδή μπορεί ένα συστατικό να Εκδίδει και χαρακτήρες και λέξεις και προτάσεις και έγγραφα, ή οποιονδήποτε συνδυασμό από όλα αυτά. Αντίστοιχα ένας Συνδρομητής μπορεί να λαμβάνει οποιονδήποτε συνδυασμό ή και όλους τους τύπους δεδομένων, να «ακούει» δηλαδή, όλα τα γεγονότα. Τέλος υποστηρίζεται και η δυνατότητα να κατασκευάζονται «Ενδιάμεσα συστατικά» τα οποία είναι ταυτόχρονα και Εκδότες και Συνδρομητές. Σε αυτήν την περίπτωση, μπορούν να χρησιμοποιούνται και πολλαπλές διεπαφές για την έκδοση και να υλοποιούνται πολλαπλές Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 115 από 163

116 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» διεπαφές για την επεξεργασία των δεδομένων. Είναι επίσης δυνατό, ένα συστατικό να λαμβάνει γεγονότα σαν Συνδρομητής σε μία διεπαφή, να τα επεξεργάζεται και να τα Εκδίδει σε μία διαφορετική διεπαφή Διεπαφής Χρήσης θέση και μέγεθος παραθύρων Συστατικά τρίτων κατασκευαστών που διαθέτουν διεπαφή χρήσης θα πρέπει να «θυμούνται» τη θέση και το μέγεθος του παραθύρου ή πλαισίου διαλόγου της διεπαφής χρήσης μεταξύ διαδοχικών ανοιγμάτων. Αυτό σημαίνει ότι όταν ο τελικός χρήστης του Βοηθήματος Επικοινωνίας, μόνος του ή με τη βοήθεια του θεραπευτή του, ρυθμίζει το μέγεθος και τη θέση του παραθύρου της διεπαφής χρήσης του (ή των πολλαπλών διεπαφών χρήσης), θα πρέπει την επόμενη φορά που θα χρησιμοποιήσει το Βοήθημα Επικοινωνίας του να βρει τη διεπαφή χρήσης με τις ίδιες ρυθμίσεις που είχε κάνει. Πρέπει λοιπόν οι κατασκευαστές να σχεδιάζουν έτσι τη διεπαφή χρήσης των συστατικών τους ώστε: Να υπάρχει η δυνατότητα προσαρμογής του μεγέθους (πλάτος και ύψος του παραθύρου) της διεπαφής χρήσης σύμφωνα με τις προτιμήσεις του χρήστη. Να υπάρχει η δυνατότητα τοποθέτησης μετακίνησης του παραθύρου της διεπαφής χρήσης στο σημείο της οθόνης που θέλει ο χρήστης. Να παραμένει η διεπαφή χρήσης στο μέγεθος και τη θέση που την προτιμά ο χρήστης μεταξύ διαδοχικών ανοιγμάτων του παραθύρου και, αν γίνονται νέες ρυθμίσεις, να τις διατηρεί. Αν είναι δυνατό, θα πρέπει και όλα τα στοιχεία που περιέχει το παράθυρο της διεπαφής χρήσης (κουμπιά, εικόνες, πλαίσια διαλόγου κλπ), να προσαρμόζουν το μέγεθος και τη θέση τους μέσα στο παράθυρο, ώστε να είναι πάντα όλα ορατά από το χρήστη, ακόμα και σε διαφορετικές ρυθμίσεις μεγέθους του γενικού παραθύρου. Για να γίνουν όλα αυτά, οι κατασκευαστές μπορεί να επιλέξουν διάφορες τεχνικές. Μπορούν να κρατούν αρχεία ρυθμίσεων (ini files) που περιέχουν πληροφορίες για την αρχικοποίηση κάθε φορά της διεπαφής χρήσης, ή μπορούν να χρησιμοποιούν και το registry του συστήματος για να αποθηκεύουν αυτές τις πληροφορίες. Γενικά ο τρόπος υλοποίησης αυτών των απαιτήσεων είναι ελεύθερος και εδώ δίνονται απλά προτάσεις. Συνήθως είναι αρκετές τέσσερις μεταβλητές για να κρατήσουν τις πληροφορίες που χρειάζονται. Μία κρατά το πλάτος του παραθύρου, μια άλλη το ύψος, μια Τρίτη την κάθετη συνιστώσα της απόστασης της επάνω αριστερής γωνίας του παραθύρου από την πάνω αριστερή γωνία της οθόνης και η τελευταία κρατά την αντίστοιχη οριζόντια συνιστώσα. Πιο πολύπλοκη είναι η ικανοποίηση της προδιαγραφής που αφορά τα στοιχεία που περιέχει κάθε παράθυρο. Αν και τα περιεχόμενα του παραθύρου πρέπει να προσαρμόζονται στο μέγεθος του παραθύρου, χρειάζεται λίγος περισσότερος κώδικας για να υπολογίζεται κάθε φορά το μέγεθος και η θέσης που πρέπει να έχουν για να χωρούν μέσα σε αυτό. Και αυτή η υλοποίηση αφήνετε στην κρίση των προγραμματιστών Κώδικας Προγράμματος Εκκίνησης Βοηθημάτων Διαπροσωπικής Επικοινωνίας Ο κώδικας του Προγράμματος Εκκίνησης Βοηθημάτων Διαπροσωπικής Επικοινωνίας είναι απαραίτητο να είναι γνωστός στους Προγραμματιστές, για να ξέρουν τη διαδικασία Σελίδα 116 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

117 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» ενεργοποίησης η οποία θα εφαρμοστεί και στα δικά τους συστατικά (ειδικά στην περίπτωση που αυτά έχουν διεπαφή χρήσης. Option Explicit 'Τί γίνεται όταν πατάω το κουμπί "Έξοδος"; Private Sub btnexit_click() 'Ξεφορτώνεται η φόρμα Unload Me 'Κλείνει ο Communicator End Sub 'Τί γίνεται όταν φορτώνεται η φόρμα; Private Sub Form_Load() 'Ορίζω αντικείμενο που θα αντιπροσωπεύσει τον Component Catalog Dim ocat As COMAdminCatalog 'Ορίζω αντικείμενo oapp που θα πάρει τη λίστα των COM+ εφαρμογών Dim oapps As COMAdminCatalogCollection 'Ορίζω αντικείμενο oaeneas που θα πάρει την εφαρμογή AENEAS Dim oaeneas As COMAdminCatalogObject 'ορίζω αντικείμενο ocoms που θα πάρει τη λίστα των Components του Communicator Dim ocoms As COMAdminCatalogCollection 'ορίζω αντικείμενο ocom που αντιπροσωπεύει ένα component Dim ocom As COMAdminCatalogObject 'ορίζω πίνακα από Objects που θα σηκώσει τα αντικείμενα του component Dim component As New Collection 'Ανοίγω το COM+ Catalog ως ένα αντικείμενο ocat Set ocat = New COMAdminCatalog 'Διαβάζω τη λίστα των COM+ εφαρμογών Set oapps = ocat.getcollection("applications") 'Γεμίζω ένα πίνακα (αντικείμενο aapp)με τις COM+ εφαρμογές που βρέθηκαν. oapps.populate 'Ψάχνω στον πίνακα για την εφαρμογή AENEAS και αν τη βρώ την αναθέτω στο αντικείμενο oaeneas For Each oaeneas In oapps Next If oaeneas.name = "AENEAS" Then Exit For Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 117 από 163

118 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» 'Αν δεν την βρω βγάζω λάθος και σταματάω τον Communicator If oaeneas Is Nothing Then Set oaeneas = oapps.add oaeneas.value("name") = "AENEAS" oaeneas.value("activation") = 0 oaeneas.value("createdby") = "ODYSSEAS Framework" oaeneas.value("description") = "Alternative and Augmentative Communication Application based on ODYSSEAS framework" oaeneas.value("runforever") = True oapps.savechanges ocat.installeventclass "AENEAS", "Interface.dll", "", "" oapps.savechanges MsgBox "H εφαρμογή ΑΙΝΕΙΑΣ μόλις εγκαταστάθηκε." + vbcrlf + vbcrlf + "Τώρα μπορείτε να προσθέσετε τα components που θα συνθέσουν" + vbcrlf + "το Βοήθημα Διαπροσωπικής Επικοινωνίας" Unload Me End End If 'Διαβάζω τη λίστα των components της εφαρμογής AENEAS Set ocoms = oapps.getcollection("components", oaeneas.key) 'Γεμίζω ένα πίνακα (αντικείμενο ocom) με τα components που βρέθηκαν ocoms.populate 'Σηκώνω τα Objects που με ενδιαφέρουν από κάθε component (αυτά που τελειώνουν σε ".Activate" For Each ocom In ocoms Next If Right(oCom.Name, 9) = ".Activate" Then component.add Item:=CreateObject(oCom.Name) End If End Sub Κώδικας 4: Το Πρόγραμμα Εκκίνησης Βοηθημάτων Επικοινωνίας και Ενεργοποίησης Συστατικών Σελίδα 118 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

119 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» 3. Ο ΟΔΥΣΣΕΑΣ για τους Πωλητές Η δεύτερη ομάδα χρηστών του Πλαισίου Σχεδιασμού και Ανάπτυξης Βοηθημάτων Διαπροσωπικής Επικοινωνίας ΟΔΥΣΣΕΑΣ είναι οι πωλητές των συστημάτων αυτών. Αυτή η ομάδα χρηστών είναι οι άνθρωποι που σε συνεργασία με τα Άτομα με Αναπηρία και τους θεραπευτές τους, θα αναγνωρίζουν τις ανάγκες των χρηστών και θα αποφασίζουν ποια σύνθεση θα πρέπει να έχει το Βοήθημα Διαπροσωπικής Επικοινωνίας. Βασική προϋπόθεση για την επίτευξη της αποστολής των πωλητών Βοηθημάτων Διαπροσωπικής Επικοινωνίας, είναι η καλή γνώση των διαθέσιμων συστατικών, όσον αφορά τη λειτουργικότητα και τις προδιαγραφές τους. Αυτοί οι χρήστες καλούνται να συνθέσουν ένα ολοκληρωμένο σύστημα από ανεξάρτητα συστατικά τα οποία στη συνέχεια θα συνεργάζονται μεταξύ τους για να προσφέρουν τη λειτουργικότητα που απαιτείται και για να ικανοποιήσουν τις ανάγκες των τελικών χρηστών τους, δηλαδή των ΑΜΑ. Είναι λοιπόν φανερό ότι για να ολοκληρωθεί με επιτυχία αυτή σύνθεση, θα πρέπει κάποιος να γνωρίζει πολύ καλά τα συστατικά. Όσο πιο ολοκληρωμένη είναι η γνώση του πωλητή για τα συστατικά που μπορεί να έχει στη διάθεσή του, αλλά και για τα ιδιαίτερα χαρακτηριστικά του καθενός από αυτά τόσο πιο επιτυχημένη θα είναι η λειτουργία του βοηθήματος Προετοιμασία του συστήματος Ο πωλητής ξεκινώντας τη διαδικασία σύνθεσης ενός Βοηθήματος Διαπροσωπικής Επικοινωνίας σύμφωνα με τις ανάγκες του χρήστη θα πρέπει να έχει στη διάθεσή του ένα υπολογιστικό σύστημα που θα είναι έτοιμο να δεχτεί τα συστατικά λογισμικού, αλλά και όλες τις ειδικές συσκευές εισόδου και εξόδου που ίσως χρειάζονται. Η τυπική πλατφόρμα στην οποία θα τρέχει το Βοήθημα είναι ένας υπολογιστής τύπου PC με λειτουργικό Microsoft Windows 2000 Professional. Οι ελάχιστες απαιτήσεις που δίνει η Microsoft για συστήματα που τρέχουν αυτό το λειτουργικό σύστημα είναι οι εξής: Επεξεργαστής συμβατό με Pentium ταχύτητας 133 MHz. Μνήμη RAM 64 ΜΒ. Σκληρός δίσκος χωρητικότητας 2 GB με ελεύθερο χώρο 650 MB κατ ελάχιστο. Η προτεινόμενη από τον ΟΔΥΣΣΕΑ ελάχιστη σύνθεση είναι η εξής: Επεξεργαστής Pentium Celeron 500 MHz. Μνήμη RAM 128 MB. Σκληρός Δίσκος 8 GB. Ανάλογα με την περίπτωση του τελικού χρήστη το υπολογιστικό σύστημα θα μπορεί να είναι φορητό ή γραφείου. Επίσης, ανάλογα με τις απαιτήσεις του χρήστη διαμορφώνεται και το μέγεθος και είδος της οθόνης του συστήματος (π.χ. 15 ιντσών, 17 ιντσών, υγρών κρυστάλλων κλπ.). Τέλος, συνήθως απαιτείται κάρτα ήχου, ισχυρή κάρτα γραφικών (με τουλάχιστον 8 MB μνήμη στα συστήματα γραφείου και 2 ΜΒ στα φορητά συστήματα) και γενικά δυνατότητες πολυμέσων (συσκευές CD-ROM, ηχεία, μικρόφωνα κλπ.). Βέβαια, Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 119 από 163

120 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» εξαρτάται από την κάθε περίπτωση και απαιτήσεις του χρήστη ποιες ακριβώς θα είναι οι συσκευές εισόδου και εξόδου του συστήματος. Αφού επιλεγεί το κατάλληλο υπολογιστικό σύστημα, θα πρέπει να συγκεντρωθούν τα κατάλληλα συστατικά που θα απαρτίσουν το ολοκληρωμένο Βοήθημα και τα αντίστοιχα DLLs να αντιγραφούν στο σκληρό δίσκο του συστήματος. Συγκεκριμένα, όλα τα DLLs που απαιτούνται πρέπει να αποθηκευτούν σε δικό του φάκελο το κάθε ένα κάτω από τη διαδρομή Program Files/Aeneas/Components/. Το όνομα του φακέλου του κάθε DLL θα πρέπει να είτε να έχει το όνομα του DLL, είτε να είναι ενδεικτικό για το είδος του συστατικού που περιέχει Εγκατάσταση του Εκτελέσιμου Προγράμματος Εκκίνησης του Βοηθήματος Διαπροσωπικής Επικοινωνίας Κατά την υλοποίηση του πλαισίου ΟΔΥΣΣΕΑΣ, αναπτύχθηκε ένα εκτελέσιμο (exe) πρόγραμμα με όνομα Communicator.exe. Αποστολή αυτού του προγράμματος είναι να εκκινεί όλο το σύστημα που υποστηρίζει τη λειτουργία του Βοηθήματος Διαπροσωπικής Επικοινωνίας καθώς και τα ίδια τα συστατικά που το αποτελούν. Το πρόγραμμα αυτό είναι διαθέσιμο στους πωλητές των συστημάτων που είναι βασισμένα στο πλαίσιο ΟΔΥΣΣΕΑΣ με τη μορφή τριών αρχείων που αναλαμβάνουν την εγκατάσταση του προγράμματος στον ηλεκτρονικό υπολογιστή του τελικού χρήστη. Τα τρία αυτά αρχεία προέκυψαν μετά από τη χρήση του εργαλείου δημιουργίας προγραμμάτων εγκατάστασης Deployment and Package Wizard του Microsoft Visual Studio και είναι τα εξής: Communicator.cab: είναι το αρχείο που περιέχει όλες τις απαραίτητες βιβλιοθήκες που χρησιμοποιούνται από το εκτελέσιμο πρόγραμμα εκκίνησης του Βοηθήματος Επικοινωνίας. Setup.exe: είναι το εκτελέσιμο αρχείο που ξεκινά την εγκατάσταση του προγράμματος Communicator στον ηλεκτρονικό υπολογιστή του τελικού χρήστη. Setup.lst: είναι το αρχείο που περιέχει βοηθητικές πληροφορίες για την εγκατάσταση του Communicator και χρησιμοποιείται από το setup.exe. Όλα τα απαραίτητα αρχεία για την εγκατάσταση του Communicator έρχονται σε δισκέτες και σε CD-ROM. Επίσης, τα αρχεία αυτά μπορούν να είναι διαθέσιμα και στο Διαδίκτυο, ώστε οι πωλητές να μπορούν να τα κατεβάσουν από εκεί, μια και το μέγεθός τους είναι αρκετά μικρό (λιγότερο από 2 ΜΒ όλα μαζί). Η διαδικασία εγκατάστασης του εκτελέσιμου προγράμματος είναι τυπική και παρόμοια με την εγκατάσταση οποιουδήποτε άλλου εμπορικού προγράμματος. Ο πωλητής θα πρέπει να εκτελέσει το αρχείο setup.exe και να ακολουθήσει τα τυπικά βήματα της εγκατάστασης. Το πρόγραμμα της εγκατάστασης αναλαμβάνει να ενημερώσει το σύστημα του τελικού χρήστη με τις απαραίτητες βιβλιοθήκες για τη λειτουργία του Βοηθήματος Επικοινωνίας. Επίσης, δημιουργεί μέσα στον φάκελο των προγραμμάτων του χρήστη (Program Files) έναν φάκελο με όνομα Communicator. Τέλος, δημιουργεί στο μενού έναρξης προγραμμάτων (Start>>Programs) έναν φάκελο με το όνομα Aeneas και μέσα σε αυτόν τοποθετεί τη συντόμευση για το εκτελέσιμο Communicator.exe. Έτσι, ο τελικός χρήστης μπορεί να εκκινήσει το Βοήθημα Διαπροσωπικής Επικοινωνίας με τον ίδιο τρόπο που εκκινεί οποιαδήποτε άλλη εφαρμογή, δηλαδή μέσω του μενού Έναρξης. Σελίδα 120 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

121 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Προτείνεται, ανάλογα με τις δυνατότητες του τελικού χρήστη και αν κάτι τέτοιο απαιτείται, μετά την εγκατάσταση του προγράμματος, ο πωλητής να δημιουργεί συντόμευση για την εκτέλεση του Communicator πάνω στην επιφάνεια εργασίας του χρήστη ή ακόμη και να εισάγει μια συντόμευση για το εκτελέσιμο μέσα στο μενού εκκίνησης (start up menu) των Windows, ώστε να εκτελείται ο communicator χωρίς να χρειάζεται η επέμβαση του χρήστη, αμέσως μόλις ανοίγει ο υπολογιστής Διαδικασία Εγκατάστασης των Συστατικών Βοηθήματος Διαπροσωπικής Επικοινωνίας Η διαδικασία εγκατάστασης και ρύθμισης του Βοηθήματος Διαπροσωπικής Επικοινωνίας γίνεται μέσω της διεπαφής χρήσης των Component Services των Windows Το παράθυρο των Component Services ανοίγει από τον Πίνακα Ελέγχου (Control Panel) στην έκδοση Professional του λειτουργικού, και από το Start>>Programs>>Administrative Tools>>Component Services των Εκδόσεων Server και Advanced Server. Πριν από την εγκατάσταση του βοηθήματος, το παράθυρο των Component Services είναι όπως φαίνεται στο παρακάτω Σχήμα. Σχήμα 35: Το παράθυρο των Component Services πριν από την εγκατάσταση της εφαρμογής του βοηθήματος Διαπροσωπικής Επικοινωνίας. Με δεξί κλικ στο φάκελο COM+ Applications, γίνεται από το αναδυόμενο μενού η επιλογή New>>Application. Από το πλαίσιο διαλόγου που εμφανίζεται πρέπει να επιλεγεί Create an Empty Application, όπως φαίνεται στο παρακάτω Σχήμα. Αυτή η επιλογή θα επιτρέψει τη δημιουργία μιας νέας εφαρμογής. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 121 από 163

122 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Σχήμα 36: Επιλογή δημιουργίας νέας εφαρμογής. Από το επόμενο πλαίσιο διαλόγου που εμφανίζεται, πρέπει να δηλωθεί ως όνομα της εφαρμογής το «AENEAS», και ως τύπος εφαρμογής η Εφαρμογή Βιβλιοθήκης (Library Application). Και οι δύο αυτές ρυθμίσεις είναι κρίσιμες για τη σωστή λειτουργία του βοηθήματος. Σχήμα 37: Επιλογή ονόματος και τύπου της νέας εφαρμογής. Σελίδα 122 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

123 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Μετά το τέλος της διαδικασίας δήλωσης μιας νέας εφαρμογής το παράθυρο των Component Services φαίνεται ενημερωμένο με την εφαρμογή AENEAS, όπως στο παρακάτω Σχήμα. Σχήμα 38: Η νέα εφαρμογή «AENEAS» στο παράθυρο Component Services Κάνοντας δεξί κλικ στο φάκελο των συστατικών της εφαρμογής AENEAS, μπορεί να επιλεχθεί από το αναδυόμενο μενού η εισαγωγή μιας νέας κλάσης γεγονότων (Event Class). Σχήμα 39: Πλαίσιο διαλόγου για την εγκατάσταση νέας κλάσης γεγονότων (Event Class) ή νέων συστατικών. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 123 από 163

124 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Η βασική κλάση γεγονότων του ΟΔΥΣΣΕΑ βρίσκεται σε ένα αρχείο DLL με το όνομα Interface.dll. Αυτό το αρχείο το παρέχει ο ΟΔΥΣΣΕΑΣ και πρέπει να βρίσκεται στον κατάλογο Interface κάτω από τη διαδρομή Program Files/Aeneas/Event Classes. Σχήμα 40: Επιλογή της βασικής κλάσης γεγονότων του ΟΔΥΣΣΕΑ. Αφού επιλεγεί η βασική κλάση γεγονότων εμφανίζεται ένα πλαίσιο διαλόγου που δείχνει όλες τις διαθέσιμες διεπαφές της και δίνει τη δυνατότητα πρόσθεση πρόσθετων κλάσεων γεγονότων σε περίπτωση που χρειάζεται. Σχήμα 41: Εμφάνιση των διαθέσιμων διεπαφών και δυνατότητα πρόσθεσης άλλων κλάσεων γεγονότων. Σελίδα 124 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

125 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Σχήμα 42:Το παράθυρο των Component Services μετά την εγκατάσταση της βασικής κλάσης γεγονότων. Στη συνέχεια, εγκαθίστανται τα συστατικά του Βοηθήματος, επιλέγοντας ξανά την εγκατάσταση νέων συστατικών (με δεξί κλικ στο φάκελο Components), αλλά αυτή τη φορά πρέπει να επιλεγεί το πλήκτρο Install New Components (βλέπε Σχήμα 30). Για σκοπούς επίδειξης, θα εγκαταστήσουμε εδώ τα δύο δοκιμαστικά συστατικά που διατίθενται ελεύθερα από τον ΟΔΥΣΣΕΑ. Πρόκειται για δύο πολύ απλά και υποτυπώδη συστατικά που έχουν κατασκευαστεί υπακούοντας στις προδιαγραφές του ΟΔΥΣΣΕΑ και υπάρχουν διαθέσιμα για τη διενέργεια δοκιμών από τους κατασκευαστές. Το ένα από αυτά είναι ένα συστατικό εισόδου και παρουσιάζεται στο χρήστη ως ένα απλό παράθυρο διαλόγου με ένα πλαίσιο κειμένου στο οποίο μπορεί ο χρήστης να πληκτρολογήσει κείμενο. Το συστατικό αυτό αν εγκατασταθεί κανονικά στα Component Services, αυτόματα θα «εκδίδει» το κείμενο που πληκτρολογεί ο χρήστης και μάλιστα σε τρία διαφορετικά interfaces της βασικής κλάσης γεγονότων: στης διεπαφή character ανά χαρακτήρα, στη διεπαφή word ανά λέξη και στη διεπαφή sentence ανά φράση. Όπως προτείνεται από τον ΟΔΥΣΣΕΑ, αυτό το συστατικό έρχεται εφοδιασμένο με δύο κλάσεις: την κλάση Activate που χρησιμεύει για την ενεργοποίησης της διεπαφής χρήσης του, και την κλάση Publisher, όπου μέσω της μεθόδου Publish γίνεται η δημοσίευση των δεδομένων του χρήστη. Το δεύτερο είναι ένα συστατικό εξόδου, παρόμοιο με το πρώτο, με τη διαφορά ότι στο πλαίσιο κειμένου του φαίνονται τα δεδομένα τα οποία εκδίδονται από το συστατικό εισόδου (στη διεπαφή word) και ο χρήστης δεν μπορεί να πληκτρολογήσει σε αυτό. Το συστατικό αυτό έχει την κατάλληλη υποδομή και προγραμματισμό ώστε να μπορεί να «ακούει» αν εκδίδονται δεδομένα από οποιονδήποτε στη διεπαφή word και να τα εμφανίζει. Βέβαια, για να γίνει αυτό πρέπει να δηλωθεί ως Συνδρομητής σε κάποιους Εκδότες όπως θα περιγραφεί παρακάτω. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 125 από 163

126 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Στα επόμενα Σχήματα φαίνονται ένα-ένα τα βήματα για την επιλογή εγκατάστασης των δύο αυτών συστατικών. Σχήμα 43: Επιλογή εγκατάστασης του δοκιμαστικού συστατικού εισόδου. Αρχικά επιλέγεται, όπως ειπώθηκε η εγκατάσταση νέου συστατικού και ο πωλητής ψάχνει στο δίσκο του υπολογιστή του χρήστη να βρει το συστατικό εισόδου και το εγκαθιστά κανονικά στα Component Services. Σχήμα 44: Επιλογή εγκατάστασης πρόσθετων συστατικών. Σελίδα 126 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

127 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Μετά την επιλογή του ενός αρχείου (του συστατικού εισόδου), ο πωλητής πατά το πλήκτρο Add στο πλαίσιο διαλόγου και ψάχνει στο δίσκο το αρχείο DLL και του συστατικού εξόδου. Σχήμα 45: Επιλογή εγκατάστασης του δοκιμαστικού συστατικού εξόδου. Τελικά στο πλαίσιο διαλόγου μπορεί να δει ο πωλητής όλα τα συστατικά που έχει επιλέξει για εγκατάσταση, καθώς και τις κλάσεις τους. Φαίνονται συγκεκριμένα εδώ οι δύο κλάσεις Activate για τη διεπαφή χρήσης των συστατικών και οι κλάσεις Publisher για την έκδοση και Subscriber για τη συνδρομή. Σχήμα 46: Εμφάνιση των συστατικών και των κλάσεών τους. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 127 από 163

128 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Μετά την εγκατάσταση όλων των συστατικών τα παράθυρο των Component Services φαίνεται όπως στο παρακάτω Σχήμα. Μπορεί ο πωλητής να δει όλα τα συστατικά που έχει εγκαταστήσει καθώς και τις διάφορες ξεχωριστές κλάσεις που το καθένα περιέχει. Ανοίγοντας το φάκελο κάθε συστατικού ξεχωριστά, φαίνονται και οι διεπαφές της κάθε κλάσης. Έτσι έχει κανείς μια συνολική εικόνα για τη δομή της εφαρμογής, των κλάσεων και των διεπαφών που την αποτελούν, σύμφωνα με τις αρχές του προγραμματισμού που βασίζεται σε συστατικά (component based). Ακόμα πιο βαθιά στη δομή κάθε συστατικού μπορεί κανείς να δει ακόμη και τις μεθόδους που υποστηρίζονται από κάθε ξεχωριστή διεπαφή (Interface). Όλη αυτή η πληροφορία είναι πιο χρήσιμη, διευκρινιστική και εύκολη στη διαχείριση, όταν ακολουθούνται κάποιοι κανόνες ονοματολογίας που αφορούν κυρίως τους προγραμματιστές που κατασκευάζουν τα επιμέρους συστατικά. Αυτούς τους κανόνες ονοματολογίας τους καθόρισε ο ΟΔΥΣΣΕΑΣ στο τμήμα του που αφορά τους προγραμματιστές και αν ακολουθούνται πιστά, μπορεί ο πωλητής να καταλάβει τη δομή και λειτουργία της εφαρμογής βλέποντας μόνο την ιεραρχία των τμημάτων της στα Component Services. Φυσικά αυτό δεν είναι αρκετό και γι' αυτό το λόγο τα συστατικά πρέπει να έρχονται με τη δική τους περιγραφή, συγκεκριμένες προδιαγραφές και τεκμηρίωση, ώστε ο πωλητής να γνωρίζει τη λειτουργικότητα τη δομή και τον τρόπο λειτουργίας τους από την αρχή και να επιλέγει τα σωστά συστατικά ανά περίπτωση. Σχήμα 47: Το παράθυρο των Component Services μετά την εγκατάσταση και των συστατικών. Το τελευταίο βήμα που πρέπει να κάνει ένα πωλητής Βοηθήματος Διαπροσωπικής Επικοινωνίας με προσοχή είναι η ρύθμιση των Συνδρομών (Subscriptions). Είναι το λεπτότερο σημείο μιας τυπικής εγκατάστασης και πρέπει να γίνει σωστά για να είναι ομαλή η λειτουργία του Βοηθήματος. Πρώτα πρέπει να εντοπιστούν τα συστατικά που πρόκειται να λαμβάνουν είσοδο από κάποια συστατικά εισόδου. Αυτή είναι μια πληροφορία που σίγουρα δίνεται στην Σελίδα 128 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

129 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» περιγραφή και τις προδιαγραφές του κάθε συστατικού. Εξ' άλλου αν έχουν ακολουθηθεί οι οδηγίες του ΟΔΥΣΣΕΑ προς τους προγραμματιστές κατά τη διάρκεια της κατασκευής των συστατικών, τότε μία από τις κλάσεις αυτών των συστατικών που μας ενδιαφέρουν εδώ θα λέγεται Subscriber. Όσα συστατικά λοιπόν περιέχουν κλάση με το όνομα αυτό, σημαίνει ότι μπορούν να γίνουν Συνδρομητές σε κάποια δεδομένα που εκδίδουν άλλα συστατικά με μια κατάλληλη δήλωση συνδρομής σε αυτήν την κλάση. Υπάρχει βέβαια και η περίπτωση κάποια συστατικά που έχουν δυνατότητες συνδρομής να μην χρειάζεται να τις χρησιμοποιήσουν σε κάποιες συνθέσεις Βοηθημάτων. Αυτό καθορίζεται από την αρχική διαδικασία σύνθεσης του Βοηθήματος, λαμβάνοντας υπ' όψη τις δυνατότητες και τις προδιαγραφές των επιμέρους συστατικών και επιλέγοντας τις λειτουργικότητες που θα χρησιμοποιηθούν. Επίσης, απαιτείται η καλή γνώση των χαρακτηριστικών του συστατικού σε περίπτωση που για οποιονδήποτε λόγο δεν έχουν ακολουθηθεί από τους κατασκευαστές οι οδηγίες ονοματολογίας και η κλάση συνδρομής δεν έχει ονομαστεί Subscriber. Και σε αυτήν την περίπτωση ο πωλητής θα πρέπει να έχει τη γνώση από την τεκμηρίωση του συστατικού για το ποια κλάση απαιτεί ρυθμίσεις συνδρομής. Στην τυπική περίπτωση με τα δυο πρότυπα συστατικά που χρησιμοποιούνται εδώ, ανοίγοντας το φάκελο της μοναδικής κλάσης Subscriber που υπάρχει και ανήκει στο συστατικό εξόδου, εμφανίζεται ο φάκελος των συνδρομών (Subscriptions). Σημειώνεται ότι όλες οι κλάσεις όλων των συστατικών έχουν φάκελο συνδρομών αλλά μόνο στις κατάλληλες κλάσεις πρέπει να δηλωθούν συνδρομές. Προς το παρόν, αυτός ο φάκελος είναι κενός και κάνοντας δεξί κλικ επάνω του μπορούμε να προσθέσουμε μια συνδρομή στη συγκεκριμένη κλάση του συστατικού επιλέγοντας New>>Subscription από το αναδυόμενο μενού. Σχήμα 48: Ο φάκελος των συνδρομών (Subscriptions) του συστατικού Συνδρομητή. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 129 από 163

130 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Το πλαίσιο διαλόγου που εμφανίζεται δίνει πληροφορίες για τα περιεχόμενα της κλάσης συνδρομής και συγκεκριμένα για τις διεπαφές και τις μεθόδους τους. Για το συγκεκριμένο συστατικό φαίνεται ότι η κλάση Subscriber περιέχει μια διεπαφή με το όνομα Word και αυτή με τη σειρά της έχει μια μέθοδο με το όνομα Communicate. Και η διεπαφή αλλά και η μέθοδος ακολουθούν τους κανόνες ονοματολογίας του ΟΔΥΣΣΕΑ και αυτά τα ονόματα είναι αναμενόμενο να εμφανίζονται. Σε άλλες περιπτώσεις, θα μπορούσαν να εμφανίζονται και πρόσθετες διεπαφές με τις δικές τους Communicate μεθόδους. Αυτό σημαίνει ότι κάποια συστατικά μπορούν να έχουν τη δυνατότητα να έχουν συνδρομές σε περισσότερους από έναν τύπους δεδομένων που προβλέπονται από το πλαίσιο ΟΔΥΣΣΕΑΣ. Σε τέτοιες περιπτώσεις πρέπει να ρυθμίζεται η κάθε συνδρομή ξεχωριστά. Σε αυτό το βήμα επιλέγεται μια διεπαφή και δηλώνεται μία συνδρομή. Για κάθε πρόσθετη πρέπει να επαναλαμβάνεται η διαδικασία πρόσθεσης συνδρομής. Στη δική μας απλή περίπτωση, η μόνη επιλογή είναι η διεπαφή Word. Σχήμα 49: Επιλογή της διεπαφής για την οποία θα δηλωθεί η συνδρομή. Στο επόμενο βήμα το σύστημα θα πρέπει να εντοπίσει την κλάση γεγονότων (Event Class) που υλοποιεί τη διεπαφή που μόλις επιλέχτηκε. Στην ουσία η κλάση γεγονότων είναι απλά ένας μεσάζοντας και η πραγματική υλοποίηση γίνεται από κάποιον "Εκδότη" όπως έχει περιγραφεί. Αυτό όμως σε αυτό το σημείο και ειδικά στην δική μας περίπτωση που δεν υπάρχει κίνδυνος διενέξεων μεταξύ πολλαπλών εκδοτών και πολλαπλών Συνδρομητών δεν είναι απαραίτητο ούτε τα συστατικά αλλά ούτε και ο πωλητής που τα διαχειρίζεται να γνωρίζει τον Εκδότη. Έτσι χρησιμοποιείται η διεπαφή της κλάσης γεγονότων σαν σημείο σύνδεσης Εκδότη και Συνδρομητή. Στην ιδανική περίπτωση το σύστημα θα εντοπίσει μια διεπαφή κλάσης γεγονότων που είναι συμβατή με τη συνδρομή που ρυθμίζουμε και θα την εμφανίσει. Ο πωλητής απλά την επιλέγει και προχωρά στο επόμενο πλαίσιο διαλόγου. Υπάρχουν όμως και περιπτώσεις που το σύστημα δεν εντοπίζει τη διεπαφή της κλάσης γεγονότων που απαιτείται ή που δεν εντοπίζει καμία συμβατή κλάση. Αυτό είναι ένα θέμα που αφορά κυρίως στις διαφορές Σελίδα 130 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

131 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» που μπορεί να υπάρχουν ανάμεσα στις γλώσσες προγραμματισμού που χρησιμοποιούνται για την κατασκευή των συστατικών και των κλάσεων γεγονότων και δεν αποτελεί πρόβλημα. Απλά για να ξεπεραστεί αυτή η ανωμαλία πρέπει στο βήμα που περιγράψαμε αντί να επιλεγεί η συγκεκριμένη διεπαφή που ενδιαφέρει, να τσεκαριστεί το κουτάκι "Use all interfaces for this component". Αυτό θα αναγκάσει το σύστημα στο επόμενο βήμα να εμφανίσει όλες τις διαθέσιμες διεπαφές κλάσεων γεγονότων, από τις οποίες ο πωλητής θα μπορέσει να επιλέξει την κατάλληλη. Σχήμα 50: Το σύστημα εντοπίζει τη διεπαφή που είναι συμβατή με την κλάση Συνδρομητή. Για να ολοκληρωθεί η διαδικασία συνδρομής πρέπει στο επόμενο πλαίσιο διαλόγου να δοθεί ένα όνομα στην νέα συνδρομή και να ενεργοποιηθεί η νέα συνδρομή. Εδώ έρχεται και ένας κανόνας ονοματολογίας του ΟΔΥΣΣΕΑ: Είναι γνωστό ότι υπάρχουν τέσσερις τύποι δεδομένων για την επικοινωνία μεταξύ των συστατικών του Βοηθήματος Διαπροσωπικής Επικοινωνίας. Αντίστοιχα χωρισμένες είναι και οι διεπαφές που χρησιμοποιούνται για την επικοινωνία και κατά συνέπεια αυτές είναι η character για την επικοινωνία ανά χαρακτήρα, word για την επικοινωνία ανά λέξη, sentence για την επικοινωνία ανά πρόταση και document για την επικοινωνία ανά ολόκληρο έγγραφο κειμένου. Όταν γίνεται μια συνδρομή σε κάποια από αυτές τις διεπαφές είναι καλό για λόγους συντήρησης η συνδρομή να παίρνει και το αντίστοιχο όνομα. Έτσι στο παράδειγμά μας, δίνεται το όνομα Word στη νέα συνδρομή, μια και η διεπαφή που χρησιμοποιήθηκε ήταν η word. Η τελευταία κίνηση που κάνει ο πωλητής σε αυτή την εγκατάσταση είναι να τσεκάρει το κουτάκι "Enable this subscription immediately" για να ενεργοποιήσει αμέσως τη συνδρομή που δημιούργησε (βλέπε επόμενο Σχήμα). Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 131 από 163

132 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Σχήμα 51: Ορισμός ονόματος και ενεργοποίηση της συνδρομής. Σχήμα 52: Απεικόνιση του παραθύρου των Component Services μετά την ολοκλήρωση της εγκατάστασης των συστατικών. Μετά την ολοκλήρωση της διαδικασίας εγκατάστασης των συστατικών του Βοηθήματος Διαπροσωπικής Επικοινωνίας, το παράθυρο των Component Services φαίνεται όπως στο παραπάνω Σχήμα. Βέβαια, ανάλογα με τη σύνθεση και τα χαρακτηριστικά κάθε εφαρμογής, μπορεί να υπάρχουν περισσότερα συστατικά καθώς και περισσότερες συνδρομές. Επίσης, όπως αναφέρθηκε μπορεί να υπάρχουν πολλαπλοί Εκδότες και Σελίδα 132 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

133 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» πολλαπλοί Συνδρομητές, καθώς και συστατικά που είναι Εκδότες και Συνδρομητές συγχρόνως. Σε τέτοιες περιπτώσεις αιτούνται ειδικότερες διαχειριστικές ενέργειες από πλευράς του πωλητή και αυτές περιγράφονται στην ενότητα για το συγχρονισμό και το φιλτράρισμα των συστατικών. Στο παρακάτω Σχήμα φαίνεται ένα screenshot όπου απεικονίζεται η οθόνη του υπολογιστικού συστήματος κατά τη λειτουργία των δύο δοκιμαστικών συστατικών που εγκαταστήσαμε. Δεν αποτελεί σε καμία περίπτωση ένα Βοήθημα Διαπροσωπικής Επικοινωνίας, αλλά μάλλον ένα μέσο δοκιμής της τεχνολογικής υποδομής του πλαισίου ΟΔΥΣΣΕΑΣ. Έτσι η μόνη λειτουργικότητα που έχει αυτό το σύστημα είναι ότι, ό,τι γράφει ο χρήστης στο πλαίσιο κειμένου του ενός συστατικού (Component Εισόδου), εμφανίζεται (αφού ολοκληρωθεί μια λέξη) στο πλαίσιο κειμένου του δεύτερου συστατικού (Component Εξόδου). Το Πρώτο είναι ο Εκδότης και το δεύτερο ο Συνδρομητής. Διακρίνεται επίσης και το κουμπί κλεισίματος της όλης εφαρμογής. Σχήμα 53: Screenshot από τη λειτουργία των δοκιμαστικών συστατικών. Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 133 από 163

134 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» 3.4. Συγχρονισμός και Φιλτράρισμα Μια σημαντική διαχειριστική υπευθυνότητα που έχουν οι πωλητές των Βοηθημάτων Διαπροσωπικής Επικοινωνίας που βασίζονται στο πλαίσιο ΟΔΥΣΣΕΑΣ, είναι ο συγχρονισμός των συστατικών που αποτελούν την εφαρμογή. Ο συγχρονισμός αυτός επιτυγχάνεται με δύο τρόπους, ανάλογα με την εκάστοτε σύνθεση του βοηθήματος. 1. Αυτόματος Συγχρονισμός: Αυτή είναι η περίπτωση που δε χρειάζεται καμία επέμβαση του πωλητή για να επιτευχθεί ο συγχρονισμός και η ομαλή συνεργασία των συστατικών. Το πλαίσιο ΟΔΥΣΣΕΑΣ προβλέπει, όπως έχει περιγραφεί, τέσσερις τύπους δεδομένων: χαρακτήρα, λέξη, πρόταση και έγγραφο. Αντίστοιχες είναι και οι διεπαφές που χρησιμοποιούνται από τα συστατικά για την επικοινωνία τους. Ο αυτόματος συγχρονισμός πολλών συστατικών στη σειρά επιτυγχάνεται με το γεγονός ότι τα διαδοχικά συστατικά μπορεί να επικοινωνούν με διαφορετικές διεπαφές. Για παράδειγμα, αν το συστατικό εισόδου δίνει έξοδο χαρακτήρα (ένα συμβατικό πληκτρολόγιο επί της οθόνης), ένα ενδιάμεσο συστατικό λαμβάνει χαρακτήρα και δίνει έξοδο λέξη (ένας προβλέπτης λέξεων), ένα δεύτερο ενδιάμεσο λαμβάνει λέξεις και εκδίδει έγγραφο (ένα συστατικό σύνθεσης ηλεκτρονικών μηνυμάτων ) και το συστατικό εξόδου λαμβάνει στην είσοδό του έγγραφα (ένα συστατικό αποστολής ηλεκτρονικής αλληλογραφίας) τότε δεν υπάρχει ανάγκη διαχειριστικής επέμβασης για το συγχρονισμό τους. Δεν υπάρχει καμία περίπτωση για παράδειγμα, δύο συστατικά να είναι Συνδρομητές στην ίδια διεπαφή και ενώ πρέπει να λειτουργούν σειριακά, το ένα μετά το άλλο πάντα με την ίδια σειρά, να μπερδεύονται λόγω έλλειψης συγχρονισμού και να λειτουργούν με την αντίθετη σειρά. Συστατικό Εισόδου Ενδιάμεσο Συστατικό Ενδιάμεσο Συστατικό Συστατικό Εξόδου Εικονικό πληκτρολόγιο χαρακτήρων Πρόβλεψη λέξεων Σύνθεση εγγράφου Αποστολή Διεπαφή χαρακτήρα character Διεπαφή λέξης word Διεπαφή εγγράφου document Σχήμα 54: Περίπτωση αυτόματου συγχρονισμού διαδοχικών συστατικών. 2. Διαχειριστικός Συγχρονισμός: Πρόκειται για την περίπτωση στην οποία υπάρχει αναγκαιότητα για συγχρονισμό των συστατικών διαχειριστικά, μέσω της διεπαφής χρήσης των Component Services και συγκεκριμένα μέσω της υπηρεσίας filtering (φιλτράρισμα). Η ανάγκη για τον «χειροκίνητο» συγχρονισμό των συστατικών του Βοηθήματος προκύπτει συνήθως όταν υπάρχουν πολλαπλοί Εκδότες ή πολλαπλοί Συνδρομητές Σελίδα 134 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

135 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» ή ενδιάμεσα συστατικά που είναι Εκδότες και Συνδρομητές συγχρόνως και κάποια από όλα αυτά τα συστατικά χρησιμοποιούν τις ίδιες διεπαφές. Για να φανεί το πρόβλημα, ας θεωρήσουμε την απλή περίπτωση ενός ενδιάμεσου συστατικού (μεταφραστής) του οποίου και οι δύο διεπαφές (εισόδου και εξόδου) υλοποιούνται με τη χρήση της word, δηλαδή το συστατικό λαμβάνει ως Συνδρομητής μια λέξη, την επεξεργάζεται και την εκδίδει ως Εκδότης. Αν ένα συστατικό εισόδου (Εικονικό Πληκτρολόγιο Λέξεων) εκδώσει μια λέξη στη διεπαφή word, αυτό το ενδιάμεσο συστατικό την λαμβάνει και αφού την επεξεργαστεί, την επανεκδίδει στην ίδια διεπαφή (ίσως σε διαφορετική γλώσσα). Αφού όμως και το ίδιο είναι Συνδρομητής σε αυτήν τη διεπαφή, ξαναλαμβάνει την επεξεργασμένη λέξη, την οποία κανονικά θα έπρεπε να λάβει ένα επόμενο συστατικό ή ένα συστατικό εξόδου (Συνθέτης Ομιλίας). Η διαδικασία επαναλαμβάνεται και το σύστημα εισέρχεται σε έναν ατελείωτο φαύλο κύκλο. Το ενδιάμεσο συστατικό λαμβάνει ως είσοδο την έξοδό του επ άπειρο μέχρι να καταρρεύσει το σύστημα. Ένα υποθετικό συστατικό εξόδου πάλι σε αυτό το σύστημα (ο Συνθέτης Ομιλίας), θα πρέπει και εκείνο να είναι Συνδρομητής στη διεπαφή λέξεων μια και πρέπει να εκφωνεί τις επεξεργασμένες λέξεις που εξάγει το ενδιάμεσο συστατικό. Πρέπει όμως να λαμβάνει μόνο την έξοδο από το ενδιάμεσο συστατικό, ενώ τώρα θα λαμβάνει και την έξοδο από το συστατικό εισόδου. Συστατικό Εισόδου Εικονικό πληκτρολόγιο λέξεων Ενδιάμεσο Συστατικό Μετάφραση Συστατικό Εξόδου Συνθέτης Ομιλίας Διεπαφή λέξης word Διεπαφή λέξης word Σχήμα 55: Περίπτωση στην οποία χρειάζεται διαχειριστικός συγχρονισμός των συστατικών. Τη λύση σε αυτά τα προβλήματα έρχεται να δώσει η δυνατότητα φιλτραρίσματος των γεγονότων στα Component Services, σε συνδυασμό με τον κατάλληλο σχεδιασμό του ΟΔΥΣΣΕΑ ώστε να εκμεταλλεύεται το πλαίσιο σωστά αυτήν τη δυνατότητα. Όπως έχει αναφερθεί, η βασική διεπαφή ή κλάση γεγονότων του ΟΔΥΣΣΕΑ προβλέπει την αποστολή από τον Εκδότη στο Συνδρομητή δύο πεδίων με αλφαριθμητικές σειρές. Το ένα πεδίο ονομάζεται data και το άλλο ονομάζεται PubID. Η υπηρεσία γεγονότων του COM+ προσφέρει τη δυνατότητα σε έναν Συνδρομητή μιας κλάσης γεγονότων να φιλτράρει τα γεγονότα που λαμβάνει, μέσω των ονομάτων των μεταβλητών που περνούν αυτά τα γεγονότα στο Συνδρομητή. Είναι γνωστό ότι στο σύστημα γεγονότων του πλαισίου ΟΔΥΣΣΕΑΣ η πρώτη μεταβλητή των μηνυμάτων που ανταλλάσσονται μεταξύ των συστατικών (με φορά από τους Εκδότες προς τους Συνδρομητές), περιέχει τα χρήσιμα δεδομένα (για παράδειγμα τη λέξη που πρέπει να εκφωνηθεί), ενώ η δεύτερη μεταβλητή περιέχει το Class ID του συστατικού που στέλνει το μήνυμα, δηλαδή του Εκδότη. Μέσω Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 135 από 163

136 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» αυτής της δεύτερης μεταβλητής λοιπόν, μπορεί να γίνει το φιλτράρισμα των Εκδοτών από την πλευρά των Συνδρομητών. Υπάρχει δηλαδή η δυνατότητα, ένας Συνδρομητής να ρυθμιστεί διαχειριστικά, έτσι ώστε, να δέχεται και να επεξεργάζεται τα μηνύματα που του έρχονται από Εκδότες με συγκεκριμένο Class ID. Έτσι λοιπόν χρησιμοποιώντας την PubID ως φίλτρο και δηλώνοντας σε ένα ειδικό πλαίσιο διαλόγου τα κριτήρια που θα χρησιμοποιηθούν για κάθε συγκεκριμένο Συνδρομητή, γίνεται διαχειριστικά η επιλογή για το ποιος Συνδρομητής θα ακούει ποιον Εκδότη και κατ επέκταση επιτυγχάνεται ο συγχρονισμός και η επιθυμητή σειρά των συστατικών. Για να κάνουμε τα πράγματα πιο συγκεκριμένα και να επιδειχτεί η διαδικασία συγχρονισμού χρησιμοποιούμε και ένα τρίτο συστατικό επίδειξης και ελέγχου που αναπτύχθηκε κατά την κατασκευή του πλαισίου ΟΔΥΣΣΕΑΣ. Πρόκειται για ένα ενδιάμεσο συστατικό (δηλαδή δεν είναι ούτε συστατικό εισόδου ούτε συστατικό εξόδου), το οποίο η μόνη επεξεργασία που κάνει στα δεδομένα που είναι να αντιστρέφει τους χαρακτήρες της αλφαριθμητικής σειράς που λαμβάνει πριν την επανεκδώσει. Η διεπαφή του και στην είσοδο και στην έξοδο υποστηρίζει τον τύπο δεδομένων «λέξη» και μόνον αυτόν. Έτσι γίνεται φανερό ότι με τα τρία δοκιμαστικά συστατικά επιτυγχάνεται μια σύνθεση εφαρμογής που δομικά συμπίπτει με αυτή του προηγούμενου σχήματος και μας δημιουργεί πρόβλημα συγχρονισμού. Στο επόμενο Σχήμα φαίνεται η σύνθεση της εφαρμογής μετά την πρόσθεση και του ενδιάμεσου συστατικού. Παρατηρεί κανείς ότι υπάρχουν τώρα δύο συστατικά που έχουν συνδρομή στη διεπαφή word και δύο Εκδότες που εκδίδουν σε αυτή τη διεπαφή. Όταν τρέξει αυτή η εφαρμογή χωρίς περαιτέρω ρύθμιση, η συμπεριφορά της θα είναι απρόβλεπτη. Σχήμα 56: Σύνθεση εφαρμογής με τρία συστατικά (εισόδου, ενδιάμεσο, εξόδου). Απαιτείται συγχρονισμός. Σελίδα 136 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

137 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Η διαδικασία που πρέπει σε παρόμοια περίπτωση να ακολουθηθεί είναι η εξής: Ο πωλητής πρέπει αφού δημιουργήσει τις συνδρομές, για κάθε μία που παρουσιάζει διένεξη ξεχωριστά, να εμφανίσει τις ιδιότητές της επιλέγοντας «Properties» από το αναδυόμενο μενού της (μετά από δεξί κλικ). Στη συνέχεια στην περιοχή «Options» του πλαισίου διαλόγου πρέπει να ρυθμίσει το πεδίο «Filter criteria» σύμφωνα με τις ανάγκες για συντονισμό και ταξινόμηση των συστατικών. Στο παράδειγμά μας πρέπει η έξοδος από το συστατικό εισόδου, να δίνεται ως είσοδος στο ενδιάμεσο συστατικό και αυτού η έξοδος με τη σειρά της να δίνεται ως είσοδος στο συστατικό εξόδου. Έτσι θα πρέπει να τεθεί ως κριτήριο στο ενδιάμεσο συστατικό να επεξεργάζεται μόνο τα γεγονότα που εκδίδονται από το συστατικό εισόδου και αντίστοιχα στο συστατικό εξόδου μόνο αυτά που προέρχονται από το ενδιάμεσο. Αυτό γίνεται θέτοντας στο πεδίο των κριτηρίων φίλτρου της κάθε συνδρομής, τη ρύθμιση: PubID = {ClassID} όπου ClassID είναι το Class ID του Εκδότη που θέλει o κάθε Συνδρομητής να ακούει. Σχήμα 57: Το πλαίσιο διαλόγου για τη συμπλήρωση των κριτηρίων του φίλτρου. Το Class ID βρίσκεται πολύ εύκολα από το αναδυόμενο μενού κάθε συστατικού στην επιλογή «Properties» (βλέπε παρακάτω Σχήμα). Η πιο απλή και ασφαλής διαδικασία είναι η αντιγραφή και επικόλληση (Copy and Paste) του Class ID από αυτό το πλαίσιο διαλόγου, στο πεδίο των κριτηρίων φιλτραρίσματος της συνδρομής (πρέπει να αντιγραφεί το Class ID μαζί με τις αγκύλες). Έτσι λοιπόν στη συνδρομή Word του ενδιάμεσου συστατικού (MidComponent1.Subscriber), θέτουμε το κριτήριο με το Class ID του συστατικού εισόδου (In1.Publisher) και στη συνδρομή Word του συστατικού εξόδου Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 137 από 163

138 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» (Out1.Subscriber), θέτουμε το κριτήριο με το Class ID του ενδιάμεσου συστατικού (MidComponent1.Publisher). Σχήμα 58: Εύρεση του Class ID του Εκδότη. Η τυπική περίπτωση στην οποία απαιτείται αυτή διαδικασία για τον συγχρονισμό, είναι όταν ένα συστατικό έχει είσοδο και έξοδο στην ίδια διεπαφή. Αποφεύγεται έτσι η συνεχόμενη ανατροφοδότηση της εξόδου του στην είσοδό του μέσω της διεπαφής. Υπάρχουν όμως και περιπτώσεις όπου κάποιοι Συνδρομητές χρειάζονται είσοδο από πολλαπλούς Εκδότες στην ίδια διεπαφή. Σε τέτοιες περιπτώσεις αν ο Συνδρομητής απαιτεί είσοδο από ΌΛΟΥΣ του Εκδότες σε μια διεπαφή, δεν απαιτείται φιλτράρισμα στη συνδρομή του. Αν όμως απαιτεί είσοδο από πολλαπλούς μεν αλλά όχι όλους του Εκδότες σε μια διεπαφή, τότε δίνεται η δυνατότητα μέσω τελεστών OR να θέσει στα κριτήρια φίλτρου της συνδρομής του τη ρύθμιση για να «ακούει» πολλαπλά PubID. Σελίδα 138 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

139 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» 4. Υλοποίηση Δοκιμαστικών Συστατικών Στα πλαίσια της υλοποίησης του πλαισίου ΟΔΥΣΣΕΑΣ, αναπτύχθηκαν τρία δοκιμαστικά συστατικά τα οποία θα περιγραφούν παρακάτω. Τα τρία αυτά συστατικά δημιουργήθηκαν για πολλούς σκοπούς. Πρώτον αποτελούν υποδείγματα προς τους προγραμματιστές για τον τρόπο που θα πρέπει να χρησιμοποιούν τις υπηρεσίες του COM+ σύμφωνα με τις προδιαγραφές του ΟΔΥΣΣΕΑ. Πιο συγκεκριμένα, αποτελούν υποδείγματα για το πώς πρέπει να χρησιμοποιούνται οι υπηρεσίες γεγονότων του λειτουργικού συστήματος, πως αξιοποιείται και πως υλοποιείται η βασική διεπαφή του ΟΔΥΣΣΕΑ "Interface.dll", πως πρέπει να είναι δομημένα τα συστατικά Εκδότες και Συνδρομητές. Επίσης, αυτά τα δοκιμαστικά συστατικά είναι ελεύθερα διαθέσιμα για δοκιμές και ελέγχους από τους κατασκευαστές. Αυτό σημαίνει ότι αν ένας κατασκευαστής δημιουργεί για παράδειγμα ένα συστατικό εξόδου, για να το δοκιμάσει θα χρειαστεί ένα συστατικό εισόδου. Δεν χρειάζεται να κατασκευάσει το δικό του, αυτό το δοκιμαστικό συστατικό εισόδου προσφέρεται από το πλαίσιο ΟΔΥΣΣΕΑΣ και ο κατασκευαστή μπορεί έτσι να έχει μια είσοδο στα πρότυπα του πλαισίου για το συστατικό του. Τέλος, τα συστατικά αυτά χρησιμεύουν ως πρότυπα για την επίδειξη της εφαρμογής των κανόνων ονοματολογίας του ΟΔΥΣΣΕΑ, αλλά και ο τρόπος περιγραφής και τεκμηρίωσής τους, πρέπει να θεωρηθεί ως οδηγία και απαίτηση από τον ΟΔΥΣΣΕΑ για τη σωστή τεκμηρίωση των συστατικών τρίτων κατασκευαστών Δοκιμαστικό Συστατικό Εισόδου Περιγραφή: Πρόκειται για ένα πρότυπο συστατικό εισόδου που έχει κατασκευαστεί σύμφωνα με τις προδιαγραφές του πλαισίου ΟΔΥΣΣΕΑΣ. Το όνομα της βιβλιοθήκης που περιέχει αυτό το συστατικό είναι in1.dll. Αυτό είναι και το μόνο αρχείο που χρειάζεται για την εγκατάσταση του συστατικού. Ο προγραμματισμός του συστατικού έχει γίνει σε Microsoft Visual Basic 6.0 SP4, σε πλατφόρμα Windows 2000 Advanced Server. Προτείνεται η αποθήκευση του αρχείου του συστατικού σε φάκελο του τελικού χρήστη στη διαδρομή Program Files/Communicator/Components/Test Input Component. Η χρήση αυτού του συστατικού περιορίζεται σε δοκιμές που γίνονται στο πλαίσιο ΟΔΥΣΣΕΑΣ από τους κατασκευαστές ή πωλητές συστατικών και συστημάτων Εναλλακτικής και Επαυξητικής Επικοινωνίας. Η προγραμματιστική δομή του συστατικού φαίνεται στο παρακάτω Σχήμα. Σχήμα 59:Δομή του Δοκιμαστικού Συστατικό Εισόδου Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 139 από 163

140 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Προδιαγραφές: Το Δοκιμαστικό Συστατικό Εισόδου έχει διεπαφή χρήσης με τη βοήθεια της οποίας μπορεί ο τελικός χρήστης να αλληλεπιδράσει με αυτό. Ο έλεγχός του μπορεί να γίνει είτε με το πληκτρολόγιο μόνο, είτε με συνδυασμό πληκτρολογίου και ποντικιού. Η διεπαφή χρήσης είναι σε τη μορφή ενός παραθύρου διαλόγου και περιλαμβάνει πλαίσιο ελέγχου και πλήκτρα ελαχιστοποίησης, μεγιστοποίησης και κλεισίματος. Επίσης, παρέχει ένα πλαίσιο κειμένου στο οποίο ο χρήστης μπορεί να γράψει κείμενο με συμβατικό πληκτρολόγιο, καθώς και ένα πρόσθετο πλήκτρο για το κλείσιμο του συστατικού. Για να επιτευχθεί η λειτουργικότητα του συστατικού χρειάζεται οπωσδήποτε η ικανότητα από πλευράς του χρήστη να μπορεί να χρησιμοποιεί το τυπικό πληκτρολόγιο του ηλεκτρονικού υπολογιστή. Η χρήση του απευθύνεται στους προγραμματιστές και κατασκευαστές συστατικών συμβατών με το πλαίσιο ΟΔΥΣΣΕΑΣ, καθώς και στους πωλητές Βοηθημάτων Διαπροσωπικής Επικοινωνίας. Το παράθυρο της διεπαφής χρήσης του Δοκιμαστικού Συστατικού Εισόδου, έχει τη δυνατότητα να κρατάει τη θέση του μεταξύ διαδοχικών ανοιγμάτων. Αυτό σημαίνει ότι αν ο χρήστης, ο θεραπευτής ή ο πωλητής ρυθμίσει το μέγεθος και τη θέση του παραθύρου στην οθόνη, τότε την επόμενη φορά που θα ανοίξει αυτό το παράθυρο, θα «θυμάται» τη θέση στην οποία πρέπει να ανοίξει και το μέγεθος που θα πρέπει να έχει. Λειτουργικότητα: Η λειτουργικότητα του Δοκιμαστικού Συστατικού Εισόδου είναι περιορισμένη και φυσικά δεν ανταποκρίνεται σε καμία ανάγκη Ατόμων Με Αναπηρία, παρά σε απαιτήσεις πωλητών και κατασκευαστών για σκοπούς δοκιμής συστημάτων. Περιορίζεται λοιπόν, στην αποστολή των δεδομένων του χρήστη στην υπηρεσία γεγονότων για έκδοση σε επόμενα συστατικά. Τα δεδομένα του χρήστη είναι απλώς αυτά που πληκτρολογεί ο χρήστης στο πλαίσιο κειμένου που παρέχεται από το συστατικό. Το Δοκιμαστικό Συστατικό Εισόδου εκδίδει τα δεδομένα κατά τη διάρκεια της πληκτρολόγησης είτε ανά χαρακτήρα, είτε ανά λέξη, είτε ανά φράση. Ως διαχωριστικό για τις λέξεις θεωρείται το κενό (space) και ως διαχωριστικό για προτάσεις και λέξεις το θαυμαστικό, η τελεία, το ερωτηματικό και το enter. Για την αποστολή των δεδομένων προς έκδοση δεν απαιτείται κάποια πρόσθετη παρέμβαση του χρήστη, η διαδικασία ενεργοποιείται από την πληκτρολόγηση. Διεπαφές: Το Δοκιμαστικό Συστατικό Εισόδου εκδίδει δεδομένα σε τρεις διεπαφές: την Character (ανά χαρακτήρα), την Word (ανά λέξη) και την Sentence (ανά πρόταση). H κλάση που περιέχει τον κώδικα για τη διαδικασία έκδοσης λέγεται, σύμφωνα με τις οδηγίες του ΟΔΥΣΣΕΑ, Publisher και περιέχει τη μέθοδο Publish, όπου υλοποιείται η έκδοση σε κάθε μία από τις υποστηριζόμενες διεπαφές. Φυσικά σύμφωνα με τις τυποποιήσεις του πλαισίου, το Δοκιμαστικό Συστατικό Εισόδου, μαζί με τα δεδομένα του χρήστη, εκδίδει και την ταυτότητά του, δηλαδή το Class ID του μαζί με κάθε μήνυμα. Το Class ID της κλάσης Publisher του συστατικού είναι: Class ID: {9E C1-42F1-B083-4CF4B27D198F} Οδηγίες χρήσης: Ακολουθούν οι οδηγίες χρήσης για πωλητές και τελικούς χρήστες. Πωλητές: Η διαδικασία εγκατάστασης του Δοκιμαστικού Συστατικού Εισόδου στην εφαρμογή του Βοηθήματος Διαπροσωπικής Επικοινωνίας είναι η τυπική που ακολουθείται για όλα τα απλά συστατικά Εκδότες. Απλά προστίθεται το αρχείο in1.dll ως νέο συστατικό στα Component Services και στην εφαρμογή AENEAS. Αυτή η διαδικασία είναι αρκετή για τη σωστή λειτουργία του συστατικού και δεν Σελίδα 140 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

141 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» χρειάζεται τίποτα παραπάνω. Σε αυτό το συστατικό μπορούν να γίνουν συνδρομητές οποιαδήποτε συστατικά υποστηρίζουν υλοποιήσεις των διεπαφών που αναφέρθηκαν παραπάνω. Αν απαιτείται συγχρονισμός των συνδρομητών των διεπαφών του Δοκιμαστικού Συστατικού Εισόδου, πρέπει να χρησιμοποιηθούν τεχνικές φιλτραρίσματος με εκμετάλλευση του εκδιδόμενου Class ID στο πεδίο PubID. Τελικοί χρήστες: Η χρήση του συστατικού για τους τελικούς χρήστες περιορίζεται στη δυνατότητα πληκτρολόγησης κειμένου με συμβατικό πληκτρολόγιο στο πλαίσιο κειμένου που παρέχει. Μπορεί να πληκτρολογηθεί οτιδήποτε και ότι πληκτρολογηθεί θα περάσει στα επόμενα συστατικά αν αυτά υπάρχουν. Επίσης, η διεπαφή χρήσης παρέχει και ένα πλήκτρο «Έξοδος» για το κλείσιμο του συστατικού. Αυτός είναι και ο προτεινόμενος τρόπος «κλεισίματος» του Δοκιμαστικού Συστατικού Εισόδου. Αφού απενεργοποιηθεί το συστατικό, πρέπει να επανεκκινηθεί ο Communicator για να επανενεργοποιηθεί. Τέλος, μπορεί ο χρήστης να αλλάξει το μέγεθος και τη θέση του παραθύρου της διεπαφής χρήσης. Την επόμενη φορά που θα ενεργοποιηθεί το συστατικό, θα εμφανιστεί το παράθυρό του στη θέση και με το μέγεθος που είχε την τελευταία φορά που ήταν ανοιχτό. Σχήμα 60: Η διεπαφή χρήσης του Δοκιμαστικού Συστατικού Εισόδου. Κώδικας Φόρμα frmui (Διεπαφή χρήσης) Option Explicit 'Δήλωση ενός Εκδότη Dim Publisher As New Publisher Private Sub cmdexit_click() 'Κλείσιμο της φόρμας με το πάτημα του πλήκτρου εξόδου Unload Me End Sub 'Τί γίνεται όταν φορτώνεται η φόρμα; Private Sub Form_Load() Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 141 από 163

142 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» 'Δήλωση μεταβλητών για διαχείριση αρχείων Dim fs, f, ts 'Δήλωση μεταβλητών για καταχώρηση θέσης και μεγέθους της φόρμας Dim h, l, t, w 'Ένα αντικείμενο του συστήματος αρχείων Set fs = CreateObject("Scripting.FileSystemObject") 'Αν υπάρχει αρχείο που κρατά τα δεδομένα θέσης και μεγέθους του παραθύρου 'τότε να διαβαστούν αυτά τα δεδομένα για ανοίξει στην τελευταία του θέση If fs.fileexists("in1.ini") Then End If Set f = fs.getfile("in1.ini") Set ts = f.openastextstream(1) h = ts.readline l = ts.readline t = ts.readline w = ts.readline Me.Height = h Me.Left = l Me.Top = t Me.Width = w ts.close Set ts = Nothing Set f = Nothing Set fs = Nothing End Sub 'Τί γίνεται όταν κλείνει η φόρμα; Private Sub Form_Unload(Cancel As Integer) 'Δήλωση μεταβλητών για διαχείριση αρχείων Dim fs, f 'Δήλωση μεταβλητών για καταχώρηση θέσης και μεγέθους της φόρμας Dim h, l, t, w 'Καταχώρηση θέσης και μεγέθους παραθύρου h = Str(frmUI.Height) l = Str(frmUI.Left) t = Str(frmUI.Top) w = Str(frmUI.Width) 'Ένα αντικείμενο του συστήματος αρχείων Σελίδα 142 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

143 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Set fs = CreateObject("Scripting.FileSystemObject") 'Δημιουργία αρχείου που περιέχει τα δεδομένα θέσης και μεγέθους του παραθύρου Set f = fs.createtextfile("in1.ini", True) f.writeline (h) f.writeline (l) f.writeline (t) f.writeline (w) f.close Set f = Nothing Set fs = Nothing 'Καθάρισμα της μνήμης από το αντικείμενο Εκδότη Set Publisher = Nothing End Sub 'Τί γίνεται όταν αλλάζουν τα περιεχόμενα του πλαισίου κειμένου; Private Sub txtinput_change() 'Εκδίδονται τα δεδομένα Publisher.Publish txtinput.text End Sub Κώδικας 5: Ο κώδικας της φόρμας (διεπαφή χρήσης) του Δοκιμαστικού Συστατικού Εισόδου Κλάση Activate 'Τί γίνεται όταν καλείται (αρχικοποιείται) η κλάση; Private Sub Class_Initialize() 'Εμφανίζεται η φόρμα διεπαφής χρήσης frmui.show End Sub Κώδικας 6: Ο κώδικας της κλάσης ενεργοποίησης της διεπαφής χρήσης του Δοκιμαστικού Συστατικού Εισόδου Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 143 από 163

144 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Κλάση Publisher Option Explicit 'Μεταβλητή που θα πάρει το Class ID του Εκδότη Dim PubID 'Μεταβλητές για τον έλεγχο της θέσης του κέρσορα Dim offsetchar As Long Dim offsetword As Long Dim offsetsent As Long 'Μέθοδος για την Έκδοση δεδομένων Public Function Publish(text As String) 'Μεταβλητή που θα πάρει τα δεδομένα του χρήστη Dim data As String 'Δήλωση ενός αντικειμένου Dim objeventclass As Object 'Ανάθεση του Class ID του Εκδότη PubID = "{9E C1-42F1-B083-4CF4B27D198F}" 'Τα δεδομένα του χρήστη είναι το κείμενα του πλαισίου κειμένου data = Mid(text, offsetchar) offsetchar = Len(text) + 1 'Περίπτωση Έκδοσης χαρακτήρα 'Ανάθεση στο αντικείμενο ενός στιγμιοτύπου κλάσης της Interface Character Set objeventclass = CreateObject("Interface.Character") 'Χρησιμοποίηση της μεθόδου Communicate του αντικειμένου, για την έκδοση των δεδομένων data objeventclass.communicate data, PubID 'Περίπτωση που Εκδίδεται λέξη If Mid(text, Len(text)) = " " Or Mid(text, Len(text)) = "." Or Mid(text, Len(text)) = vblf Or Mid(text, Len(text)) = "!" Or Mid(text, Len(text)) = "?" Then End If data = RTrim(Mid(text, offsetword)) Set objeventclass = CreateObject("Interface.Word") objeventclass.communicate data, PubID offsetword = Len(text) + 1 'Περίπτωση που Εκδίδεται Πρόταση If Mid(text, Len(text)) = "." Then data = RTrim(Mid(text, offsetsent)) Set objeventclass = CreateObject("Interface.Sentence") objeventclass.communicate data, PubID Σελίδα 144 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

145 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» End If offsetsent = Len(text) + 1 'διαγραφή του αντικειμένου από τη μνήμη (αφού τελειώσει την αποστολή του ως Εκδότης) Set objeventclass = Nothing End Function 'Τί γίνεται όταν αρχικοποιείται η κλάση; Private Sub Class_Initialize() 'αρχικοποιούνται οι μεταβλητές θέσης του κέρσορα για τον έλεγχο 'του που αρχίζει και που τελειώνει το κείμενο προς έκδοση offsetchar = 1 offsetword = 1 offsetsent = 1 End Sub Κώδικας 7: Ο κώδικας της κλάσης Έκδοσης του Δοκιμαστικού Συστατικού Εισόδου 4.2. Δοκιμαστικό Συστατικό Εξόδου Περιγραφή: Πρόκειται για ένα πρότυπο συστατικό εξόδου που έχει κατασκευαστεί σύμφωνα με τις προδιαγραφές του πλαισίου ΟΔΥΣΣΕΑΣ. Το όνομα της βιβλιοθήκης που περιέχει αυτό το συστατικό είναι out1.dll. Αυτό είναι και το μόνο αρχείο που χρειάζεται για την εγκατάσταση του συστατικού. Ο προγραμματισμός του συστατικού έχει γίνει σε Microsoft Visual Basic 6.0 SP4, σε πλατφόρμα Windows 2000 Advanced Server. Προτείνεται η αποθήκευση του αρχείου του συστατικού σε φάκελο του τελικού χρήστη στη διαδρομή Program Files/Communicator/Components/Test Output Component. Η χρήση αυτού του συστατικού περιορίζεται σε δοκιμές που γίνονται στο πλαίσιο ΟΔΥΣΣΕΑΣ από τους κατασκευαστές ή πωλητές συστατικών και συστημάτων Εναλλακτικής και Επαυξητικής Επικοινωνίας. Η προγραμματιστική δομή του συστατικού φαίνεται στο παρακάτω Σχήμα. Σχήμα 61:Δομή του Δοκιμαστικού Συστατικού Εξόδου Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 145 από 163

146 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Προδιαγραφές: Το Δοκιμαστικό Συστατικό Εξόδου έχει διεπαφή χρήσης με τη βοήθεια της οποίας μπορεί ο τελικός χρήστης να αλληλεπιδράσει με αυτό. Ο έλεγχός του μπορεί να γίνει είτε με το πληκτρολόγιο, είτε με το ποντίκι. Η διεπαφή χρήσης είναι σε τη μορφή ενός παραθύρου διαλόγου και περιλαμβάνει πλαίσιο ελέγχου και πλήκτρα ελαχιστοποίησης, μεγιστοποίησης και κλεισίματος. Επίσης, παρέχει ένα πλαίσιο κειμένου στο οποίο ο χρήστης μπορεί να διαβάσει κείμενο, καθώς και ένα πρόσθετο πλήκτρο για το κλείσιμο του συστατικού. Η χρήση του απευθύνεται στους προγραμματιστές και κατασκευαστές συστατικών συμβατών με το πλαίσιο ΟΔΥΣΣΕΑΣ, καθώς και στους πωλητές Βοηθημάτων Διαπροσωπικής Επικοινωνίας. Το παράθυρο της διεπαφής χρήσης του Δοκιμαστικού Συστατικού Εξόδου, έχει τη δυνατότητα να κρατάει τη θέση του μεταξύ διαδοχικών ανοιγμάτων. Αυτό σημαίνει ότι αν ο χρήστης, ο θεραπευτής ή ο πωλητής ρυθμίσει το μέγεθος και τη θέση του παραθύρου στην οθόνη, τότε την επόμενη φορά που θα ανοίξει αυτό το παράθυρο, θα «θυμάται» τη θέση στην οποία πρέπει να ανοίξει και το μέγεθος που θα πρέπει να έχει. Λειτουργικότητα: Η λειτουργικότητα του Δοκιμαστικού Συστατικού Εισόδου είναι περιορισμένη και φυσικά δεν ανταποκρίνεται σε καμία ανάγκη Ατόμων Με Αναπηρία, παρά σε απαιτήσεις πωλητών και κατασκευαστών για σκοπούς δοκιμής συστημάτων. Περιορίζεται λοιπόν, στην παραλαβή των δεδομένων του χρήστη από την υπηρεσία γεγονότων και από συστατικά Εκδότες. Τα δεδομένα του χρήστη εμφανίζονται μετά την παραλαβή τους στο πλαίσιο κειμένου που παρέχεται από το συστατικό. Το Δοκιμαστικό Συστατικό Εξόδου λαμβάνει τα δεδομένα κατά τη διάρκεια της λειτουργίας του ανά λέξη. Για την παραλαβή και εμφάνιση των δεδομένων δεν απαιτείται κάποια πρόσθετη παρέμβαση του χρήστη, η διαδικασία ενεργοποιείται από την υπηρεσία γεγονότων, μετά τις απαραίτητες διαχειριστικές ρυθμίσεις του πωλητή. Διεπαφές: Το Δοκιμαστικό Συστατικό Εξόδου μπορεί να είναι συνδρομητής σε οσαδήποτε συστατικά Εκδότες στη διεπαφή Word (ανά λέξη). H κλάση που περιέχει τον κώδικα για τη διαδικασία παραλαβής και εμφάνισης των δεδομένων λέγεται, σύμφωνα με τις οδηγίες του ΟΔΥΣΣΕΑ, Subscriber. Φυσικά σύμφωνα με τις τυποποιήσεις του πλαισίου, το Δοκιμαστικό Συστατικό Εξόδου, μαζί με τα δεδομένα του χρήστη, λαμβάνει και την ταυτότητα του Εκδότη, δηλαδή το Class ID του μαζί με κάθε μήνυμα. Οδηγίες χρήσης: Ακολουθούν οι οδηγίες χρήσης για πωλητές και τελικούς χρήστες. Πωλητές: Η διαδικασία εγκατάστασης του Δοκιμαστικού Συστατικού Εξόδου στην εφαρμογή του Βοηθήματος Διαπροσωπικής Επικοινωνίας είναι η τυπική που ακολουθείται για όλα τα απλά συστατικά Συνδρομητές. Απλά προστίθεται το αρχείο out1.dll ως νέο συστατικό στα Component Services και στην εφαρμογή AENEAS. Στη συνέχεια, ο πωλητής θα πρέπει να ρυθμίσει τη συνδρομή του συστατικού σε δεδομένα της κατάλληλης διεπαφής και του κατάλληλου Εκδότη. Συνίσταται σύμφωνα με τις οδηγίες του ΟΔΥΣΣΕΑ, να δοθεί στη συνδρομή το όνομα Word. Αφού γίνει η συνδρομή σε συγκεκριμένη διεπαφή (την Interface.Word) το Δοκιμαστικό Συστατικό Εξόδου θα λαμβάνει οτιδήποτε Εκδίδεται από οποιονδήποτε Εκδότη στη διεπαφή αυτή. Για αυτό το συστατικό μπορούν λειτουργήσουν ως Εκδότες οποιαδήποτε συστατικά υποστηρίζουν έκδοση στη διεπαφή Word. Αν χρειάζεται φιλτράρισμα των Εκδοτών αυτό μπορεί να γίνει πάλι με τον τυπικό τρόπο με τη χρήση της υπηρεσίας φιλτραρίσματος στην Σελίδα 146 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

147 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» συνδρομή. Αρκεί να τεθεί ως όρισμα στο κατάλληλο πεδίο κριτηρίων φίλτρου το ή τα PubID των εκδοτών από τους οποίους η παραλαβή δεδομένων είναι επιθυμητή. Τελικοί χρήστες: Η χρήση του συστατικού για τους τελικούς χρήστες περιορίζεται στη δυνατότητα εμφάνισης κειμένου στο πλαίσιο κειμένου που παρέχει. Μπορεί να εμφανιστεί οτιδήποτε πληκτρολογηθεί στα συστατικά Εκδότες αν αυτά υπάρχουν. Επίσης, η διεπαφή χρήσης παρέχει και ένα πλήκτρο «Έξοδος» για το κλείσιμο του συστατικού. Αυτός είναι και ο προτεινόμενος τρόπος «κλεισίματος» του Δοκιμαστικού Συστατικού Εξόδου. Αφού απενεργοποιηθεί το συστατικό, πρέπει να επανεκκινηθεί ο Communicator για να επανενεργοποιηθεί. Τέλος, μπορεί ο χρήστης να αλλάξει το μέγεθος και τη θέση του παραθύρου της διεπαφής χρήσης. Την επόμενη φορά που θα ενεργοποιηθεί το συστατικό, θα εμφανιστεί το παράθυρό του στη θέση και με το μέγεθος που είχε την τελευταία φορά που ήταν ανοιχτό. Σχήμα 62: Η διεπαφή χρήσης του Δοκιμαστικού Συστατικού Εξόδου. Κώδικας: Φόρμα frmout (Διεπαφή χρήσης) 'Τί γίνεται όταν πατιέται το πλήκτρο Εξόδου; Private Sub Command1_Click() 'Κλείνει η φόρμα Unload Me End Sub Κώδικας 8: Ο κώδικας της φόρμας (διεπαφή χρήσης) του Δοκιμαστικού Συστατικού Εξόδου Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 147 από 163

148 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Κλάση Activate 'Τί γίνεται όταν αρχικοποιείται η κλάση; Private Sub Class_Initialize() 'Εμφανίζεται η φόρμα της διεπαφής χρήσης frmout.show End Sub Κώδικας 9: Ο κώδικας της κλάσης ενεργοποίησης της διεπαφής χρήσης του Δοκιμαστικού Συστατικού Εξόδου Κλάση Subscriber Option Explicit 'Δήλωση ότι πρόκειται να υλοποιηθεί η διεπαφή λέξης Interface.Word Implements Interface.Word 'Χρησιμοποίηση της μεθόδου Communicate της υλοποιούμενης διεπαφής για την 'παραλαβή και την επεξεργασία των δεδομένων Private Sub Word_Communicate(ByVal Data As String, ByVal PubID As String) 'Τα δεδομένα που παραλαμβάνονται εμφανίζονται στο πλαίσιο κειμένου frmout.txtoutput.text = frmout.txtoutput.text + " " + Data End Sub Κώδικας 10: Ο κώδικας της κλάσης Συνδρομής του Δοκιμαστικού Συστατικού Εξόδου 4.3. Δοκιμαστικό Ενδιάμεσο Συστατικό Περιγραφή: Πρόκειται για ένα πρότυπο Ενδιάμεσο συστατικό που έχει κατασκευαστεί σύμφωνα με τις προδιαγραφές του πλαισίου ΟΔΥΣΣΕΑΣ. Το όνομα της βιβλιοθήκης που περιέχει αυτό το συστατικό είναι MidComponent1.dll. Αυτό είναι και το μόνο αρχείο που χρειάζεται για την εγκατάσταση του συστατικού. Ο προγραμματισμός του συστατικού έχει γίνει σε Microsoft Visual Basic 6.0 SP4, σε πλατφόρμα Windows 2000 Advanced Server. Προτείνεται η αποθήκευση του αρχείου του συστατικού σε φάκελο του τελικού χρήστη στη διαδρομή Program Files/Communicator/Components/Test Mid Component. Η χρήση αυτού του συστατικού περιορίζεται σε δοκιμές που γίνονται στο πλαίσιο ΟΔΥΣΣΕΑΣ από τους κατασκευαστές ή πωλητές συστατικών και συστημάτων Εναλλακτικής και Επαυξητικής Επικοινωνίας. Η προγραμματιστική δομή του συστατικού φαίνεται στο παρακάτω Σχήμα. Σελίδα 148 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

149 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» Σχήμα 63:Δομή του Δοκιμαστικού Ενδιάμεσου Συστατικού Προδιαγραφές: Το Δοκιμαστικό Ενδιάμεσο Συστατικό έχει διεπαφή χρήσης με τη βοήθεια της οποίας μπορεί ο τελικός χρήστης να αλληλεπιδράσει με αυτό. Ο έλεγχός του μπορεί να γίνει είτε με το πληκτρολόγιο, είτε με το ποντίκι. Η διεπαφή χρήσης είναι σε τη μορφή ενός παραθύρου διαλόγου και περιλαμβάνει πλαίσιο ελέγχου και πλήκτρα ελαχιστοποίησης, μεγιστοποίησης και κλεισίματος. Επίσης, παρέχει δύο πλαίσια κειμένου στα οποία ο χρήστης μπορεί να διαβάσει το κείμενο που λαμβάνει, καθώς και αυτό που εκδίδει το συστατικό, καθώς και ένα πρόσθετο πλήκτρο για το κλείσιμο του συστατικού. Η χρήση του απευθύνεται στους προγραμματιστές και κατασκευαστές συστατικών συμβατών με το πλαίσιο ΟΔΥΣΣΕΑΣ, καθώς και στους πωλητές Βοηθημάτων Διαπροσωπικής Επικοινωνίας. Το παράθυρο της διεπαφής χρήσης του Δοκιμαστικού Ενδιάμεσου Συστατικού, έχει τη δυνατότητα να κρατάει τη θέση του μεταξύ διαδοχικών ανοιγμάτων. Αυτό σημαίνει ότι αν ο χρήστης, ο θεραπευτής ή ο πωλητής ρυθμίσει το μέγεθος και τη θέση του παραθύρου στην οθόνη, τότε την επόμενη φορά που θα ανοίξει αυτό το παράθυρο, θα «θυμάται» τη θέση στην οποία πρέπει να ανοίξει και το μέγεθος που θα πρέπει να έχει. Λειτουργικότητα: Η λειτουργικότητα του Δοκιμαστικού Ενδιάμεσου Συστατικού είναι περιορισμένη και φυσικά δεν ανταποκρίνεται σε καμία ανάγκη Ατόμων Με Αναπηρία, παρά σε απαιτήσεις πωλητών και κατασκευαστών για σκοπούς δοκιμής συστημάτων. Περιορίζεται λοιπόν, στην παραλαβή των δεδομένων του χρήστη από την υπηρεσία γεγονότων και από συστατικά Εκδότες. Τα δεδομένα του χρήστη εμφανίζονται μετά την παραλαβή τους στο πρώτο πλαίσιο κειμένου που παρέχεται από το συστατικό. Στη συνέχεια, κάνει μια στοιχειώδη επεξεργασία στα δεδομένα που δεν είναι τίποτα άλλο από την αντιστροφή των χαρακτήρων της λέξης που παρέλαβε. Τέλος η αντεστραμμένη λέξη εκδίδεται στην υπηρεσία γεγονότων. Το Δοκιμαστικό Ενδιάμεσο Συστατικό λαμβάνει τα δεδομένα κατά τη διάρκεια της λειτουργίας του ανά λέξη και τα εκδίδει πάλι ανά λέξη. Για την παραλαβή και εμφάνιση των δεδομένων δεν απαιτείται κάποια πρόσθετη παρέμβαση του χρήστη, η διαδικασία ενεργοποιείται από την υπηρεσία γεγονότων, μετά τις απαραίτητες ρυθμίσεις του πωλητή. Διεπαφές: Το Δοκιμαστικό Ενδιάμεσο Συστατικό μπορεί να είναι συνδρομητής σε οσαδήποτε συστατικά Εκδότες στη διεπαφή Word (ανά λέξη). H κλάση που περιέχει τον κώδικα για τη διαδικασία παραλαβής και εμφάνισης των δεδομένων λέγεται, σύμφωνα με τις οδηγίες του ΟΔΥΣΣΕΑ, Subscriber. Επίσης, το συστατικό αυτό λειτουργεί ταυτόχρονα και ως Εκδότης και μάλιστα εκδίδει τα δεδομένα του στην ίδια διεπαφή με αυτή από την οποία τα λαμβάνει. Αυτό σημαίνει ότι είναι επιβεβλημένη η διαχειριστική επέμβαση του πωλητή στη συνδρομή του συστατικού, ώστε να ρυθμιστούν σωστά τα Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 149 από 163

150 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» φίλτρα του και να μη λαμβάνει την έξοδό του πίσω στην είσοδο με απρόβλεπτα αποτελέσματα για τη λειτουργία του. H κλάση που περιέχει τον κώδικα για τη διαδικασία έκδοσης λέγεται σύμφωνα με τις οδηγίες του ΟΔΥΣΣΕΑ Publisher και περιέχει τη μέθοδο Publish, όπου υλοποιείται η έκδοση στη διεπαφή Word. Φυσικά σύμφωνα με τις τυποποιήσεις του πλαισίου, το Δοκιμαστικό Ενδιάμεσο Συστατικό, μαζί με τα δεδομένα του χρήστη, λαμβάνει και την ταυτότητα του Εκδότη, δηλαδή το Class ID του μαζί με κάθε μήνυμα. Επίσης, αποστέλλει τη δική του ταυτότητα μαζί με τα δεδομένα σε κάθε μήνυμα. Το Class ID της κλάσης Publisher του συστατικού είναι: Class ID: {BF6ADE75-3B16-4BD6-B23F-12B2B759D869} Οδηγίες χρήσης: Ακολουθούν οι οδηγίες χρήσης για πωλητές και τελικούς χρήστες. Πωλητές: Η διαδικασία εγκατάστασης του Δοκιμαστικού Ενδιάμεσου Συστατικού στην εφαρμογή του Βοηθήματος Διαπροσωπικής Επικοινωνίας είναι η τυπική που ακολουθείται για όλα τα απλά συστατικά Εκδότες σε συνδυασμό με τη διαδικασία που ακολουθείται για τα συστατικά - Συνδρομητές. Απλά προστίθεται το αρχείο MidComponent1.dll ως νέο συστατικό στα Component Services και στην εφαρμογή AENEAS. Στη συνέχεια, ο πωλητής θα πρέπει να ρυθμίσει τη συνδρομή του συστατικού σε δεδομένα της κατάλληλης διεπαφής και του κατάλληλου Εκδότη. Συνίσταται σύμφωνα με τις οδηγίες του ΟΔΥΣΣΕΑ, να δοθεί στη συνδρομή το όνομα Word. Αφού γίνει η συνδρομή σε συγκεκριμένη διεπαφή (την Interface.Word), το Δοκιμαστικό Ενδιάμεσο Συστατικό θα λαμβάνει οτιδήποτε Εκδίδεται από οποιονδήποτε Εκδότη στη διεπαφή αυτή. Για αυτό το συστατικό μπορούν λειτουργήσουν ως Εκδότες οποιαδήποτε συστατικά υποστηρίζουν έκδοση στη διεπαφή Word. Ένας από αυτούς τους Εκδότες είναι και το ίδιο το Δοκιμαστικό Ενδιάμεσο Συστατικό, με αποτέλεσμα να δε γίνουν περαιτέρω ρυθμίσεις συγχρονισμού να λαμβάνει στη είσοδό του και τη δική του έξοδο. Αυτό θα οδηγούσε σε μια ανώμαλη αναδρομική λειτουργία, που κατά πάσα πιθανότητα θα προκαλούσε την κατάρρευση του συστήματος. Είναι λοιπόν υποχρεωτικό στην περίπτωση αυτού του συστατικού, αλλά και σε όλα τα παρόμοια συστατικά που χρησιμοποιούν την ίδια διεπαφή για είσοδο και για έξοδο, να επέμβει διαχειριστικά ο πωλητής, ώστε να απομονώσει στην ουσία την είσοδο από την έξοδο. Αυτό θα γίνει με τον μη συμπεριληφθεί στα κριτήρια του φίλτρου της συνδρομής του συστατικού το Class ID της κλάσης Έκδοσης του ίδιου του συστατικού. Αρκεί να τεθεί ως όρισμα στο κατάλληλο πεδίο κριτηρίων φίλτρου το ή τα PubID των εκδοτών από τους οποίους η παραλαβή δεδομένων είναι επιθυμητή. Τελικοί χρήστες: Η χρήση του συστατικού για τους τελικούς χρήστες περιορίζεται στη δυνατότητα εμφάνισης κειμένου στα πλαίσια κειμένου που παρέχει. Μπορεί να εμφανιστεί οτιδήποτε πληκτρολογηθεί στα συστατικά Εκδότες αν αυτά υπάρχουν. Στο δεύτερο πλαίσιο κειμένου εμφανίζονται τα περιεχόμενα του πρώτου, τα οποί πρόκειται να αποσταλούν στα «επόμενα» συστατικά. Επίσης, η διεπαφή χρήσης παρέχει και ένα πλήκτρο «Έξοδος» για το κλείσιμο του συστατικού. Αυτός είναι και ο προτεινόμενος τρόπος «κλεισίματος» του Δοκιμαστικού Ενδιάμεσου Συστατικού. Αφού απενεργοποιηθεί το συστατικό, πρέπει να επανεκκινηθεί ο Communicator για να επανενεργοποιηθεί. Τέλος, μπορεί ο χρήστης να αλλάξει το μέγεθος και τη θέση του παραθύρου της διεπαφής χρήσης. Την επόμενη φορά που Σελίδα 150 από 163 Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής

151 Μέρος Β Υλοποίηση του Πλαισίου «ΟΔΥΣΣΕΑΣ» θα ενεργοποιηθεί το συστατικό, θα εμφανιστεί το παράθυρό του στη θέση και με το μέγεθος που είχε την τελευταία φορά που ήταν ανοιχτό. Σχήμα 64: Η διεπαφή χρήσης του Δοκιμαστικού Ενδιάμεσου Συστατικού. Κώδικας: Φόρμα frmui (Διεπαφή χρήσης) 'Τί γίνεται όταν πατιέται το πλήκρο Εξόδου; Private Sub cmdexit_click() 'Κλείνει η φόρμα Unload Me End Sub Κώδικας 11: Ο κώδικας για τη διεπαφή χρήσης του Δοκιμαστικού Ενδιάμεσου Συστατικού Κλάση Activate 'Τί γίνεται όταν αρχικοποιείται η κλάση; Private Sub Class_Initialize() 'Εμφανίζεται η φόρμα Διεπαφής Χρήσης frmui.show End Sub Κώδικας 12: Ο κώδικας για την κλάση ενεργοποίησης του Δοκιμαστικού Ενδιάμεσου Συστατικού Πανεπιστήμιο Αθηνών Τμήμα Πληροφορικής Σελίδα 151 από 163