Σύστημα DigiWallet Supporting the Real Economy

Transcript

1 Τεχνολογία Λογισμικού Τομέας Ηλεκτρονικής και Υπολογιστών Τμήμα ΗΜΜΥ Α.Π.Θ. 8 ο Εξάμηνο Άνοιξη 2012 Σύστημα DigiWallet Supporting the Real Economy Σχεδίαση Συστήματος Del.3.1 Version 1.0 Ονόματα μελών ομάδας & s Κιντσάκης Αθανάσιος - kintsaki@auth.gr Μόσχογλου Στέλιος - moschoglou@gmail.com Πάπιστας Ιωάννης - iapap1990@gmail.com Τούμπας Κωνσταντίνος - ktoumpas@auth.gr Ημερομηνία Παράδοσης : 21/05/2012 Ημερομηνία Τελικής Παράδοσης:

2 Ιστορικό Αλλαγών Όνομα Ημερομηνία Αλλαγή Έκδοση Α. Συμεωνίδης 29/05/2009 Δημιουργία Εγγράφου Προσαρμογή του ESA software engineering standards guidelines (1991) και του εγγράφου SDD document, από τους Bruegge και Dutoit (2004). Ομάδα 11 20/05/2012 Συμπλήρωση Εγγράφου 0.9 Ομάδα 11 06/07/2012 Διόρθωση των αρχικών SQL σε Structured Query Language Ομάδα 11 06/07/2012 Προστέθηκε ενότητα βιβλιογραφική επισκόπηση με τις πηγές από τις οποίες αντλήθηκαν πληροφορίες. Ομάδα 11 Εξωραϊσμοί εγγράφου Μέλη Ομάδας Ανάπτυξης Όνομα OA Α. Συμεωνίδης * asymeon@issel.ee.auth.gr Μ. Τσάπανος * michael.tsapanos@issel.ee.auth.gr Κιντσάκης Αθανάσιος 11 kintsaki@auth.gr Μόσχογλου Στέλιος 11 moschoglou@gmail.com Πάπιστας Ιωάννης 11 iapap1990@gmail.com Τούμπας Κωνσταντίνος 11 ktoumpas@auth.gr 2

3 Περιεχόμενα Περιεχόμενα... 3 Λίστα Σχημάτων Εισαγωγή Στόχος του εγγράφου Αντικείμενο του λογισμικού Τυπογραφικές Παραδοχές του Εγγράφου Ορισμοί, Ακρωνύμια, Συντομεύσεις Στόχοι Σχεδίασης Αναγνωστικό Κοινό Επισκόπηση Εγγράφου Τρέχουσα Αρχιτεκτονική Λογισμικού Ως προς τον τρόπο επικοινωνίας Ως προς τις συναλλαγές Ως προς την ασφάλεια Προτεινόμενη Αρχιτεκτονική Λογισμικού Αποδόμηση Συστήματος Απεικόνιση Υλικού/Λογισμικού Διαχείριση Μόνιμων Δεδομένων Έλεγχος Πρόσβασης και Ασφάλεια Γενικός έλεγχος λογισμικού Handler Συγχρονισμός στην SQL Οριακές Συνθήκες Εκκίνηση συστήματος Τερματισμός συστήματος Εμφάνιση σφαλμάτων Εμφάνιση σφάλματος στο περιβάλλον του client Εμφάνιση σφάλματος στην επικοινωνία client-server Εμφάνιση σφάλματος στον server Διαχείριση αρνητικής απόκρισης της SQL Προδιαγραφές Τμηματικού Σχεδιασμού (Component Design Specifications) Πρότυπα Σχεδιασμού που υιοθετήθηκαν Δομικά Πρότυπα Πρότυπα Συμπεριφοράς Δημιουργικά Πρότυπα Βιβλιογραφική Επισκόπηση

4 Λίστα Σχημάτων Σχήμα 1 Διακριτοποίηση στόχων σχεδίασης... 8 Σχήμα 2 Μοντέλο client / server...12 Σχήμα 3 Σύνδεση στο internet μέσω δικτύου κινητής τηλεφωνίας...13 Σχήμα 4 ΑΤΜ & Ροή Χρήματος...14 Σχήμα 5 Μηχανές έκδοσης OTP...14 Σχήμα 6 Component Diagram...15 Σχήμα 7 Deployment Diagram...19 Σχήμα 8 Facade Pattern...29 Σχήμα 9 Bridge Pattern

5 1. Εισαγωγή 1.1 Στόχος του εγγράφου Στόχος του παρόντος εγγράφου είναι να προσδιορίσει και να παρουσιάσει, το κατά δυνατόν αναλυτικότερα και συγκεκριμένα, την τελική αρχιτεκτονική που θα ακολουθηθεί στο υπό ανάπτυξη καινοτόμο σύστημα DigiWallet. Στα προηγούμενα έγγραφα ορισμού του συστήματος, χρηστών και λογισμικού αντιστοίχως, έχουμε καταγράψει σε μια γενική μορφή τις απαιτήσεις του. Σε αυτό το σημείο, καλούμαστε να περιγράψουμε αναλυτικά τις παραπάνω απαιτήσεις, αλλά πλέον το σύστημα αποδομείται σε υποσυστήματα. Επιπροσθέτως, θα υπάρξει ανάλυση των υποσυστημάτων. Τοιουτοτρόπως, το σύστημα θα λάβει μια τελική μορφή, τόσο σε επίπεδο λογισμικού, όσο και σε επίπεδο υλικού, μιας και θα προσδιοριστούν ενδελεχώς όλα τα υποσυστήματα που το απαρτίζουν και τα οποία θα διεκπεραιώνουν, σε ένα πλαίσιο ευρύτερης συνεργασίας μεταξύ τους, το προς υλοποίηση σύστημά μας. Οι επιλογές που θα γίνουν ως προς τη δημιουργία και υλοποίηση των υποσυστημάτων επιβάλλεται να είναι σαφείς και τέτοιες, ώστε να καλύπτουν και να ικανοποιούν τους στόχους σχεδίασης, όπως ορίζονται αυτοί στην παράγραφο 1.4. Εδώ, θα πρέπει να τονίσουμε τα χαρακτηριστικά με βάση τα οποία ένα υποσύστημα κρίνεται επαρκές και αποδοτικό. Αυτά είναι: Τμηματικότητα (Separation): Κάθε υποσύστημα είναι σχεδιασμένο έτσι ώστε να εκτελεί διακριτές λειτουργίες, αλλά και να δέχεται (παράγει) συγκεκριμένες, πεπερασμένες, διακριτές εισόδους (εξόδους). Είναι από τα πιο βασικά, λεπτά σημεία της ανάπτυξης και θα πρέπει να δοθεί ιδιαίτερη βαρύτητα στην άψογη τήρηση του συγκεκριμένου κανόνα. Έχοντας ένα σύστημα κατηγοριοποιημένο σε υποσυστήματα που ακολουθούν τη λογική της τμηματικότητας, τα οφέλη που προκύπτουν είναι πολλά. Ανάμεσα σε άλλα, εφόσον κάθε υποσύστημα είναι ανεξάρτητο από τα υπόλοιπα, μπορεί να θεωρηθεί σαν black box και σε περίπτωση εμφάνισης σφάλματος, απαιτείται η επέμβαση μόνο στο συγκεκριμένο τμήμα. Επιπλέον, η λογική αυτή συμβάλλει στην εύκολη επεκτασιμότητα του συστήματος, καθώς τυχόν βελτιώσεις μπορούν να εφαρμοστούν μεμονωμένα, αλλά και να αναληφθούν από ξεχωριστές ο- μάδες λογισμικού. Top-down σχεδιασμός: Πέρα της διαχώρισης του συστήματος σε υποσυστήματα, θα πρέπει να λάβουμε σίγουρα υπόψη ότι και κάθε υποσύστημα αποδομείται σε υπομονάδες. Μια υπομονάδα είναι ένα συστατικό στοιχείο του (υπο)συστήματος, που παρέχει μια ή περισσότερες υπηρεσίες σε άλλες υπομονάδες και χρησιμοποιεί υπηρεσίες οι οποίες παρέχονται από άλλες υπομονάδες. Καθώς ξεκινούμε την ανάπτυξη του υποσυστήματος, καλό θα είναι να ακολουθείται η λογική του top-down design, όπου αρχικά, στο top μέρος, βρίσκονται οι υπομονάδες γενικής φύσεως και καθώς κατεβαίνουμε προς τα κάτω, στο down μέρος, οι υπομονάδες ειδικότερης φύσεως. Ασφαλώς επιτρέπεται και προτρέπεται η επικοινωνία μεταξύ των υπομονάδων. Αφαιρετικότητα (Abstraction): Αφορά την απλοποίηση της περιγραφής μιας εφαρμογής του πραγματικού κόσμου (real world) στις (προγραμματιστικές) ενότητες (υποσυστήματα) που την απαρτίζουν. Απαιτούμε λοιπόν μια αναπαράσταση των στοιχείων και της συμπεριφοράς του συστήματος, μοντελοποιώντας το σε επί μέρους ενότητες (υποσυστήματα). Αυτά τα υ- ποσυστήματα οφείλουν να είναι καλώς ονομασμένα (well named). Επίσης, θα πρέπει να είναι συνεκτικά (coherent). Δηλαδή, η αφαίρεση πρέπει να περιέχει ένα σχετικό σύνολο των ιδιοτήτων και συμπεριφορών που έχει νόημα από τη σκοπιά του χρήστη. Έπειτα, θα πρέπει να είναι ακριβή (accurate). Δηλαδή, η αφαίρεση πρέπει να περιέχει μόνο τα χαρακτηριστικά και τη συμπεριφορά που καθορίζονται από τον φορέα που διαμορφώθηκε. Δε θα πρέπει να δίνονται στα υποσυστήματα εξουσίες και ικανότητες πέραν των αρμοδιοτήτων τους. Επίσης, 5

6 θα πρέπει να είναι μινιμαλιστικά (minimal). Δηλαδή, να περιέχουν μόνο τις πληροφορίες (data) που είναι απαραίτητες. Τέλος, θα πρέπει να είναι ολοκληρωμένα (complete). Θα πρέπει δηλαδή το κάθε υποσύστημα να διαθέτει όλα εκείνα τα απαραίτητα χαρακτηριστικά, ώστε να εκτελεί τις λειτουργίες βάσει του οποίου ορίστηκε. Συνθετικότητα (Composition): Είναι η διαδικασία του φτιάχνεις σύνθετα, ολόκληρα συστήματα, συνενώνοντας απλούστερα κομμάτια (στην προκειμένη περίπτωση υποσυστήματα). Η συνθετικότητα, θα πρέπει να διέπεται από συσσωμάτωση (aggregation). Δηλαδή, μόνο το ολικό σύστημα να είναι ορατό και προσβάσιμο. Τέλος, να υπάρχει συσχέτιση (association). Αυτό δε σημαίνει ότι το ένα υποσύστημα επεμβαίνει στις δουλειές του άλλου. Συνεχίζουν να είναι ανεξάρτητα. Απλώς, οι είσοδοι/έξοδοι του ενός μπορούν να χρησιμοποιηθούν αντίστοιχα σαν είσοδοι/έξοδοι του άλλου. Οι υπόλοιποι στόχοι του εγγράφου αποσκοπούν στην περιγραφή διαφόρων άλλων μερών και διαδικασιών του συστήματος, που δεν έχουν περιγραφεί λεπτομερώς ή δεν έχουν περιγραφεί καθόλου στα προηγούμενα στάδια της σχεδίασης. Τέτοια παραδείγματα είναι, μεταξύ άλλων, η καταγραφή οριακών συνθηκών, ο αυστηρός προσδιορισμός ασφαλείας του συστήματος, κ.ά. Τελικώς, με την ολοκλήρωση της όλης διαδικασίας που περιγράφεται στο παρόν έγγραφο αλλά και σαφώς με το συνδυασμό του με τα προηγούμενα έγγραφα, το σύστημα θα είναι έτοιμο προς ανάπτυξη. Περαιτέρω πληροφορίες σχετικά με το τι πραγματεύεται κάθε κεφάλαιο και ενότητα, αλλά και τους στόχους που αυτά καλύπτουν, μπορούν να βρεθούν στην επισκόπηση του εγγράφου, στην παράγραφο Αντικείμενο του λογισμικού Αντικείμενο του έργου είναι η δημιουργία ενός συστήματος διεκπεραίωσης συναλλαγών, ώστε μακροπρόθεσμα να αντικαταστήσει πλήρως, από λειτουργική άποψη, τη σημερινή φυσική μορφή του χρήματος. Οι συναλλαγές που λαμβάνουν χώρα σήμερα με τη μορφή φυσικού χρήματος αποτελούν κατά κανόνα ανώνυμες συναλλαγές. Αν και οι ανώνυμες συναλλαγές προσφέρουν μεγάλη ευελιξία, αποτελούν και τη μεγαλύτερη πληγή του χρηματοπιστωτικού συστήματος. Στην κατηγορία τους υπάγεται σχεδόν το σύνολο των περιπτώσεων φοροδιαφυγής, λαθρεμπορίου και παραοικονομίας. Σε μια χώρα όπως η Ελλάδα, όπου η φοροδιαφυγή και η παραοικονομία φαντάζουν ανεξέλεγκτα προβλήματα, το παραπάνω σύστημα αποτελεί μια οριστική και ριζοσπαστική λύση. Κάθε συναλλαγή όντας επώνυμη και καταγραμμένη στη βάση δεδομένων του συστήματος θα «χτίζει» το οικονομικό προφίλ του κάθε χρήστη. Τα δεδομένα αυτά (ιστορικό συναλλαγών) αποτελούν ιδιοκτησία του χρήστη και είναι αυστηρώς ορατά μόνο σε αυτόν. Παρόλα αυτά μια γενική και συνολική εικόνα του κάθε χρήστη, δηλαδή τα σύνολα εισερχομένων και εξερχομένων ποσών θα αναφέρονται στην εφορεία για διαπίστωση τυχόν σημαντικών αποκλίσεων από τα δηλωθέντα στοιχεία στην φορολογική δήλωση. Με τον τρόπο αυτό η φοροδιαφυγή θα είναι σχεδόν αδύνατη καθώς δεν θα μπορεί να αποκρύψει κάποιος τα εισοδήματα που λαμβάνει όπως και επίσης να δικαιολογήσει τα έξοδα του αν αυτά υπερβαίνουν κατά πολύ τα εισοδήματα που δηλώνει. Επίσης, αντιμετωπίζεται αποτελεσματικά κάθε μορφή παραοικονομίας καθώς στην περίπτωση αυτή έχουμε να κάνουμε με μια τεράστια αγορά χρήματος η οποία εκ φύσεως της έχει να κάνει με παράνομες/εγκληματικές οικονομικές συναλλαγές. Τα ποσά που διακινούνται στην αγορά αυτή είναι μεγάλα και θα είναι αδύνατο να δικαιολογηθούν από τους εμπλεκομένους. 6

7 Καταργώντας την φυσική υπόσταση του χρήματος γίνεται αδύνατη και η απώλεια ή η καταστροφή του. Σε περίπτωση απώλειας της κάρτας συναλλαγών θα είναι δυνατή η ακύρωσή της και η επιστροφή των χρημάτων που ήταν φορτωμένα σε αυτή πίσω στο λογαριασμό του χρήστη. Επίσης, σε περίπτωση κλοπής της κάρτας με άμεση ακύρωσή της θα είναι αδύνατη η χρήση της. 1.3 Τυπογραφικές Παραδοχές του Εγγράφου Το κείμενο του εγγράφου τούτου είναι γραμμένο με γραμματοσειρά Calibri, μεγέθους 11pt. Οι οδηγίες και οι παρατηρήσεις σημειώνονται με αγκύλες (<>). Οι τίτλοι των κεφαλαίων έχουν έντονη (bold) γραμματοσειρά Calibri, μεγέθους 18pt, ενώ των εσωτερικών ενοτήτων έχουν ίδια γραμματοσειρά, μεγέθους 14pt. Οι λεζάντες των σχημάτων έχουν γραμματοσειρά Times New Roman, πλάγια γραφή (italic), μεγέθους 10pt. Οι αναφορές σε μη λειτουργικές απαιτήσεις (ΜΛΑ-xx) είναι συντομεύσεις προς το έγγραφο των απαιτήσεων λογισμικού. Όπου κρίνεται απαραίτητο, οι αγγλικές μεταφράσεις διαφόρων τεχνικών όρων δίνονται μέσα σε παρένθεση μετά τον αντίστοιχο ελληνικό. 1.4 Ορισμοί, Ακρωνύμια, Συντομεύσεις Στο έγγραφο χρησιμοποιήθηκαν τα παρακάτω ακρωνύμια και συντομεύσεις: ΟΑ Ομάδα Ανάπτυξης DB Βάση Δεδομένων (DataBase) GUI Graphical User Interface API Application Programming Interface Component Diagram Διάγραμμα Τμημάτων Deployment Diagram Διάγραμμα Ανάπτυξης ΠΠ Πίνακας Πρόσβασης CP Component Packet Server Διακομιστής Client Πελάτης Design Pattern Δομικό Πρότυπο σελ. Σελίδα Del. x Deliverable x ΜΛΑ-xx Μη Λειτουργική Απαίτηση xx Ver. x.x. Version x.x Σχ. - xx Σχήμα - xx 1.5 Στόχοι Σχεδίασης Οι στόχοι σχεδίασης προέκυψαν ύστερα από προσεκτική, αναλυτική μελέτη των μη λειτουργικών απαιτήσεων (ΜΛΑ) που περιγράφηκαν στο δεύτερο έγγραφο Απαιτήσεις Λογισμικού. Σε αυτό το σημείο, προχωρούμε στη διακριτοποίηση των στόχων σχεδίασης, ανάλογα με το πού αυτοί απευθύνονται. Συγκεκριμένα, αποφασίσαμε να κάνουμε τη διαχώριση στόχων στις εξής κατηγορίες: Σχεδιασμού (Design) Run-Time (κατά τη διάρκεια διεπαφής του χρήστη με το πρόγραμμα) 7

8 Συστήματος (System) Χρήστη (User) Για περαιτέρω διευκρίνιση και κατανόηση, ακολουθούν τα παρακάτω διαγράμματα που ορίζουν τις άνωθεν κατηγορίες και τα χαρακτηριστικά που τις διέπουν. Σχεδιασμού Εννοιολογική Ακεραιότητα Συντηρησιμότητα Επαναχρησιμοποίηση Run-Time Διαθεσιμότητα Διαλειτουργικότητα Διαχειρισιμότητα Αποδοτικότητα Αξιοπιστία Επεκτασιμότητα Ασφάλεια Σύστημα Υποστήριξη Ελεγξιμότητα Χρήστης Χρηστικότητα Σχήμα 1 Διακριτοποίηση στόχων σχεδίασης Βάσει αυτών των κατηγοριών λοιπόν, θα έχουμε από την πλευρά του Σχεδιασμού: Εννοιολογική Ακεραιότητα (Conceptual Integrity): Ορίζει τη συνέχεια και συνοχή της όλης σχεδίασης. Αυτή περιλαμβάνει τον τρόπο με την οποία τα υποσυστήματα σχεδιάζονται, αλλά επίσης, σε επίπεδο κώδικα, παράγοντες όπως στυλ γραφής κώδικα (indentation) και ο- νομάτισμα μεταβλητών (variable naming). Αυτό είναι έκδηλο από τον καθαρό τρόπο γραφής των πακέτων και των κλάσεων στο δεύτερο έγγραφο, Απαιτήσεις Λογισμικού, μιας και είναι αυτές που ουσιαστικά οριοθετούν τις μη λειτουργικές απαιτήσεις, όπως π.χ. το πακέτο που έχει σχέση με αντικείμενα ελέγχου. Συντηρησιμότητα (Maintainability): Είναι η δυνατότητα του συστήματος να υποβάλλεται σε αλλαγές με ένα σχετικά βαθμό ευκολίας. Αυτές οι αλλαγές θα έχουν επίδραση στα υποσυστήματα, τις υπηρεσίες, τα γραφικά περιβάλλοντα, κ.λπ., καθώς προσθέτουμε ή αλλάζουμε λειτουργίες, διορθώνουμε λάθη, ή εφαρμόζουμε νέες απαιτήσεις τεχνολογικές, ή και του 8

9 πελάτη. Ο συνοπτικός και αντικειμενοστραφής τρόπος με τον οποίο είναι δομημένα όλα τα πακέτα, κλάσεις, συναρτήσεις του συστήματος, συμβάλλουν προς αυτή την κατεύθυνση. Περιλαμβάνεται μέσα στη ΜΛΑ-17. Επαναχρησιμοποίηση (Reusability): Ορίζει τη δυνατότητα τα υποσυστήματα και οι υποδομές να είναι κατάλληλα για την ανάπτυξη άλλων εφαρμογών ή άλλων σεναρίων χρήσης, διαφορετικών από τα ήδη υπάρχοντα. Η επαναχρησιμοποίηση πρέπει να τονιστεί ότι ελαχιστοποιεί τη διπλή γραφή υποσυστημάτων ή υποδομών (δηλαδή υποσυστημάτων ή υποδομών που εκτελούν την ίδια διαδικασία) και μειώνει τον χρόνο υλοποίησης. Περιλαμβάνεται στημλα-6, ΜΛΑ-7, ΜΛΑ-8, ΜΛΑ-9, ΜΛΑ-10, ΜΛΑ-11, ΜΛΑ-12. Από την πλευρά του Run-Time, θα έχουμε: Διαθεσιμότητα (Availability): Ορίζει τη χρονική διάρκεια κατά την οποία το σύστημα είναι σε κατάσταση λειτουργίας. Μπορεί να μετρηθεί σαν ποσοστό ως προς τον χρόνο κατά τον ο- ποίο το σύστημα είναι εκτός λειτουργίας. Η διαθεσιμότητα, όπως είναι λογικό, επηρεάζεται άμεσα από λάθη στο σύστημα, προβλήματα στις εγκαταστάσεις, κακόβουλες επιθέσεις, υ- περβολικό φόρτο. Επειδή το DigiWallet είναι μια άκρως ευαίσθητη εφαρμογή, της οποίας η διαθεσιμότητα θα πρέπει να είναι πάντα και άμεσα διαθέσιμη, στις ΜΛΑ δόθηκε ιδιαίτερη βαρύτητα σε αυτόν τον τομέα. Περιλαμβάνεται μέσα στις ΜΛΑ-1, ΜΛΑ-3, ΜΛΑ-4, ΜΛΑ-12, ΜΛΑ-14, ΜΛΑ-15, ΜΛΑ-16. Διαλειτουργικότητα (Interoperability): Είναι η δυνατότητα που έχει ένα σύστημα να λειτουργεί επιτυχώς επικοινωνώντας και ανταλλάσσοντας πληροφορίες με άλλα, εξωτερικά συστήματα που έχουν υλοποιηθεί και τρέχουν από ξένες εταιρείες. Ένα τέτοιο σύστημα βοηθάει στην ανταλλαγή αλλά και επαναχρησιμοποίηση πληροφοριών εσωτερικά του συστήματος, αλλά και εξωτερικά αυτού. Περιλαμβάνεται στις ΜΛΑ-17, ΜΛΑ-13, ΜΛΑ-11. Διαχειρισιμότητα (Manageability): Ορίζει πόσο εύκολο είναι για τους διαχειριστές του συστήματος να το διαχειριστούν / ελέγξουν, χρησιμοποιώντας τα μέσα ελέγχου συστήματος που τους δίνονται στη διάθεσή τους από το ίδιο το σύστημα. Περιλαμβάνεται στη ΜΛΑ-17. Αποδοτικότητα (Performance): Είναι ένας δείκτης ανταπόκρισης του συστήματος στο να ε- κτελεί κάθε σενάριο χρήσης του μεταξύ ενός συγκεκριμένου χρονικού διαστήματος. Μπορεί να μετρηθεί βάσει της χρονοκαθυστέρησης (latency) ή ρυθμαπόδοσης (throughput). Χρονοκαθυστέρηση είναι ο χρόνος που μεσολαβεί μέχρι τελικώς να πραγματοποιηθεί το σενάριο χρήσης, από τη στιγμή που το επέλεξε ο χρήστης. Ρυθμαπόδοση είναι ο αριθμός των σεναρίων χρήσης που λαμβάνουν χώρα σε μια συγκεκριμένη χρονική περίοδο. Περιλαμβάνεται στις ΜΛΑ-1, ΜΛΑ-2, ΜΛΑ-8, ΜΛΑ-10, ΜΛΑ-11, ΜΛΑ-12. Αξιοπιστία (Reliability): Είναι η ιδιότητα του συστήματος να παραμένει σε λειτουργία με την πάροδο του χρόνου, ανεξαρτήτως απρόοπτων γεγονότων. Η αξιοπιστία μετράται σαν την πιθανότητα ένα σύστημα να μη σταματήσει τις εκτελούμενες λειτουργίες του μέσα σε μια συγκεκριμένη χρονική περίοδο. Περιλαμβάνεται στις ΜΛΑ-14, ΜΛΑ-15, ΜΛΑ-16. Επεκτασιμότητα (Scalability): Είναι η ιδιότητα του συστήματος να διαχειρίζεται αυξήσεις στο φόρτο εργασίας του χωρίς επιδράσεις πάνω σε αυτό ή η δυνατότητά του να είναι άμεσα ε- πεκτάσιμο, με την προσθήκη νέων λειτουργιών. Περιλαμβάνεται στις ΜΛΑ-17, ΜΛΑ-12, ΜΛΑ-11, ΜΛΑ-10. Ασφάλεια (Security): Είναι η δυνατότητα του συστήματος να αποφεύγει και να εμποδίζει κακόβουλες ή ανεπιτήδευτες δράσεις έξω από τα πλαίσια της προσχεδιασμένης χρήσης. Ε- πίσης, εμποδίζει την διαρροή ή απώλεια πληροφοριών από το σύστημα. Ένα ασφαλές σύστημα στοχεύει στην προστασία των πόρων και εμποδίζει μη εξουσιοδοτημένη τροποποίηση πληροφοριών. Περιλαμβάνεται στις ΜΛΑ-3, ΜΛΑ-4, ΜΛΑ-5. 9

10 Από την πλευρά του Συστήματος, θα έχουμε: Υποστήριξη (Supportability): Είναι η δυνατότητα του συστήματος να παρέχει βοηθητικές πληροφορίες, ώστε να αναγνωριστούν και να αντιμετωπιστούν προβλήματα, όταν αυτά παρουσιάζονται και αποτελούν τροχοπέδη στην ομαλή λειτουργία του. Τη συγκεκριμένη δυνατότητα την παρέχει το πακέτο που αφορά σε αντικείμενα ελέγχου του συστήματος. Ελεγξιμότητα (Testability): Είναι η δυνατότητα του συστήματος να δημιουργεί κριτήρια ε- λέγχου για το ίδιο το σύστημα και τα υποσυστήματά του και να εκτελεί αυτούς τους ελέγχους, ώστε να δει αν πληρούνται τα συγκεκριμένα κριτήρια. Η ελεγξιμότητα κατά βάση βοηθάει στην απομόνωση και σταδιακή μείωση των λαθών στο σύστημα, με ένα αρκετά αποδοτικό τρόπο. Όπως και προηγούμενα, τη συγκεκριμένη δυνατότητα την παρέχει το πακέτο που αφορά σε αντικείμενα ελέγχου του συστήματος. Τέλος, από την πλευρά του Χρήστη, θα έχουμε: Χρηστικότητα (Useability): Ορίζει πόσο καλά το σύστημα συναντά τις προσδοκίες και απαιτήσεις του χρήστη ή καταναλωτή όντας διαισθητικό (intuitive), εύκολο στη διαχείρισή του τόσο σε τοπικό όσο και σε παγκόσμιο επίπεδο, παρέχοντας εύκολη και αποδοτική πρόσβαση για τα άτομα με ειδικές ικανότητες, συντελώντας τέλος πάντων σε μια γενική καλή χρηστική εμπειρία. Περιλαμβάνεται στις ΜΛΑ-6, ΜΛΑ-7, ΜΛΑ-8, ΜΛΑ-9, ΜΛΑ-10, ΜΛΑ-11, ΜΛΑ Αναγνωστικό Κοινό Το αναγνωστικό κοινό του εγγράφου αποτελείται από τις εξής κατηγορίες: Οι μηχανικοί λογισμικού που είναι υπεύθυνοι για την υλοποίηση του έργου τόσο στο παρών στάδιο της περιγραφής των απαιτήσεων λογισμικού όσο και σε μετέπειτα στάδια. Ο πελάτης, σε περίπτωση που διαθέτει τις απαραίτητες γνώσεις αλλά και την διάθεση, ώστε να επιβεβαιώσει την ορθή υλοποίηση του έργου σύμφωνα με τις παρούσες αλλά και τις μελλοντικές πιθανές ανάγκες του. Οι μηχανικοί λογισμικού αλλά και οι προγραμματιστές που θα κληθούν να αναπτύξουν τον τελικό κώδικα της εφαρμογής Οι μηχανικοί λογισμικού και οι προγραμματιστές που θα είναι υπεύθυνοι για την υποστήριξη και συντήρηση του συστήματος. Άλλες ομάδες ανάπτυξης που θα αναλάβουν να τροποποιήσουν το παρών έργο στο μέλλον ή να υλοποιήσουν παρόμοια στη φύση συστήματα τα οποία ενδέχεται να χρησιμοποιούν ως εξωτερικό σύστημα το παρών. 1.7 Επισκόπηση Εγγράφου Αρχικώς, στην εισαγωγική ενότητα, περιγράφεται το αυτό κάθε αυτό αντικείμενο του λογισμικού καθώς και οι στόχοι σχεδίασης, όπως αυτοί καθορίστηκαν και διαμορφώθηκαν από τα προηγούμενα έγγραφα Απαιτήσεις Χρηστών και Απαιτήσεις Λογισμικού. Επιπλέον, παρέχονται περαιτέρω πληροφορίες σχετικά τους στόχους και το ευρύτερο αναγνωστικό κοινό. Τέλος, αναφέρονται και οι τυπογραφικές παραδοχές του εγγράφου. 10

11 Στη δεύτερη ενότητα, εξαιτίας της απουσίας αντίστοιχων ή παρόμοιων λογισμικών, επιχειρείται μια ανάλυση των υπαρχόντων υποσυστημάτων που εν μέρει (κι όχι ολικά) απαρτίζουν το DigiWallet. Επίσης, αναλύεται λακωνικά, αλλά ταυτοχρόνως περιεκτικά, η κύρια αρχιτεκτονική που ακολουθείται για την ανάπτυξη του συστήματός μας (πελάτη / διακομιστή client / server). H ανάλυση γίνεται μεθοδικά και σταδιακά, ώστε οι αναγνώστες του εγγράφου να κατανοήσουν πλήρως τις αρχές λειτουργίας αυτών των συστημάτων και να εμπεδώσουν τον τρόπο με τον οποίο τελικά το σύστημα τους τροφοδοτεί με τις υπηρεσίες που αυτοί απαιτούν και οι οποίες έχουν αναλυθεί ενδελεχώς στα προηγούμενα έγγραφα και συγκεκριμένα στο έγγραφο Απαιτήσεις Χρηστών. Στην επόμενη ενότητα, περιγράφεται το επί μέρους μοντέλο σχεδίασης του συστήματος. Συγκεκριμένα, προσδιορίζεται πλήρως η αποδόμηση του συστήματος στα υποσυστήματά του αλλά και αναλύεται επακριβώς ο τρόπος με τον οποίο αυτά συνδέονται μεταξύ τους και αλληλεπιδρούν, ώστε να διασφαλιστεί η απρόσκοπτη λειτουργία του DigiWallet. Επιπλέον, περιγράφεται ο τρόπος αποθήκευσης των δεδομένων στη βάση, οι επιλογές ασφαλείας, τα δικαιώματα των χρηστών, αλλά και οι συνθήκες αρχικοποίησης και τερματισμού του συστήματος και οι ενέργειες που πραγματοποιούνται σε περίπτωση εμφάνισης σφαλμάτων. Τέλος, στην τέταρτη ενότητα, που είναι και η τελευταία, αφορά το κομμάτι των προδιαγραφών του τμηματικού σχεδιασμού του λογισμικού και περιγράφει την τελική αποδόμηση των υποσυστημάτων σε πακέτα καθώς και την οργάνωση του κώδικα. Η περιγραφή επιχειρεί να κάνει μια επισκόπηση του κάθε πακέτου, τις εξαρτήσεις του με τα υπόλοιπα πακέτα, καθώς και την ενδεχόμενη χρήση του, στα διαφορετικά σενάρια χρήσης, όπως έχουν αναλυθεί στα προηγούμενα έγγραφα. 11

12 2. Τρέχουσα Αρχιτεκτονική Λογισμικού Στην παρούσα ενότητα, οφείλουμε να παρουσιάσουμε άλλες, ήδη υπάρχουσες αρχιτεκτονικές πάνω στις οποίες στηρίζεται η ανάπτυξη και υλοποίηση του συστήματος DigiWallet. Καθότι το υπό ανάπτυξη σύστημα DigiWallet είναι ρηξικέλευθο, θα αρκεστούμε στο να παρουσιάσουμε τις ήδη υπάρχουσες, μεμονωμένες αρχιτεκτονικές, οι οποίες σε συνδυασμό μεταξύ τους αλλά και με τις νέες, υπό υλοποίηση, θα απαρτίσουν το ολικό, τελικό εγχείρημα. Ως έχει καλώς οριστεί στα προηγούμενα έγγραφα, Απαιτήσεις Χρηστώ και Απαιτήσεις Λογισμικού, ανάμεσα σε άλλα, συστήματα τα οποία χρησιμοποιούνται είναι τα αυτόματα τραπεζικά συστήματα συναλλαγών (ATM s), τα δίκτυα κινητής τηλεφωνίας νέας γενιάς (3G), οι καινοτόμες υπηρεσίες εξυπηρέτησης τραπεζικών συναλλαγών μέσω διαδικτύου (e-banking), τα ειδικά περιβάλλοντα διεπαφής χρηστών με τις κεντρικές μονάδες μέσω φυλλομετρητών (browsers), τα ειδικά μηχανήματα έκδοσης OTP (One Time Password, Κωδικός Μιας Χρήσης) των τραπεζών. Παρακάτω, θα ακολουθήσει εκτενής αναφορά στα συστήματα αυτά, καθώς και στον τρόπο με τον οποίο συνεργάζονται στο υπό ανάπτυξη σύστημα DigiWallet. 2.1 Ως προς τον τρόπο επικοινωνίας Για τον τρόπο επικοινωνίας χρησιμοποιείται το μοντέλο πελάτη / διακομιστή (client / server), το οποίο και διαχωρίζει τις εργασίες μεταξύ των παρόχων των πληροφοριών και αιτημάτων, που ονομάζονται διακομιστές (servers) και σε αυτούς που αιτούνται τις πληροφορίες, τους πελάτες (clients). Οι διακομιστές και πελάτες επικοινωνούν μεταξύ τους μέσω του διαδικτύου. Ο διακομιστής, υπενθυμίζεται ότι είναι ένα κεντρικό μηχάνημα που διαμοιράζεται τις πληροφορίες που διαθέτει με τους πελάτες. Αντίθετα, οι πελάτες, δε διαμοιράζονται μέρη των πόρων τους. Τους δίνεται ωστόσο η δυνατότητα να αιτούνται περιεχόμενα από τον εκάστοτε διακομιστή. Εξαιτίας τούτου, οι πελάτες θέτουν σε εκκίνηση ειδικές συνεδρίες (sessions) προκειμένου να επικοινωνήσουν με τους διακομιστές, οι οποίοι μετ η σειρά τους αναμένουν εισερχόμενα αιτήματα. Ο διακομιστής παρέχει μια υπηρεσία σε έναν ή περισσότερους πελάτες, οι οποίοι πριν έχουν προχωρήσει στην αντίστοιχη αίτηση της συγκεκριμένης υπηρεσίας. Μεταξύ άλλων, το μοντέλο πελάτη / διακομιστή διαθέτει εκ φύσεως υπηρεσίες όπως πρόσβαση στο διαδίκτυο και στη βάση δεδομένων. Αυτές είναι απαραίτητες, καθώς οι χρήστες του DigiWallet που απαιτούν πρόσβαση στο λογαριασμό τους μέσω του υπολογιστή τους, χρησιμοποιούν έναν φυλλομετρητή, ώστε να στείλουν κάποια αίτηση σε έναν απομακρυσμένο διακομιστή. Εν συνεχεία, η συγκεκριμένη αίτηση, που έχει φθάσει πλέον στο διακομιστή, με τη σειρά της, μπορεί να απαιτήσει πρόσβαση στο ανεξάρτητο, εξωτερικό σύστημα διαχείρισης της βάσης δεδομένων, στέλνοντας ένα αίτημα λήψης πληροφοριών για κάποια συγκεκριμένη συναλλαγή π.χ., που βρίσκεται αποθηκευμένη στη βάση δεδομένων. Εφόσον ολοκληρωθεί η απόκτηση της πληροφορίας για τη συγκεκριμένη συναλλαγή, το αίτημα επιστρέφει στο διακομιστή και αυτός μετ η σειρά του επιστρέφει το επιθυμητό αποτέλεσμα στον εκάστοτε αιτούντα χρήστη. Μεταξύ άλλων, προκειμένου να επιτευχθεί όλη αυτή η διαδικασία, χρησιμοποιούνται πρωτόκολλα όπως το TCP, HTTP, DNS, SMTP. Μια σχηματική αναπαράσταση του τι ακριβώς συμβαίνει φαίνεται παρακάτω: Σχήμα 2 Μοντέλο client / server 12

13 Φυσικά, στο συγκεκριμένο τομέα, πρέπει να συμπεριλάβουμε υπόψη, πέρα από τα κλασικά πρωτόκολλα που αναφέρθηκαν για την επικοινωνία σε ένα κλασικό δίκτυο τηλεπικοινωνιών και τα νέα, έξυπνα δίκτυα κινητής τηλεφωνίας, τα λεγόμενα 3G. Στα συγκεκριμένα δίκτυα, είναι εφικτή η σύνδεση μέσω της κινητής συσκευής στο διαδίκτυο σε ταχύτητες αντίστοιχες της DSL σύνδεσης. Αυτό από μόνο του, εγγυάται την απρόσκοπτη διεκπεραίωση των συναλλαγών που θα λαμβάνουν χώρα στο σύστημα DigiWallet μέσω των κινητών συσκευών. Παρακάτω, παρουσιάζεται διαγραμματικά ο τρόπος σύνδεσης του κινητού τηλεφώνου στο διαδίκτυο (internet): Σχήμα 3 Σύνδεση στο internet μέσω δικτύου κινητής τηλεφωνίας Ουσιαστικά, εφόσον ο ενδιαφερόμενος χρήστης βρίσκεται εντός περιοχής κάλυψης του δικτύου (στην εικόνα με τους ομόκεντρους κύκλους ορίζεται η περιοχή κάλυψης), κάθε αίτηση του στέλνεται μέσω των κεραιών λήψης, οι οποίες συνδέονται ενσύρματα κατόπιν με το κεντρικό δίκτυο, στο διαδίκτυο. 2.2 Ως προς τις συναλλαγές Όπως έχει αναφερθεί και προηγούμενα, το σύστημα DigiWallet θα πρέπει να είναι σε θέση να διεκπεραιώνει συναλλαγές με τα ήδη υπάρχοντα διαθέσιμα τραπεζικά συστήματα. Κύριο μέρος των συναλλαγών μέσω τραπεζικών συστημάτων αποτελούν τα αυτοματοποιημένα μηχανήματα συναλλαγών, γνωστά με τη συντομογραφία ATM. Ο ενδιαφερόμενος χρήστης, ο οποίος θα έχει στη διάθεσή του μια κάρτα αντίστοιχη αυτής της γνωστής Visa, θα μπορεί με την κάρτα του να πραγματοποιεί συναλλαγές από οποιοδήποτε ATM, οποιασδήποτε τράπεζας. Οι τράπεζες, θα πρέπει να διασυνδέσουν τα ATM s που διαθέτουν, μέσω ασφαλούς σύνδεσης στο διαδίκτυο, με τους διακομιστές του DigiWallet, ώστε να μπορούν να φέρονται εις πέρας πάσης φύσεως συναλλαγές. Διαγραμματικά, το πώς δηλαδή θα γίνεται η ροή πληροφοριών, συναλλαγών και διάφορων χρηματικών ποσών μέσω διαφορετικών λογαριασμών στο DigiWallet, επιχειρείται να παρουσιαστεί στο παρακάτω διάγραμμα. Ουσιαστικά, κάθε χρήστης συνδέεται στο εκάστοτε τοπικό ATM, το οποίο μετ η σειρά του συνδέεται στον κεντρικό διακομιστή του DigiWallet κι ο οποίος με τη σειρά του αναλαμβάνει να προωθήσει τη ροή του χρήματος πίσω, στον επιθυμητό χρήστη. Απαραίτητη προϋπόθεση για όλα αυτά, είναι, όπως αναφέρθηκε και νωρίτερα, μια ασφαλής, γρήγορη, αξιόπιστη σύνδεση στο διαδίκτυο. 13

14 Σχήμα 4 ΑΤΜ & Ροή Χρήματος 2.3 Ως προς την ασφάλεια Όπως αναφέρθηκε και στην εισαγωγή της ενότητας, για λόγους ασφαλείας, σαν επιπλέον μέτρο, οι χρήστες του DigiWallet ενδέχεται να επιθυμούν την έκδοση OTP (One Time Password, Κωδικό Μιας Χρήσης) για την είσοδό τους στο σύστημα. Αυτό, είναι ήδη γνωστή μεθοδολογία και εφαρμόζεται κατά κόρον στις περισσότερες τράπεζες. Την έκδοση του συγκεκριμένου OTP θα την αναλαμβάνει μια μικρή, φορητή συσκευή, αντίστοιχη αυτής που χρησιμοποιούν οι τράπεζες. Σε διαφορετική περίπτωση, ο χρήστης μπορεί να επιλέξει την αποστολή του OTP στο κινητό του. Μια αναπαράσταση των συγκεκριμένων μηχανημάτων μπορείτε να παρατηρήσετε στο παρακάτω σχήμα: Σχήμα 5 Μηχανές έκδοσης OTP 14

15 3. Προτεινόμενη Αρχιτεκτονική Λογισμικού 3.1 Αποδόμηση Συστήματος Όσον αφορά την αποδόμηση του συστήματος DigiWallet αυτή χωρίζεται σε τρία βασικά υποσυστήματα. Αυτά είναι τα υποσυστήματα Client, Server και Database τα οποία συνδέονται με βάση τα πρότυπα facade και bridge. Στο παρακάτω διάγραμμα φαίνονται διαγράφονται αναλυτικά τα υποσυστήματα αυτά και οι μεταξύ τους συνδέσεις. Στη συνέχεια αναλύεται ο διαχωρισμός στα παρακάτω υποσυστήματα και επεξηγούνται αναλυτικότερα οι λειτουργίες τους. Σχήμα 6 Component Diagram Client Με τον όρο Client αναφερόμαστε σε οποιοδήποτε τρόπο με τον οποίο έρχεται ο χρήστης σε επαφή με το σύστημα. Οι διαχειριστές του συστήματος επικοινωνούν με το σύστημα συνδεόμενοι σε αυτό μέσω των υπολογιστών εργασίας τους (τερματικών) μετά από Authorized Log in. Οι απλοί ή οι εταιρικοί χρήστες συνδέονται αντίστοιχα στο σύστημα από οποιονδήποτε υπολογιστή ή κινητό τηλέφωνο με χρήση των υπηρεσιών Internet και mobile banking που έχουν περιγραφεί έγγραφο απαιτήσεις χρηστών. Υπάρχουν και αυτοματοποιημένες συνδέσεις των χρηστών στο σύστημα οι οποίες πραγματοποιούνται μέσω των τραπεζικών ΑΤΜ ή και κάθε φορά γίνεται χρήση της DigiCard. Το υποσύστημα Client αποτελείται μόνο από το πακέτο GUI το οποίο περιέχει τις συναρτήσεις που δημιουργούν το γραφικό περιβάλλον μέσω του οποίου ο χρήστης αλληλεπιδρά με το σύστημα. Ο κώδικας που αποτελεί τις κλάσεις αυτές τρέχει τοπικά στο εκάστοτε μηχάνημα και αναλαμβάνει την απεικόνιση με γραφικό τρόπο στην οθόνη του χρήστη το περιβάλλον εργασίας του συστήματος. Τα αιτήματα του χρήστη μεταβιβάζονται στο υποσύστημα Server όπου γίνεται η επεξεργασία τους και στη συνέχεια οι απαντήσεις του Server εμφανίζονται στην οθόνη του χρήστη. Server O Server αποτελεί το βασικό υποσύστημα του DigiWallet. Περιέχει τις κλάσεις για την επικύρωση των χρηστών και την εκτέλεση οποιασδήποτε ενέργειας. Επίσης επικοινωνεί με τοπική σύνδεση με την βάση δεδομένων στην οποία γίνεται η καταγραφή όλων των δεδομένων που διαχειρίζεται το σύστημα. 15

16 Αρχικά ο Handler αποτελεί την σύνδεση μεταξύ του χρήστη και του συστήματος και συνεπώς αναλαμβάνει την ερμηνεία και δρομολόγηση της εκτέλεσης οποιασδήποτε ενέργειας του χρήστη. Στη συνέχεια απαιτείται επικύρωση κάθε αιτούμενης ενέργειας του χρήστη, διαδικασία που αναλαμβάνει το πακέτο Authorization. Μετά την επιτυχή επικύρωση της αιτούμενης ενέργειας ακολουθεί η δρομολόγηση της στο αντίστοιχο πακέτο όπου πραγματοποιείται η εκτέλεση της. Τα πακέτα του Server επικοινωνούν μέσω του πακέτου DB Bridge με την βάση δεδομένων του συστήματος όπου αποθηκεύεται το σύνολο των δεδομένων. Το DB Bridge περιλαμβάνει τις συναρτήσεις που αναλαμβάνουν την αποθήκευση, ανάκτηση και τον συγχρονισμό των δεδομένων από και προς τη βάση δεδομένων του συστήματος. Επιπλέον περιλαμβάνει και τις συναρτήσεις που αναλαμβάνουν το Backup των δεδομένων, διαδικασία που περιγράφεται αναλυτικότερα στην συνέχεια του εγγράφου. Components Authorization Aνήκουν οι συναρτήσεις αυτές των κλάσεων του πακέτου Users που αναλαμβάνουν την σύνδεση και αυθεντικοποίηση των χρηστών στο σύστημα (Log In, Authorization). Είναι σημαντικό να σημειωθεί πως η αυθεντικοποίηση των χρηστών λαμβάνει χώρα μόνο τη στιγμή εισόδου τους στο σύστημα και στη συνέχει παρακάμπτεται η διαδικασία αυτή για τη συνέχεια της χρονικής διάρκειας της συνεδρίας του χρήστη στο σύστημα. Accounts Management Ανήκουν οι κλάσεις του πακέτου Users που επιτρέπουν στον χρήστη, ανάλογα με την κατηγορία χρηστών στην οποία ανήκει, να εκτελέσει τις επιτρεπτές για αυτόν ενέργειες στον λογαριασμό του αλλά και στο ίδιο το σύστημα. Παραδείγματα τέτοιων ενεργειών είναι η τροποποίηση των προσωπικών του ρυθμίσεων και η εμφάνιση των πραγματοποιηθέντων συναλλαγών. Transactions Ανήκουν οι κλάσεις του πακέτου Transactions οι οποίες υλοποιούν τις οικονομικές συναλλαγές στο σύστημα. System Monitoring Ανήκουν οι κλάσεις του πακέτου SystemMonitoring οι οποίες πραγματεύονται την παρακολούθηση της εύρυθμης λειτουργίας του συστήματος και της εξέρευσης και επίλυσης σφαλμάτων. Πρόσβαση σε αυτές έχουν μόνο οι διαχειριστές του συστήματος. External Systems Comm Ανήκουν οι κλάσεις του πακέτου API που αναλαμβάνουν την επικοινωνία του συστήματος με εξωτερικά συστήματα. Database Bridge Ανήκουν οι κλάσεις του πακέτου DataBaseAPI οι οποίες υλοποιούν τις επικοινωνίες του Server με την βάση δεδομένων. Database 16

17 Η βάση δεδομένων του συστήματος αποτελεί εξωτερικό σύστημα ως προς το DigiWallet και αναλαμβάνει την αποθήκευση του συνόλου των δεδομένων που επεξεργάζεται το σύστημα. Επικοινωνεί με τον Server μέσω μια τοπικής σύνδεσης που τηρεί προδιαγραφές ασφαλείας, ταχύτητας και αξιοπιστίας. Θα μπορούσε να θεωρηθεί πως η βάση δεδομένων είναι μέρος του Server αλλά λόγω καλύτερης αποδόμησης και σχεδίασης του συστήματος επιλέχθηκε να διαχωριστεί σε διαφορετικό υποσύστημα. Στο σημείο αυτό είναι αναγκαίο να διασαφηνίσουμε πως λόγο της έκτασης τους συστήματος αλλά και της κατανεμημένης δόμησης του οι έννοιες του server και της Database δεν αναφέρονται σε μεμονωμένα συστήματα αλλά σε ένα γενικότερο σύνολο που αποτελείται από πολλές επιμέρους δομικές μονάδες. 3.2 Απεικόνιση Υλικού/Λογισμικού Το σύστημα DigiWallet έχει πολυάριθμες απαιτήσεις από πλευράς υλικού και συνεργαζόμενων λογισμικών. Η ανάλυση που ακολουθεί παρακάτω χωρίζεται τμηματικά σε τρία μέρη ανάλογα της οπτικής με την οποία παρατηρούμε το σύστημα. Αναλύουμε τις ανάγκες του συστήματος ξεχωριστά για τα τρία υποσυστήματα που το απαρτίζουν (Client, Server, Database). Client Οι χρήστες συνδέονται στο σύστημα μέσω τερματικών (υπολογιστών η γενικότερα συσκευών που διαθέτουν πρόσβαση στο διαδίκτυο). Για να επισκεφθεί και να πλοηγηθεί κάποιος την ιστοσελίδα του DigiWallet δεν απαιτείται να υπάρχει προεγκατεστημένο κάποιο συγκεκριμένο λογισμικό ούτε υπάρχει περιορισμός από πλευράς υλικού. Εξαίρεση αποτελεί η περίπτωση που ο χρήστης επιλέγει την πρόσβαση στο σύστημα μέσω των ειδικών εφαρμογών που έχουν αναπτυχθεί για κινητά τηλέφωνα για τις οποίες θα απαιτείται η προγενέστερη εγκατάσταση τους στη συσκευή. Όσον αφορά την ιδιαίτερη κατηγορία χρηστών των Administrators, αυτοί υπόκειντο σε περαιτέρω περιορισμούς όσον αφορά τη χρήση του συστήματος. Επιτρέπεται η πρόσβαση τους στο σύστημα μόνο από τους υπολογιστές εργασίας του συστήματος (έλεγχος που πραγματοποιείται μέσω ταυτοποίησης MAC address ) και μόνο κατά τις ώρες εργασίας τους. Server Οι Servers του συστήματος αποτελούν υπολογιστικά μηχανήματα υψηλών επιδόσεων που αναλαμβάνουν την διεκπεραίωση όλων των λειτουργιών του συστήματος. Στους Servers συνδέονται οι χρήστες μέσω του διαδικτύου, καταθέτουν τις προς εκτέλεση εντολές και λαμβάνουν τις αντίστοιχες απαντήσεις. Οι Servers επικοινωνούν μεταξύ τους και αλληλοσυμπληρώνουν την λειτουργία τους ανάλογα με τα εκάστοτε δεδομένα φόρτου εργασίας και διαθεσιμότητας ζητούμενων δεδομένων. Το λειτουργικό σύστημα που χρησιμοποιούν οι Servers είναι Linux και η τεχνολογία Webserver Apache. Τα δύο παραπάνω προϊόντα λογισμικού διατίθενται δωρεάν και χαρακτηρίζονται από δοκιμασμένη αξιοπιστία και ωριμότητα. Βάση Δεδομένων Η αποθήκευση των δεδομένων γίνεται στη βάση δεδομένων του συστήματος. Η βάση δεδομένων συνήθως τρέχει συνήθως στο ίδιο μηχάνημα με τον κάθε server και επικοινωνεί άμεσα με αυτόν. Εκτός από τις τοπικές αυτές βάσεις δεδομένων που αναλαμβάνουν την αποθήκευση των δεδομένων του κάθε server υπάρχουν και εξωτερικά σημεία (off site) στα οποία αποθηκεύονται αντίγραφα ασφαλείας των δεδομένων του συνολικού συστήματος. Όσον αφορά την τεχνολογία βάσης δεδομέ- 17

18 νων που χρησιμοποιείται συμβουλευτείτε την επόμενη παράγραφο, 3.3 Διαχείριση Μόνιμων Δεδομένων. Αρχιτεκτονική των Servers/Backup Sites Η σχεδίαση και κατανομή του συστήματος των Servers, των σημείων αποθήκευσης δεδομένων καθώς και των σημείων τήρησης αντιγράφων ασφαλείας δεδομένων (backup sites) δεν μπορεί να περιγραφεί με αυστηρούς κανόνες καθώς επρόκειτο για ένα συνεχώς εξελισσόμενο σύστημα η πορεία του οποίου καθορίζεται από υπάρχουσες και μελλοντικές υποδομές αλλά και πληθυσμιακούς, κοινωνικούς και πολιτικούς παράγοντες. Ωστόσο, μπορούν να θεσπιστούν οι παρακάτω γενικοί κανόνες που καθορίζουν ως ένα βαθμό την δομή του. Το σύστημα είναι οργανωμένο σε σταθμούς (Stations). Κάθε station αποτελείται από ένα WebServer μαζί με μια βάση δεδομένων στην οποία αποθηκεύονται όλα τα τοπικά δεδομένα. Μια ομάδα από stations αποτελεί έναν κόμβο (Node) του συστήματος. Σε κάθε node υπάρχει ένα BackupSite στο οποίο αποθηκεύονται τα δεδομένα όλων των stations που ανήκουν στο node. Τα nodes επικοινωνούν με το MainBackupSite στο οποίο κρατείται αντίγραφο όλων των δεδομένων του συστήματος. Έχει μεριμνηθεί και η ύπαρξη ενός δεύτερου AlternateBackupSite. Κάθε χρήστης κατά κανόνα εξυπηρετείται συνήθως από μια συγκεκριμένη Node του συστήματος. Κατά την είσοδο του λοιπόν στο σύστημα κατευθύνεται στην Node αυτή. Τα κριτήρια βάση των ο- ποίων γίνεται η κατάταξη των χρηστών σε Nodes είναι ως επί το πλείστον πληθυσμιακά/γεωγραφικά. Υπάρχει ένας γενικός Server στον οποίο είναι αποθηκευμένος ένας πίνακας που καταγράφει σε ποιο Node/Station ανήκει κάθε χρήστης. Ο Server αυτός έχει παρόμοια λειτουργία με τους DNS Servers, μόνο που στη δική μας περίπτωση θα ονομάζεται User Name Server (UNS). Με την είσοδο του ο χρήστης επικοινωνεί με τον UNS οπού εκεί διαβάζεται η εγγραφή του στον πίνακα και ανακατευθύνεται στο κατάλληλο Node και Station που του αντιστοιχεί. Στην βέλτιστη περίπτωση ο χρήστης θα εξυπηρετηθεί από το Station εκείνο που έχει τα δεδομένα του καταχωρημένα στην τοπική του βάση δεδομένων. Στην περίπτωση που αυτό δεν είναι εφικτό (λόγω φόρτου του Station, η αδυναμίας του) θα εξυπηρετηθεί από άλλο Station της Node το όποιο θα αντλήσει τα δεδομένα του χρήστη από το κοινό BackupSite όλων των Station της Node. Σε περιπτώσεις συναλλαγών που εμπλέκονται παραπάνω από ένας χρήστες, ακολουθείται η ίδια διαδικασία για κάθε χρήστη ξεχωριστά. Δηλαδή ενημερώνονται τα δεδομένα του πρώτου χρήστη και στη συνέχει αποστέλλονται οι απαραίτητες πληροφορίες στο κατάλληλο Node για την ενημέρωση του επομένου χρήστη. Η τοπολογία του δικτύου των Nodes μεταξύ τους αλλά και των Stations που ανήκουν στο ίδιο Node είναι μορφής δακτυλίου. Ακόμη όμως και στην περίπτωση κατάρρευσης του δακτυλίου το δίκτυο μπορεί να λειτουργήσει και με τοπολογία αστέρα με κοινό σημείο μεταξύ των Nodes το MainBackupSite και μεταξύ των Stations ενός Node το BackupSite. Τα παραπάνω απεικονίζονται και σχηματικά στο παρακάτω διάγραμμα. 18

19 Σχήμα 7 Deployment Diagram 3.3 Διαχείριση Μόνιμων Δεδομένων Όσον αφορά τη βάση δεδομένων του συστήματος καταλήξαμε στην επιλογή της SQL (Structured Query Language). H SQL προσφέρει αυξημένη αξιοπιστία, μεταφερσιμότητα και υψηλή παραμετροποίηση. Η υποστήριξη του προϊόντος είναι αρκετά ικανοποιητική και αποτελεί μια πολύ δημοφιλή και αποδοτική επιλογή για την ανάπτυξη συστημάτων παρόμοια με το δικό μας. Στα πακέτα κλάσεων του συστήματος μας υπάρχει ειδικό πακέτο με το όνομα DataBase API το οποίο και ανήκει στο DB Bridge component όπως περιγράφεται στην αποδόμηση του συστήματος στην παράγραφο 3.1 του παρόντος εγγράφου. Το πακέτο αυτό περιλαμβάνει τις κλάσεις που ευθύνονται για την διεκπεραίωση οποιασδήποτε λειτουργίας σχετικής με την βάση δεδομένων. Η αρχιτεκτονική αυτή που υιοθετήθηκε προσφέρει μεγάλη ευελιξία στην ανάπτυξη και συντήρηση του συστήματος DigiWallet καθώς ανεξαρτητοποιεί τις λειτουργίες του συστήματος από αυτές της βάσης δεδομένων. Ουσιαστικά το DataBase API αποτελεί ένα ενδιάμεσο layer μεταξύ του συστήματος και της βάσης δεδομένων. Με κατάλληλη ενημέρωση του διατηρείται η συμβατότητα μεταξύ του συστήματος και της βάσης δεδομένων μετά από οποιαδήποτε αλλαγή συντελείται σε κάποιο από αυτά. Στο κεφάλαιο 2 των απαιτήσεων λογισμικού στην παράγραφο της στατικής μοντελοποίησης περιγράφονται αναλυτικά και με απόλυτη σαφήνεια το σύνολο των δεδομένων που αποθηκεύονται στο σύστημα. Παρακάτω ακολουθεί σε κατηγοριοποιημένη μορφή (κατά κλάσεις) μια συνοπτική καταγραφή τους. Για κάθε κλάση που αναφέρεται αποθηκεύεται το σύνολο των δεδομένων που αυτή πραγματεύεται. Σε περίπτωση που είναι αναγκαία λεπτομερέστερη ανάλυσή τους προσφέρεται το προαναφερθέν έγγραφο. Users Package SimpleUser 19

20 Admin CorpUser CorpAdmin Transactions Package Transaction DigicardOnTransaction DigicardOffTransaction SystemControl Package SystemOverview TransactionPriority ErrorInquiry API Package ATMAPI MachineAPI MobileAPI 3.4 Έλεγχος Πρόσβασης και Ασφάλεια Ο παρακάτω πίνακας πρόσβασης μοντελοποιεί την πρόσβαση των χρηστών στα δεδομένα και τις συναρτήσεις των κλάσεων. Στην ορίζοντια γραμμή βρίσκονται οι κατηγορίες χρηστών και στην κατακόρυφη στήλη βρίσκονται οι κλάσεις του συστήματος. Σε κάθε κελί αναγράφονται οι συναρτήσεις των κλάσεων στις οποίες έχει πρόσβαση η κάθε κατηγορία χρήστη. Οι κλάσεις στα πακέτα GUI και API πραγματεύονται το γραφικό περιβάλλον διεπαφής και την επικοινωνία του συστήματος με εξωτερικά συστήματα. Συνεπώς δεν περιλαμβάνονται στον παρακάτω πίνακα καθώς δεν σχετίζονται με τα δικαιώματα των χρηστών. Αν και τα δεδομένα των κλάσεων δεν συμπεριλαμβάνονται στον πίνακα για συντομία χώρου, θεωρείται δεδομένο πως ο χρήστης διαθέτει πρόσβαση και στα αντίστοιχα δεδομένα τα οποία χρειάζεται κατά την εκτέλεση της κάθε συνάρτηση. Επίσης οι συναρτήσεις στον πίνακα παρατίθενται χωρίς τα ορίσματα τους για οικονομία χώρου. Η αναλυτική παρουσίαση των συναρτήσεων και των δεδομένων του συστήματος βρίσκεται στο κεφάλαιο 2 (στατική μοντελοποίηση) του εγγράφου απαιτήσεις συστήματος. 20

21 Class SimpleUser Class CorpUser Class CorpAdmin Class Admin Class Transaction Class DigicardOnTransaction Class DigicardOffTransaction Class SystemOverview Class TransactionPriority Class ErrorInquiry SimpleUser CorpUser CorpAdmin Admin ModifySettings() RequestTaxReport() CreateTransaction() ChargeDigicard() ReportTransaction() ReportBug() RequestReport() GetOTP() RevokeDigicard() ActivateBackupDigicard() RequestCredit() TransferCredit() ShowTransactions() ModifySettings() ModifySettings() CreateTransaction() CreateTransaction() ReportTransaction() ReportTransaction() ReportBug() ReportBug() RequestReport() RequestReport() RequestCredit() RequestCredit() TransferCredit() TransferCredit() ShowTransactions() ShowTransactions() SetPermissions() RequestTaxReport() CreateUser() DeleteUser() IssueDigicard() RevokeDigicard() ActivateDigicard() RequestAccountOpening() GetDate() GetDate() GetDate() CheckCredit() CheckCredit() CheckCredit() ExecuteTransaction() ExecuteTransaction() ExecuteTransaction() GetDate() PendingReports() GetTransaction() UpdateAccount() CheckCredit() GetDate() CheckCredit() ExecuteTransaction() NotifyPendingReports() CountTransactions() ShowLoad() NodeUsage() DefineMaxTransaction() GetCreditFlow() GetTransactionStats() GetNodeUSageStats() GetEstimatedTax() GetNodeTemperature() GetNodeSpace() GetOveralBandwidth() GetLineQuality() FindCorpTransactions() FindHugeTransactions() LocateSignalStrength() UpdatePendingTransactions() RetryTransaction() RetryTransaction() RetryTransaction() SendReport() SendReport() SendReport() NotifyAdmin() NotifyAdmin() NotifyAdmin() 21

22 Για την είσοδο των χρηστών στο σύστημα απαιτείται διαδικασία αυθεντικοποιήσης η οποία περιλαμβάνει την πληκτρολόγηση UserId και Password. Στην περίπτωση των administrators απαιτείται επιπλέον ένας κωδικός OTP ο οποίος εκδίδεται μετά από αίτηση στο σύστημα και έχει χρονική ισχύ ισχύ ίση με το ωράριο εργασίας του υπαλλήλου. Η επικοινωνία με τον Server του συστήματος για την διαδικασία Log in προστατεύεται από τα πρωτόκολλα ασφαλείας https και SSL (128bit). Τόσο τα UserId όσο και τα passwords των χρηστών αποθηκεύονται σε κρυπτογραφημένη μορφή στη βάση δεδομένων. Τα περιεχόμενα της βάσης δεδομένων (SQL) είναι κρυπτογραφημένα με την αντίστοιχη τεχνολογία κρυπτογράφησης που προσφέρει η εταιρεία, Transparent Data Encryption (TDE). 3.5 Γενικός έλεγχος λογισμικού Handler Όπως προαναφέρθηκε, η αρχιτεκτονική του συστήματος είναι αυτή του server-client. Συνεπώς, όλα τα αιτήματα ξεκινούν από τους clients, και εξυπηρετούνται από τον server. Ο τρόπος που υλοποιείται η διαδικασία, είναι αρκετά συνηθισμένος σε τέτοιου είδους συστήματα. Συγκεκριμένα, υπάρχει ένα επιπλέον τμήμα στην πλευρά του server, ο handler. Το τμήμα αυτό, έχει διττή σημασία. Από τη μια, αποτελεί το τμήμα διαχείρισης των επικοινωνιών. Κάθε client επικοινωνεί αποκλειστικά με αυτόν που του καταθέτει όλα τα αιτήματα προς εκτέλεση. Επίσης, ο handler είναι αυτός που εκκινεί τη διαδικασία αποστολής δεδομένων προς τους clients, όταν χρειάζεται. Αποτελεί ουσιαστικά την διεπαφή ολόκληρου του server με τον έξω κόσμο. Είναι το υποσύστημα που αποφασίζει για θέματα σύνδεσης, όπως time-outs και άλλα. Ο δεύτερος ρόλος του υποσυστήματος handler είναι η διαχείριση των clients. Συγκεκριμένα, ο client δημιουργεί, κατά την διαδικασία επιτυχούς εισαγωγής στο σύστημα ( log in), το αντικείμενο UserObject, με την μορφή ενός cookie το οποίο αποθηκεύεται προσωρινά στο σύστημα του client καθ όλη τη διάρκεια της επικοινωνίας (session), αλλά διαγράφεται με το πέρας αυτής. Σε αντιστοιχία με κάθε τέτοιο cookie,ο handler δημιουργεί ένα νήμα (thread) στον server, το οποίο συνδέεται μοναδικά με έναν συγκεκριμένο client (μέσω του cookie). Το νήμα αυτό καλεί τα δικά του instances των κλάσεων που απαιτείται κάθε φορά, για την εκτέλεση των λειτουργιών του. Η δομή και ο τρόπος λειτουργίας των νημάτων είναι τέτοια που επιτρέπει στον server να τα εκτελεί παράλληλα, ακολουθώντας όλες τις αρχές παράλληλων συστημάτων και προγραμμάτων. Επίσης, δεν υ- πάρχουν θέματα χρονισμού, λόγω ανεξαρτησίας των νημάτων. Το μοναδικό σημείο στο οποίο απαιτείται συγχρονισμός είναι η επικοινωνία με την βάση δεδομένων, η οποία και περιγράφεται στην επόμενη παράγραφο Συγχρονισμός στην SQL Όπως έχει αναφερθεί και παραπάνω, ο server ακολουθεί αρχιτεκτονική παράλληλου συστήματος. Προκύπτει έτσι η ανάγκη διαχείρισης, σε χρονικό επίπεδο, των αιτημάτων προς τη βάση δεδομένων. Σε περιπτώσεις όπου πολλά νήματα ζητούν πρόσβαση στη βάση δεδομένων, το σύστημα αντιδρά με τον παρακάτω τρόπο. Αρχικά, προσδιορίζει αν τα αιτήματα αναφέρονται στο ίδιο τμήμα της βάσης δεδομένων. Σε περίπτωση που κάτι τέτοιο δεν ισχύει, τα καταθέτει ταυτόχρονα. Για παράδειγμα, μια αίτηση τροποποίησης των στοιχείων ενός λογαριασμού, μια αίτηση για συναλλαγή και μια αίτηση αναφοράς ύποπτης συναλλαγής, είναι τρεις ανεξάρτητες διαδικασίες που μπορούν να εκτελεσθούν ταυτόχρονα. Σε αντίθετη περίπτωση, το σύστημα τοποθετεί τα αιτήματα σε μια ουρά, και τα καταθέτει σειριακά προς εκτέλεση, αφού βεβαιωθεί ότι το προηγούμενο αίτημα έχει ολοκληρωθεί. 22

23 3.6 Οριακές Συνθήκες Εκκίνηση συστήματος Έκδοση Περιγραφή Άλλαξε απ τον Ημερ/νία 1.0 Πρώτο προσχέδιο Fred Bloggs 1/1/ Συγγραφή Σεναρίου Τούμπας Κων/νος 19/5/12 Περι- Σύντομη γραφή: Οι παρακάτω παράγραφοι καθορίζουν τη συμπεριφορά του συστήματος σε συγκεκριμένες περιπτώσεις. Πυροδότηση Δραστηριότητας: Προϋπόθεση: Το σύστημα αποτελείται από δύο συνιστώσες, τον server και τον client. Η αρχιτεκτονική αυτή υλοποιείται, θεωρώντας δεδομένη τη δια-δικτυακή διεύθυνση του server. Έτσι, απαιτείται πρώτα η εκκίνηση του server, και στη συνέχεια μπορούν οποιαδήποτε στιγμή να εκκινήσουν και να συνδεθούν οι clients. Διαδικασία εκκίνησης του server. Ο server δεν είναι σε λειτουργία. Βασική Ροή Γραμμή Ενέργεια χρήστη συστήματος Απάντηση Συστήματος 1 Εκκίνηση του συστήματος server. Ο server είναι πλέον σε λειτουργία και μπορούν να συνδεθούν σε αυτόν clients. 2 Σύνδεση ενός client στο server. Ο χρήστης (client) είναι πλέον συνδεδεμένος στο σύστημα και μπορεί να πραγματοποιήσει οποιαδήποτε ενέργεια έχει δικαίωμα. Μετέπειτα κατάσταση: Ο server βρίσκεται σε λειτουργία και οι clients μπορούν να συνδεθούν σε αυτόν. Εναλλακτική Ροή (ΕΡ1): Αποτυχία σύνδεσης στο σύστημα Εάν στη γραμμή 2 στη βασική ροή ο χρήστης προσπαθήσει να συνδεθεί στον server όταν αυτός δεν βρίσκεται σε λειτουργία τότε: Γραμμή Ενέργεια χρήστη συστήματος Απάντηση Συστήματος 2 Σύνδεση ενός client στο server Το σύστημα εμφανίζει μήνυμα σφάλματος Server Unavailable Το σενάριο χρήσης τερματίζει. Μετέπειτα κατάσταση: Οι clients δεν μπορούν να συνδεθούν στο server, μέχρι ο τελευταίος να τεθεί σε λειτουργία. 23

24 3.6.2 Τερματισμός συστήματος Έκδοση Περιγραφή Άλλαξε απ τον Ημερ/νία 1.0 Πρώτο προσχέδιο Fred Bloggs 1/1/ Συγγραφή Σεναρίου Τούμπας Κων/νος 19/5/12 Περι- Σύντομη γραφή: Πυροδότηση Δραστηριότητας: Προϋπόθεση: Ο τερματισμός του συστήματος είναι μια διαδικασία η οποία δεν θα πρέπει να συμβαίνει υπό φυσιολογικές συνθήκες. Σε περίπτωση όμως που κάτι τέτοιο κρίνεται αναγκαίο (πχ για λόγους συντήρησης ή πραγματοποίησης κάποιας αναβάθμισης), θα εμφανίζεται σε όλους τους συνδεδεμένους χρήστες (clients), μήνυμα το οποίο θα τους ενημερώνει την ώρα τερματισμού του συστήματος, καθώς και τη χρονική διάρκεια κατά την οποία δεν θα λειτουργεί το όλο σύστημα. Οι ειδοποιήσεις αυτές θα εμφανίζονται για πρώτη φορά 24 ώρες, τουλάχιστον, πριν τον προγραμματισμένο τερματισμό, και όσο πλησιάζει η ώρα του τερματισμού θα πληθαίνουν. Εκκίνηση διαδικασίας τερματισμού. Ο server είναι σε λειτουργία. Βασική Ροή Γραμμή Ενέργεια χρήστη συστήματος Απάντηση Συστήματος 1 Ενημέρωση των χρηστών ότι το σύστημα θα παραμείνει ανενεργό για ένα καθορισμένο χρονικό διάστημα. 2 Έναρξη διαδικασίας τερματισμού, μετά από ένα καθορισμένο χρονικό διάστημα από την ολοκλήρωση του προηγούμενου βήματος. Μετέπειτα κατάσταση: Το σύστημα στέλνει ένα προειδοποιητικό και εμφανίζει στο GUI του συστήματος μήνυμα για τη μη διαθεσιμότητα του συστήματος. Τερματισμός συστήματος. Το σύστημα παραμένει ανενεργό μέχρι την πραγματοποίηση της διαδικασίας εκκίνησής του. Εναλλακτική Ροή (ΕΡ1): Παραμονή στο σύστημα Εάν στη γραμμή 2 στη βασική ροή, ο χρήστης παραμένει συνδεδεμένος στο σύστημα και προσπαθήσει να πραγματοποιήσει μια ενέργεια, τότε: Γραμμή Ενέργεια χρήστη συστήματος Απάντηση Συστήματος 2 Αίτηση για μια ενέργεια. Εμφάνιση μηνύματος σφάλματος timeout. Το σενάριο χρήσης τερματίζει. Μετέπειτα κατάσταση: Οι clients δεν μπορούν να συνδεθούν στο server, μέχρι ο τελευταίος να τεθεί σε λειτουργία. 24

25 3.6.3 Εμφάνιση σφαλμάτων Εμφάνιση σφάλματος στο περιβάλλον του client Έκδοση Περιγραφή Άλλαξε απ τον Ημερ/νία 1.0 Πρώτο προσχέδιο Fred Bloggs 1/1/ Συγγραφή Σεναρίου Τούμπας Κων/νος 19/5/12 Περι- Σύντομη γραφή: Πυροδότηση Δραστηριότητας: Προϋπόθεση: Σε περίπτωση εμφάνισης σφάλματος στον client (πχ το σύστημα δέχτηκε εσφαλμένη αίτηση), ο client επανεκκινεί αυτόματα, ζητώντας την εκ νέου είσοδο του χρήστη στο σύστημα. Αυτό έχει ως στόχο, την αποφυγή ζητημάτων ασφάλειας. Εμφάνιση σφάλματος. Ο client να είναι συνδεδεμένος στο σύστημα. Βασική Ροή Γραμμή Ενέργεια χρήστη συστήματος Απάντηση Συστήματος 1 Ενέργεια που πυροδοτεί την εμφάνιση ενός σφάλματος. Εμφάνιση μηνύματος σφάλματος και επανεκκίνηση του client, ζητώντας να κάνει Sign In. Αναμονή του συστήματος μέχρι ο client να κάνει Sign In, για τη συνέχεια της λειτουργίας του Εμφάνιση σφάλματος στην επικοινωνία client-server Έκδοση Περιγραφή Άλλαξε απ τον Ημερ/νία 1.0 Πρώτο προσχέδιο Fred Bloggs 1/1/ Συγγραφή Σεναρίου Τούμπας Κων/νος 19/5/12 Περι- Σύντομη γραφή: Μετέπειτα κατάσταση: Πυροδότηση Δραστηριότητας: Προϋπόθεση: Σε περίπτωση σφάλματος στην επικοινωνία client-server ( όπως για παράδειγμα σε περίπτωση 3.6.2, ή σε μια περίπτωση κακού δικτύου) προκύπτει σφάλμα με τη μορφή διαδικασίας επικοινωνίας που δεν ολοκληρώθηκε. Σε μια τέτοια περίπτωση, εμφανίζεται μήνυμα στον χρήστη, πληροφορώντας τον πως η διαδικασία που αιτήθηκε δεν εκτελέστηκε με επιτυχία, και του δίνει τη δυνατότητα επανάληψης της όλης διαδικασίας. Αίτηση του client η οποία δεν λήφθηκε από τον server ή δεν ήρθε απάντηση. Ο client να είναι συνδεδεμένος στο σύστημα και το σύστημα να λειτουργεί σωστά. 25