forked from mirrors/easyappointments
* Added content to implementation.tex
* Made corrections into several tex files.
This commit is contained in:
parent
fb196ed719
commit
5385243cb5
12 changed files with 151 additions and 127 deletions
|
@ -2,32 +2,32 @@
|
|||
Το αποτέλεσμα της εκπόνησης της εργασίας αυτής είναι ένα πλήρης σύστημα διαχείρισης ραντεβού, το οποίο μπορεί να παραμετροποιηθεί επαρκώς έτσι ώστε να καλύψει τις ανάγκες οποιασδήποτε επιχείρισης ανεξαρτήτου ειδικότητας και μεγέθους. Ο αρχικός σχεδιασμός αποδείχθηκε σωστός και έτσι το τελικό προϊόν πληροί τις απαιτήσεις για τις οποίες αναπτύχθηκε.
|
||||
|
||||
\section{Προβλήματα}
|
||||
\subsection{Διαχείριση Χρόνου}
|
||||
\subsection{Διαχείριση χρόνου}
|
||||
Σημαντικότερο πρόβλημα σχετικά με την υλοποίηση της εφαρμογής ήταν η χρονική καθυστέρηση μιας και ανάμεσα στην ανάληψη της εργασίας και την περαίωση της, πραγματοποιήθηκε η πρακτική άσκηση σε εταιρεία πληροφορικής, καθώς και εργασία εκτός σχολής με άλλες εταιρείες πληροφορικής. Οι εξωτερικές υποχρεώσεις αυτές αποσπούσαν την συνεχή και ομαλή ανάπτυξη, κάτι που συνεχώς διασπούσε τον ειρμό και τον δημιουργικό οίστρο. Συμπέρασμα αυτού του σημαντικού προβλήματος είναι ότι θα πρέπει να γίνεται σαφής και ορθός προγραμματισμός του χρόνου υλοποίησης ενός έργου γιατί διαφορετικά οι πιθανότητες για χαμηλότερη ποιότητα υπηρεσίας ή ακόμα και αποτυχίας του έργου αυξάνονται εκθετικά.
|
||||
|
||||
\subsection{Συγχρονισμός Δεδομένων Με Το Google Calendar}
|
||||
\subsection{Συγχρονισμός δεδομένων με το Google Calendar}
|
||||
Όσον αφορά την συνεργασία του συστήματος με την υπηρεσία Google Calendar, αλλά και γενικότερα με άλλες πιθανές υπηρεσίες το ζήτημα παραμένει στο πως θα παραμείνουν τα δεδομένα ακέραια και ενημερωμένα και στα δύο συστήματα, όταν δεν υπάρχει ένα κοινό μέσο αποθήκευσης. Το θέμα γιγαντώνεται μάλιστα όταν δεν υπάρχει πρόσβαση στον κώδικα του ενός από τα δύο συστήματα έτσι ώστε να δημιουργηθεί μια "γέφυρα δεδομένων". Για την επίλυση αυτού του θέματος ήταν αναγκαίο να δημιουργηθεί ένας αλγόριθμος συγχρονισμού ο οποίος θα ενεργοποιούνταν από την πλευρά του Easy!Appointments και θα αναλάμβανε την ενημέρωση και τον δύο συστημάτων με τα τελευταία δεδομένα. Για αυτόν τον σκοπό θα έπρεπε να καταγραφούν και να υλοποιηθούν κάποιοι κανόνες συγχρονισμού οι οποίοι θα μετέφεραν επιτυχώς τα ραντεβού αμφίδρομα και στα δύο συστήματα. Στις περιπτώσεις όπου η μεταφορά αυτή θα ήταν αδύνατη (σύγκρουση δεδομένων) ο χρήστης θα έπρεπε να αποφασίσει ποια εκδοχή των δεδομένων θα υπερισχύσει στο τέλος.
|
||||
|
||||
\subsection{Διαχωρισμός Δικαιωμάτων Χρηστών}
|
||||
\subsection{Διαχωρισμός δικαιωμάτων χρηστών}
|
||||
Ένα ακόμα πρόβλημα που αντιμετωπίστηκε κατά την διάρκεια την ανάπτυξης του έργου ήταν ο διαχωρισμός των δικαιωμάτων των χρηστών μέσα στο σύστημα. Ο κάθε χρήστης αναλόγως το είδος του (διαχειριστής, πάροχως, γραμματέας) έχει διαφορετικές δυνατότητες και δικαιώματα στα δεδομένα που αποθηκεύονται από το σύστημα. Αυτό συμβαίνει γιατί στις περισσότερες περιπτώσεις θα πρέπει να τηρηθεί η ιεραρχία της επιχείρησης, αλλά και επίσης γιατί θα πρέπει να διασφαλιστεί η ακεραιότητα των δεδομένων από τυχόν εσφαλμένες ενέργειες χρηστών σε βασικές ρυθμίσεις του συστήματος. Για τις κυριότερες ρυθμίσεις απαιτούνται τα δικαιώματα διαχειριστή και έτσι το σύστημα χρειάζεται απαραιτήτως πάντα έναν χρήστη διαχειριστή (ο χρήστης που δημιουργείται κατά την εγκατάσταση είναι ουσιαστικά ο πρώτος διαχειριστής της εφαρμογής). Για να λυθεί αυτό το πρόβλημα η εγγραφή του κάθε χρήστης στην βάση δεδομένων συνδέεται με έναν ρόλο, ο οποίος περιέχει τα δικαιώματα που του αντιστοιχούν. Έτσι για παράδειγμα ένας χρήστης που προορίζεται για πάροχος υπηρεσίας, θα έχει τα δικαιώματα που αντιστοιχούν στον ρόλο "Πάροχος Υπηρεσίας", όπως αυτά είναι αποθηκευμένα στην βάση δεδομένων. Έτσι κάθε φορά που συνδέεται ένας χρήστης στο διαχειριστικό κομμάτι της εφαρμογής τα δεδομένα σχετικά με τα δικαιώματα του και τον ρόλο του διαβάζονται από σελίδα σε σελίδα και η εφαρμογή μπορεί και γνωρίζει με ποιόν τρόπο θα πρέπει να εμφανιστούν τα δεδομένα και ποιες ενέργειες είναι διαθέσιμες στην κάθε περίπτωση.
|
||||
|
||||
\section{Εξέλιξη Της Εφαρμογής}
|
||||
\section{Εξέλιξη της εφαρμογής}
|
||||
Όπως και σε κάθε έργο λογισμικού, υπάρχουν πολλά πράγματα τα οποία μπορούν να εξελιχθούν και να βελτιωθούν, καθώς και δυνατότητες οι οποίες μπορούν να προστεθούν για να κάνουν την εφαρμογή πιο εύχρηστη και αποδοτικότερη. Οι βελτιώσεις αυτές γίνονται στην φάση της συντήρησης και επέκτασης, σταδιακά, με σκοπό την ύπαρξη ενός ενημερωμένου προϊόντος στην αγορά. Με αυτόν τον τρόπο οι εταιρείες θα μπορούν να εμπιστεύονται την εν λόγω εφαρμογή και να την χρησιμοποιούν ως το δικό τους εργαλείο διαχείρισης των ραντεβού. Παρακάτω περιγράφονται κάποια σημεία στα οποία θα μπορούσε να εξελιχθεί μελλοντικά το σύστημα που παράχθηκε.
|
||||
|
||||
\subsection{Mobile Design}
|
||||
\subsection{Mobile design}
|
||||
Με την πάροδο του χρόνου όλο και περισσότερες "έξυπνες" συσκευές βρίσκονται στα χέρια των καταναλωτών και έτσι δημιουργείται η ανάγκη για χρήση των διαδικτυακών εφαρμογών από οθόνες που έχουν διαφορετικά μεγέθη οθονών. Εφόσον οι διαστάσεις για τις οθόνες του υπολογιστή έχουν καλυφθεί, το επόμενο βήμα είναι να σχεδιαστεί όλο το σύστημα για κινητές συσκευές και tablet. Με αυτόν τον τρόπο θα μπορούν οι χρήστες του Easy!Appointments να χρησιμοποιούν το σύστημα από το κινητό του πολύ πιο άνετα και έτσι να είναι πάντα ενημερωμένοι σχετικά με τα ραντεβού τους όπου και αν βρίσκονται. Προϋπόθεση για αυτό πάντα είναι μια ενεργή σύνδεση με το διαδίκτυο. Για να υλοποιηθεί αυτή η δυνατότητα θα χρειαστεί να γραφεί CSS κώδικας ο οποίος να εμφανίζει την εφαρμογή διαφορετικά σε κινητές συσκευές.
|
||||
|
||||
\subsection{Μετάφραση Της Διεπαφής Χρήστη}
|
||||
\subsection{Μετάφραση της διεπαφής χρήστη}
|
||||
Η πρώτη υλοποίηση του συστήματος έχει γίνει εξολοκλήρου στην αγγλική γλώσσα, όπως και με τα περισσότερα συστήματα που απευθύνονται σε ένα ευρύ καταναλωτικό κοινό. Το Easy!Appointments δέχεται κείμενο και σε άλλες γλώσσες (χρησιμοποιείται το encoding UTF-8) αλλά η διεπαφή, τα μηνύματα και τα αντικείμενα ελέγχου είναι όλα στα Αγγλικά. Για να γίνει πιο εύκολη η χρήση της εφαρμογής και από ανθρώπους οι οποίοι δεν είναι τόσο εξοικειωμένοι με αυτήν την γλώσσα θα πρέπει να μεταφραστεί όλο το σύστημα και σε άλλες κοινές γλώσσες. Για να επιτευχθεί αυτό στην συγκεκριμένη περίπτωση θα πρέπει να χρησιμοποιηθεί η ενσωματωμένη τεχνική του CodeIgniter.
|
||||
|
||||
\subsection{Αναφορές Δεδομένων}
|
||||
\subsection{Αναφορές δεδομένων}
|
||||
Το σύστημα μέσω της λειτουργίας του κρατάει διάφορα δεδομένα (ραντεβού, πελάτες, πάροχοι κτλ). Καλό θα ήταν αυτά τα δεδομένα να μπορούν να εξαχθούν με κάποιον τρόπο έτσι ώστε να μπορέσουν να χρησιμοποιηθούν και με άλλους τρόπους. Μια περίπτωση χρήσης θα ήταν η εξαγωγή των σημερινών ραντεβού ενός πάροχου σε μια εκτυπώσιμη αναφορά, έτσι ώστε να μπορεί ο χρήστης να την τυπώσει και να την έχει ως λίστα στο γραφείο. Μια άλλη περίπτωση χρήσης θα ήταν να εκτυπωθούν τα στοιχεία ενός πελάτη, καθώς και το ιστορικό των ραντεβού του. Οι αναφορές αυτές είναι πολύ χρήσιμες γιατί μπορούν να αναδείξουν γρήγορα δεδομένα και μάλιστα σε εκτυπώσιμη μορφή, κάτι που ακόμα χρειάζονται πολλές εταιρείες.
|
||||
|
||||
\subsection{Στατιστικές Πληροφορίες}
|
||||
\subsection{Στατιστικές πληροφορίες}
|
||||
Μια χρήσιμη μελλοντική δυνατότητα θα ήταν η συλλογή στατιστικών πληροφοριών σχετικά με τα ραντεβού που κλίνονται στο σύστημα. Από αυτήν την διαδικασία θα μπορούσαν να βγουν σημαντικές πληροφορίες όπως το ποια υπηρεσία ή πάροχος προτιμάται πιο συχνά, ποιες μέρες έχουν τα περισσότερα ραντεβού, πόσο συχνά ακυρώνονται τα ραντεβού και σε πόσο χρονικό διάστημα πριν. Αυτές οι πληροφορίες είναι πολύ σημαντικές για μια εταιρεία η οποία λειτουργεί με κρατήσεις ραντεβού γιατί έτσι μπορεί να γνωρίζει με ποιόν τρόπο λειτουργεί το πελατειακό κοινό της και έτσι να λειτουργεί αναλόγως για να παρέχει καλύτερη εξυπηρέτηση. Ένα παράδειγμα θα ήταν η περίπτωση ενός μεγάλου κομμωτηρίου στην οποία οι πελάτες θα κρατούσαν πάρα πολλά ραντεβού το Σάββατο κάθε εβδομάδας, γιατί πιθανόν έχουν περισσότερο χρόνο. Τα στατιστικά (εκτός της πείρας) θα έδειχναν την αυξημένη κίνηση του Σαββάτου και έτσι ο διαχειριστής θα είχε διαθέσιμους όλους του πάροχους προς ραντεβού, για να μπορέσει να καλυφθεί το κοινό όσο καλύτερα γίνεται.
|
||||
|
||||
\subsection{Δημιουργία RESTful Υπηρεσίας}
|
||||
Κάθε μεγάλο διαδικτυακό σύστημα παρέχει και μια RESTful υπηρεσία η οποία μπορεί να απαντάει με δεδομένα σε διάφορες κλήσεις που της γίνονται, εφόσον βέβαια έχει πιστοποιηθεί ο client που επικοινωνεί μαζί τους. Με αυτόν τον τρόπο θα μπορούν άλλοι προγραμματιστές να φτιάχνουν εφαρμογές οι οποίες θα επικοινωνούν με το Easy!Appointments και θα διαχειρίζονται τα δεδομένα του συστήματος. Η υλοποίηση αυτής της δυνατότητας θα βοηθούσε πολύ την εξέλιξη και την χρήση του Easy!Appoinmtments γιατί από εδώ και πέρα διάφορες εφαρμογές θα υλοποιούνταν κάνοντας δυνατή την χρήση των δεδομένων σε πολλές διαφορετικές περιστάσεις. Κάτι που είναι πάρα πολύ χρήσιμο για κάθε επαγγελματία (παραδείγματος χάρη η χρήση πελατών από CRM εφαρμογή).
|
||||
\subsection{Δημιουργία RESTful υπηρεσίας}
|
||||
Κάθε μεγάλο διαδικτυακό σύστημα παρέχει και μια RESTful υπηρεσία η οποία μπορεί να απαντάει με δεδομένα σε διάφορες κλήσεις που της γίνονται, εφόσον βέβαια έχει πιστοποιηθεί ο client που επικοινωνεί μαζί τους. Με αυτόν τον τρόπο θα μπορούν άλλοι προγραμματιστές να φτιάχνουν εφαρμογές οι οποίες θα επικοινωνούν με το Easy!Appointments και θα διαχειρίζονται τα δεδομένα του συστήματος. Η υλοποίηση αυτής της δυνατότητας θα βοηθούσε πολύ την εξέλιξη και την χρήση του Easy!Appointments γιατί από εδώ και πέρα διάφορες εφαρμογές θα υλοποιούνταν κάνοντας δυνατή την χρήση των δεδομένων σε πολλές διαφορετικές περιστάσεις. Κάτι που είναι πάρα πολύ χρήσιμο για κάθε επαγγελματία (παραδείγματος χάρη η χρήση πελατών από CRM εφαρμογή).
|
||||
|
||||
\subsection{Βελτίωση Κώδικα}
|
||||
\subsection{Βελτίωση κώδικα}
|
||||
Τελευταίο αλλά και όχι λιγότερο σημαντικό είναι η συνεχής βελτίωση και ενημέρωση του κώδικα έτσι ώστε να είναι πάντα στην καλύτερη δυνατή κατάσταση. Καθώς εξελίσσεται ένα σύστημα λογισμικού είναι απαραίτητο να βελτιώνεται ο κώδικας και η δομή του. Επίσης είναι απαραίτητο να ενημερώνονται και τα εξωτερικά εργαλεία τα οποία χρησιμοποιούνται έτσι ώστε να διασφαλίζεται η ασφάλεια και η ποιότητα του συστήματος. Κατά καιρούς εμφανίζονται διάφορες ενημερώσεις ασφαλείας αλλά και διορθώσεων σφαλμάτων σε αυτά τα framework (CodeIgniter, jQuery κτλ) τα οποία θα χρειαστεί να συμπεριληφθούν και στο Easy!Appointments. Κάθε φορά που ο χρήστης λαμβάνει μια νέα έκδοση της εφαρμογής θα πρέπει ο κώδικας που την απαρτίζει να βρίσκεται σε πολύ καλή κατάσταση, να έχει ελεγχθεί και να λειτουργεί σωστά έτσι ώστε να εμπνέει εμπιστοσύνη προς τους χρήστες.
|
|
@ -1,9 +1,9 @@
|
|||
%% ΑΛΛΑ ΕΞΩΤΕΡΙΚΑ ΕΡΓΑΛΕΙΑ
|
||||
%% ΕΞΩΤΕΡΙΚΑ ΕΡΓΑΛΕΙΑ
|
||||
%% Σε αυτό το κεφάλαιο γίνεται περιγραφή των υπόλοιπων εξωτερικών
|
||||
%% εργαλείων που χρησιμοποιήθηκαν από για την υλοποίηση του συστήματος
|
||||
%% κρατήσεων ραντεβού.
|
||||
|
||||
\chapter{Άλλα Εξωτερικά Εργαλεία}
|
||||
\chapter{Εξωτερικά Εργαλεία}
|
||||
Εκτός του Calendar API και των βιβλιοθηκών που παρέχει η Google, έχουν χρησιμοποιηθεί και κάποια άλλα εργαλεία ανάπτυξης λογισμικού, τα οποία βοήθησαν στην άρτια και ποιοτικότερη παραγωγή του συστήματος κρατήσεων ραντεβού. Τα εργαλεία αυτά είναι όλα ανοιχτού κώδικα (open source) και έχουν στόχο να βοηθήσουν τον προγραμματιστή να επικεντρωθεί περισσότερο σε αυτό που έχει να κάνει και όχι τόσο στα τετριμμένα πράγματα τα οποία αποσπούν μεγάλο χρονικό διάστημα άσκοπα. Εν ολίγοις πρόκειται για ένα σύνολο από διάφορα framework τα οποία είναι πολύ χρήσιμα για οποιαδήποτε ανάπτυξη λογισμικού.
|
||||
|
||||
\section{CodeIgniter}
|
||||
|
|
|
@ -25,7 +25,7 @@
|
|||
|
||||
Για να αποτραπεί η υπερβολική χρήση της υπηρεσίας Calendar, η εταιρεία έχει θέσει ένα υπέρτατο όριο 10.000 request την ημέρα. Αν κάποια εταιρεία ξεπεράσει αυτό το όριο τότε θα χρειαστεί να πληρώσει κάποιο αντίτιμο για να μπορέσει να συνεχίσει κανονικά την χρήση. Για αυτό τον λόγο είναι και απαραίτητο οποιοσδήποτε client χρησιμοποιεί το Calendar API, να έχει πρώτα δημιουργήσει ένα API Key μέσω της σελίδας API Console που προσφέρει η Google.
|
||||
|
||||
\section {Περιγραφή Του API}
|
||||
\section {Περιγραφή του Calendar API}
|
||||
Το Ημερολόγιο της Google είναι ένα πολύ δυνατό και ευέλικτο εργαλείο. Οι χρήστες μπορούν να βλέπουν το ίδιο ημερολόγιο σε οποιαδήποτε συσκευή βρίσκονται έχοντας απλώς σύνδεση με το διαδίκτυο, για να μπορέσουν να ληφθούν τα δεδομένα από την υπηρεσία. Όλες οι εφαρμογές αυτές χρησιμοποιούν το API για να υλοποιήσουν τις βασικές λειτουργίες ενός ημερολογίου, δηλαδή την διαχείριση και την εύκολη εύρεση συμβάντων που είναι καταχωρημένα στο Google Calendar. Αφού γίνουν οι αλλαγές αυτές θα χρειαστεί να εκτελεστεί η διαδικασία του συγχρονισμού έτσι ώστε τα νέα δεδομένα να είναι και στις υπόλοιπες εφαρμογές που έχουν πρόσβαση στο ημερολόγιο.
|
||||
|
||||
Στην ευρεία χρήση της υπηρεσίας συντελεί το ότι η πλατφόρμα του ημερολογίου είναι συμβατή με διάφορες γλώσσες προγραμματισμού και έτσι μπορούν να υλοποιηθούν εφαρμογές για όλες τις συσκευές με εξελιγμένο λειτουργικό σύστημα (Windows, Linux, MacOsX, Android, iOs, Windows Phone κτλ).
|
||||
|
@ -53,7 +53,7 @@
|
|||
|
||||
Οι προγραμματιστές διαμορφώνουν τον κωδικά τους έτσι ώστε να είναι συμβατός με αυτήν την δομή και έτσι η επικοινωνία με την υπηρεσία της Google να είναι ευκολότερη.
|
||||
|
||||
\section {Πως χρησιμοποιείται το API}
|
||||
\section {Πως χρησιμοποιείται}
|
||||
Η χρήση του API μπορεί να γίνει απευθείας με κλήσεις RESTful προς τον server της Google, είτε με χρήση κάποιων από τις έτοιμες βιβλιοθήκες που παρέχει η εταιρεία. Επίσης είναι απαραίτητη η ύπαρξη ενός λογαριασμού στην Google καθώς και η καταχώρηση του project στο Google API Console έτσι ώστε να πάρει ο προγραμματιστής ένα API Key, ένα κλειδί το οποίο είναι απαραίτητο για την χρήση της υπηρεσίας.
|
||||
|
||||
Αν ο προγραμματιστής επιλέξει την χρήση της RESTful μεθόδου επικοινωνίας, θα χρειαστεί αν στέλνει request σε διάφορα URL και έτσι να παίρνει απαντήσεις με τα δεδομένα που χρειάζεται. Όλες οι απαντήσεις είναι σε JSON μορφή οπότε είναι πιθανόν να χρειαστεί να τις αναλύσει (parse) πριν τις χρησιμοποιήσει στην εφαρμογή του.
|
||||
|
@ -129,7 +129,7 @@ if (isset($_SESSION['oauth_access_token'])) {
|
|||
|
||||
Με αυτόν τον τρόπο εκτελούνται οι διαδικασίες ανταλλαγής δεδομένων μεταξύ του Google Calendar και του συστήματος του προγραμματιστή.
|
||||
|
||||
\section{Συγχρονισμός Ραντεβού με το Google Calendar}
|
||||
\section{Συγχρονισμός ραντεβού}
|
||||
Ο συγχρονισμός δεδομένων μεταξύ δυο συστημάτων είναι μια περίπλοκη και υποτιμημένη διαδικασία, διότι ο προγραμματιστής έχει κάνει αρκετή δουλειά έτσι ώστε να καταφέρει να γεφυρώσει και τις δυο πηγές δεδομένων με τον καλύτερο τρόπο. Το αποτέλεσμα δεν μπορεί ποτέ να είναι 100\% επιτυχές διότι μερικές φορές τα δεδομένα και οι αλλαγές μπορεί να έρχονται σε σύγκρουση (conflict) και έτσι θα χρειαστεί να παρθούν αποφάσεις είτε με βάση κάποιους κανόνες, είτε από τον ίδιο τον χρήστη για το ποια αλλαγή θα υπερισχύσει. Το πράγμα μάλιστα δυσκολεύει περισσότερο όταν δεν υπάρχει πρόσβαση στον κώδικα του ενός από τα δύο συστήματα (πχ Google Calendar) και όλη η διαδικασία θα πρέπει να τρέξει από το άλλο.
|
||||
|
||||
Στην περίπτωση του Easy!Appointments θα πρέπει να υλοποιηθεί μια διαδικασία η οποία θα συγχρονίζει τα ραντεβού και τα συμβάντα του συστήματος με αυτά του Google Calendar. Η διαδικασία αυτή θα εκτελείτε όταν δημιουργούνται συγκεκριμένα συμβάντα (πχ. προσθήκη ραντεβού) και θα φέρνει και τα δύο πλάνα στην ίδια κατάσταση. Ο συγχρονισμός θα εκτελείται κάθε φορά για το πλάνο ενός πάροχου υπηρεσιών και εφόσον έχει ήδη δοθεί η άδεια στην εφαρμογή να έχει πρόσβαση στα δεδομένα του Google Calendar του συγκεκριμένου χρήστη.
|
||||
|
|
|
@ -57,12 +57,12 @@
|
|||
%% ============================================================================
|
||||
%% ΤΑ ΠΑΡΑΚΑΤΩ ΕΙΝΑΙ ΥΠΟΧΡΕΩΤΙΚΑ
|
||||
%% ============================================================================
|
||||
\renewcommand{\thesistitle}{Δημιουργία διαδικτυακού συστήματος συνατντήσεων (appointments) με χρήση Google Calendar PHP API}
|
||||
\renewcommand{\thesistitle}{Δημιουργία διαδικτυακού συστήματος συναντήσεων (appointments) με χρήση Google Calendar PHP API}
|
||||
\renewcommand{\thesisauthor}{Αλέξανδρος Τσελεγγίδης (2503)}
|
||||
\renewcommand{\thesisauthorabbrv}{Α. Τσελεγγίδης}
|
||||
\renewcommand{\thesisauthorinitials}{ΑΤ}
|
||||
\renewcommand{\thesissupervisor}{Δρ. Νικόλαος Πεταλίδης, Επιστημονικός Συνεργάτης}
|
||||
\renewcommand{\thesismonth}{Ιούνιος}
|
||||
\renewcommand{\thesismonth}{Νοέμβριος}
|
||||
\renewcommand{\thesisyear}{2013}
|
||||
|
||||
%% ΒΙΒΛΙΟΓΡΑΦΙΑ
|
||||
|
|
|
@ -1,10 +1,16 @@
|
|||
%% ΣΧΕΔΙΑΣΗ & ΥΛΟΠΟΙΗΣΗ
|
||||
%% Σε αυτό το κεφάλαιο περιγράφεται η διαδικασία σχεδίασης και
|
||||
%% υλοποίησης της εφαρμογής. Αναλύονται οι επιλογές που έχουν
|
||||
%% γίνει και με ποιόν τρόπο λειτουργούν κάποια βασικά τμήματα
|
||||
%% του κώδικα.
|
||||
|
||||
\chapter{Σχεδίαση \& Υλοποίηση}
|
||||
Σε αυτό το κεφάλαιο γίνεται ανάλυση του συστήματος στα επιμέρους μέρη και περιγράφεται η διαδικασία της υλοποίησης τους. Επεξηγούνται επίσης τα σημαντικότερα σημεία στον κώδικα και οι αλγόριθμοι που χρησιμοποιούνται για την επίλυση των κυριότερων λειτουργιών. Έχουν συμπεριληφθεί τμήματα κώδικα αλλά και διαγράμματα τα οποία βοηθούν στην κατανόηση των λύσεων που έχουν χρησιμοποιηθεί.
|
||||
Σε αυτό το κεφάλαιο γίνεται ανάλυση του συστήματος στα επιμέρους μέρη που το απαρτίζουν και περιγράφεται η διαδικασία της υλοποίησης τους. Επεξηγούνται επίσης τα σημαντικότερα σημεία στον κώδικα και οι αλγόριθμοι που χρησιμοποιούνται για την επίλυση των κυριότερων λειτουργιών. Έχουν συμπεριληφθεί τμήματα κώδικα αλλά και διαγράμματα τα οποία βοηθούν στην κατανόηση των λύσεων που έχουν χρησιμοποιηθεί.
|
||||
|
||||
%% ==================================================
|
||||
%% ΑΝΑΛΥΣΗ ΔΕΔΟΜΕΝΩΝ
|
||||
%% ==================================================
|
||||
\section{Ανάλυση Δεδομένων}
|
||||
\section{Ανάλυση δεδομένων}
|
||||
Το κυριότερο πρόβλημα που προσπαθεί να λύσει το σύστημα είναι η κράτηση και η διαχείριση ραντεβού από μια επιχείριση. Σε αυτήν την περίπτωση χρήσης έχει επικεντρωθεί η σχεδίαση και η υλοποίηση του συστήματος το οποίο περιέχει και άλλες δυνατότητες οι οποίες μπορούν όμως να θεωρηθούν λιγότερο σημαντικές. Έχοντας υπόψιν την έννοια "ραντεβού" ως την κύρια οντότητα της εφαρμογής, σχεδιάστηκε το παρακάτω μοντέλο το οποίο διευκρινίζει τις σχέσεις των οντοτήτων του συστήματος μεταξύ τους.
|
||||
|
||||
\begin{figure}[ht!]
|
||||
|
@ -14,7 +20,7 @@
|
|||
\label{domain-model}
|
||||
\end{figure}
|
||||
|
||||
Με βάση αυτό το σχεδιάγραμμα μπορεί πολύ εύκολα να προκύψει και το σχεδιακό μοντέλο της βάσης δεδομένων, δεδομένου ότι έχουμε και τις οντότητες, αλλά και τις σχέσεις μεταξύ τους. Όλοι οι χρήστες της εφαρμογής κληρονομούν την συμπεριφορά τους από μια οντότητα (User) και στην συνέχεια προσθέτουν τις πρόσθετες ιδιαιτερότητες που τους χαρακτηρίζουν. Για παράδειγμα ο χρήστης γραμματέας (Secretary) περιέχει έναν πίνακα από πάροχους (Providers) τους οποίους μπορεί να διαχειριστεί, ή ένα ραντεβού είναι ξεκάθαρο ότι περιέχει στην πληροφορία του έναν πελάτη, έναν πάροχο και μια υπηρεσία.
|
||||
Με βάση αυτό το σχεδιάγραμμα μπορεί πολύ εύκολα να προκύψει και το σχεδιακό μοντέλο της βάσης δεδομένων, δεδομένου ότι έχουμε και τις οντότητες, αλλά και τις σχέσεις μεταξύ τους. Όλοι οι χρήστες κληρονομούν την συμπεριφορά τους από μια οντότητα (User) και επιπρόσθετα κατέχουν διάφορες ιδιότητες που είναι αναγκαίες για τον ρόλο τους μέσα στην εφαρμογή. Για παράδειγμα ο χρήστης γραμματέας (Secretary) περιέχει έναν πίνακα από πάροχους (Providers) τους οποίους μπορεί να διαχειριστεί, ή ένα ραντεβού είναι ξεκάθαρο ότι περιέχει στην πληροφορία του έναν πελάτη, έναν πάροχο και μια υπηρεσία.
|
||||
|
||||
\begin{figure}[ht!]
|
||||
\centering
|
||||
|
@ -23,21 +29,21 @@
|
|||
\label{er}
|
||||
\end{figure}
|
||||
|
||||
Για την διαχείριση των δεδομένων της βάσης δημιουργήθηκαν ειδικές κλάσεις (models) οι οποίες περιέχουν μεθόδους που χρησιμοποιούνται από τους controllers του συστήματος. Το CodeIgniter δίνει στον προγραμματιστή ένα δικό του μέσο επικοινωνίας με την βάση δεδομένων, το οποίο είναι ένα πολύ ισχυρό και ευέλικτο εργαλείο. Η επονομαζόμενη Database Class του CodeIgniter επιτρέπει στον προγραμματιστεί να εκτελεί ερωτήματα προς την βάση, να παράγει αποτελέσματα και να τα αναλύει σε ξεχωριστές εγγραφές, να κρατάει στην μνήμη ερωτήματα για γρηγορότερη ανταπόκριση (query caching) και κυριότερο την κλάση Active Record. Η κλάση αυτή έχει έναν δικό της τρόπο για την εκτέλεση των ερωτημάτων προς την βάση. Όλα τα τμήματα ενός τυπικού ερωτήματος είναι μέθοδοι σε αυτήν την κλάση και έτσι ο προγραμματιστείς χρησιμοποιεί τις μεθόδους αυτές για να επικοινωνήσει με την βάση δεδομένων. Το θετικό είναι ότι ανεξαρτήτως τον τύπο της βάσης η κλάση αυτή λειτουργεί με τον ίδιο τρόπο (MySQL, PostGre, MSSQL κτλ). Η τεχνική αυτή λέγεται Active Record Database Pattern και έχει αν κάνει με την αλλαγή adapter στην κλάση ανάλογα με τον τύπο της βάσης. Σε κάθε περίπτωση όμως ο τρόπος λειτουργίας της είναι ο ίδιος. Στο παρακάτω τμήμα κώδικα αναφέρεται ένα παράδειγμα για το πως μπορεί να βρεθεί το αναγνωριστικό μιας εγγραφής χρησιμοποιώντας ως κλειδί την διεύθυνση email.
|
||||
Για την διαχείριση των δεδομένων της βάσης δημιουργήθηκαν ειδικές κλάσεις (models) οι οποίες περιέχουν μεθόδους που χρησιμοποιούνται από τους controllers του συστήματος. Το CodeIgniter δίνει στον προγραμματιστή ένα δικό του μέσο επικοινωνίας με την βάση δεδομένων, το οποίο είναι ένα πολύ ισχυρό και ευέλικτο εργαλείο. Η επονομαζόμενη Database Class του CodeIgniter επιτρέπει στον προγραμματιστεί να εκτελεί ερωτήματα προς την βάση, να παράγει αποτελέσματα και να τα αναλύει σε ξεχωριστές εγγραφές, να κρατάει στην μνήμη ερωτήματα για γρηγορότερη ανταπόκριση (query caching) και κυριότερο την κλάση Active Record. Η κλάση αυτή έχει έναν δικό της τρόπο για την εκτέλεση των ερωτημάτων προς την βάση. Όλα τα τμήματα ενός τυπικού ερωτήματος είναι μέθοδοι, οι οποίες χρησιμοποιούνται από τον προγραμματιστή ως το μέσο επικοινωνίας με την βάση δεδομένων. Το θετικό είναι ότι ανεξαρτήτως τον τύπο της βάσης η κλάση αυτή λειτουργεί με τον ίδιο τρόπο (MySQL, PostGre, MSSQL κτλ). Η τεχνική αυτή λέγεται Active Record Database Pattern και έχει να κάνει με την αλλαγή adapter στην κλάση ανάλογα με τον τύπο της βάσης. Σε κάθε περίπτωση όμως ο τρόπος λειτουργίας της είναι ο ίδιος. Στο παρακάτω τμήμα κώδικα αναφέρεται ένα παράδειγμα για το πως μπορεί να βρεθεί το αναγνωριστικό μιας εγγραφής χρησιμοποιώντας ως κλειδί την διεύθυνση email.
|
||||
|
||||
\lstinputlisting{snippets/find_record_id.php}
|
||||
|
||||
%% ==================================================
|
||||
%% ΑΡΧΙΤΕΚΤΟΝΙΚΗ ΚΩΔΙΚΑ
|
||||
%% ==================================================
|
||||
\section{Αρχιτεκτονική Κώδικα}
|
||||
\section{Αρχιτεκτονική κώδικα}
|
||||
Η εφαρμογή είναι γραμμένη χρησιμοποιώντας τις εξής τεχνολογίες: PHP, Javascript, HTML, CSS, MySQL. Εκτός αυτών έχουν χρησιμοποιηθεί και κάποια βοηθητικά εργαλεία τα οποία διευκολύνουν τον προγραμματιστή στο να πετύχει καλύτερο αποτέλεσμα σε μικρότερο χρόνο. Αυτά τα εργαλεία (frameworks) όπως έχουν αναφερθεί και σε προηγούμενο κεφάλαιο είναι τα CodeIgniter (PHP), jQuery (Javascript), Bootstrap (CSS + Javascript).
|
||||
|
||||
Όσον αφορά την αρχιτεκτονική του κώδικα έχει επιλεχθεί το μοντέλο MVC (Model - View - Controller) και αυτό υλοποιείται με την χρήση του CodeIgniter με άριστη απόδοση. Ο κώδικας PHP έχει χωριστεί σε τρία μέρη και έτσι χρησιμοποιείται σε όλη την εφαρμογή. Με αυτόν τον τρόπο βελτιώνονται οι συνθήκες συντήρησης γιατί είναι ξεκάθαρο σε ποιο από τα τρία ξεχωριστά σημεία ανήκει ένα τμήμα κώδικα. Έχουν συγγραφεί και δοκιμαστεί κλάσεις models για κάθε οντότητα οι οποίες αναλαμβάνουν την διαχείριση των δεδομένων με την βάση. Επίσης έχουν δημιουργηθεί views για κάθε σελίδα που πιθανόν θα δει ο χρήστης τα οποία συνδέονται με ένα κομμάτι CSS κώδικα, υπεύθυνο για την μορφοποίηση της σελίδας. Τέλος τον συντονισμό των προηγούμενων αναλαμβάνουν οι κλάσεις controllers οι οποίες είτε είναι υπεύθυνες για την σωστή φόρτωση μιας σελίδας της εφαρμογής είτε απαντούν σε κλήσεις της JavaScript που γίνονται μέσω της τεχνολογίας AJAX.
|
||||
Όσον αφορά την αρχιτεκτονική του κώδικα έχει επιλεχθεί το μοντέλο MVC (Model - View - Controller) το οποίο υλοποιείται με άριστη απόδοση και οργάνωση χάρη στο framework CodeIgniter. Ο κώδικας PHP έχει χωριστεί σε τρία μέρη (models, views, controllers) και με αυτόν τον τρόπο παραμένει σε όλο τον κώδικα της εφαρμογής. Ο διαχωρισμός αυτός βελτιώνει τις συνθήκες συντήρησης γιατί είναι ξεκάθαρο σε ποιο από τα τρία ξεχωριστά σημεία ανήκει μια λειτουργία, όταν αυτή αναζητείται από τον προγραμματιστή. Έχουν συγγραφεί και δοκιμαστεί κλάσεις models για κάθε οντότητα οι οποίες αναλαμβάνουν την διαχείριση των δεδομένων με την βάση και παρέχουν μεθόδους που επαναχρησιμοποιούνται σε διάφορες περιπτώσεις. Επίσης έχουν δημιουργηθεί views για κάθε σελίδα που μπορεί να δει ο χρήστης τα οποία συνδέονται με ένα κομμάτι CSS κώδικα, υπεύθυνο για την μορφοποίησή τους. Τέλος τον συντονισμό αυτών των τμημάτων αναλαμβάνουν οι κλάσεις controllers οι οποίες είτε είναι υπεύθυνες για την σωστή φόρτωση μιας σελίδας της εφαρμογής, είτε απαντούν σε κλήσεις της JavaScript που γίνονται μέσω της τεχνολογίας AJAX.
|
||||
|
||||
Πολύ μεγάλο μέρος της εφαρμογής έχει γραφτεί σε JavaScript για να μπορέσει το περιβάλλον εργασίας του χρήστη να γίνει αρκετά φιλικό και οικείο. Το κομμάτι JavaScript κώδικα χωρίζεται σε διάφορες κλάσεις και namespace τα οποία χρησιμοποιούνται από μια ή και παραπάνω σελίδες και στόχο έχουν να "ζωντανέψουν" το περιεχόμενο προσθέτοντας διαδραστικότητα. Πολλές φορές είναι απαραίτητο να εκτελεστούν κλήσεις AJAX προς τον server για την λήψη πρόσθετων πληροφοριών, είτε για να αποσταλούν δεδομένα τα οποία σηματοδοτούν για παράδειγμα κάποια επεξεργασία ή και διαγραφή εγγραφής από την βάση δεδομένων. Το framework jQuery αποτελεί σημαντικό εργαλείο για την διεκπεραίωση αυτής της λειτουργίας διότι δίνει την δυνατότητα στον προγραμματιστή να γράψει κώδικα όμορφα δομημένο και πολύ αποδοτικό, από ότι θα ήταν χωρίς την χρήση του. Αυτή η ιδιότητα της βιβλιοθήκης συντελεί και στην δημοτικότητά της και την χρήση της από κολοσσούς ανάπτυξης λογισμικού.
|
||||
Πολύ μεγάλο μέρος της εφαρμογής έχει γραφεί σε JavaScript για να μπορέσει το περιβάλλον εργασίας του χρήστη να γίνει αρκετά φιλικό και λειτουργικό. Ο JavaScript κώδικας χωρίζεται σε διάφορες κλάσεις και namespace τα οποία χρησιμοποιούνται από μια ή και παραπάνω σελίδες και στόχο έχουν να "ζωντανέψουν" το περιεχόμενο προσθέτοντας διαδραστικότητα. Πολλές φορές είναι απαραίτητο να εκτελεστούν κλήσεις AJAX προς τον server για την λήψη πρόσθετων πληροφοριών, είτε για να αποσταλούν δεδομένα τα οποία σηματοδοτούν για παράδειγμα κάποια επεξεργασία ή και διαγραφή εγγραφής από την βάση δεδομένων. Η χρήση του AJAX κρίνεται σημαντική διότι με αυτήν αποφεύγονται οι συνεχείς επαναφορτώσεις των σελίδων, οι οποίες θα γινόταν για να μπορέσει ο client να επικοινωνήσει με τον server. Αυτό το κομμάτι αναλαμβάνεται εξ ολοκλήρου από την JavaScript και προσδίδει ευελιξία και ταχύτητα στην χρήση της εφαρμογής. Το framework jQuery αποτελεί σημαντικό εργαλείο για την διεκπεραίωση διαφόρων λειτουργιών μέσω της JavaScript διότι δίνει την δυνατότητα στον προγραμματιστή να γράψει κώδικα όμορφα δομημένο και πολύ πιο αποδοτικό από ότι θα ήταν χωρίς την χρήση του. Αυτή η ιδιότητα της βιβλιοθήκης συντελεί και στην δημοτικότητά της και την χρήση της από κολοσσούς ανάπτυξης λογισμικού.
|
||||
|
||||
Για την μορφοποίηση των σελίδων της εφαρμογής χρησιμοποιήθηκε το πιο διαδεδομένο CSS framework αυτήν την περίοδο, το Bootstap. Χρησιμοποιώντας αυτό το framework γράφτηκε νέο CSS το οποίο μορφοποιεί τις σελίδες έτσι ώστε να ανταποκρίνονται όπως πρέπει σε διάφορα μεγέθη οθονών.
|
||||
Για την μορφοποίηση των σελίδων της εφαρμογής χρησιμοποιήθηκε το πιο διαδεδομένο CSS framework την συγκεκριμένη την περίοδο, το Bootstap. Χρησιμοποιώντας αυτό το framework γράφτηκε νέο CSS το οποίο μορφοποιεί τις σελίδες έτσι ώστε να ανταποκρίνονται όπως πρέπει σε διάφορα μεγέθη οθονών, ενώ παράλληλα δεν χαλάει την συμβατότητα μεταξύ των διάφορων περιηγητών διαδικτύου. Το Bootstrap περιέχει και κάποια πρόσθετα JavaScript τα οποία βοηθούν σημαντικά στο οπτικό αποτέλεσμα της διεπαφής χρήστη.
|
||||
|
||||
Στο παρακάτω σχεδιάγραμμα γίνεται σαφής ο διαχωρισμός του κώδικα του συστήματος στα διάφορα τμήματα που το απαρτίζουν και η χρήση των εξωτερικών εργαλείων που συντέλεσαν στην ορθή ανάπτυξη της εφαρμογής.
|
||||
|
||||
|
@ -51,39 +57,39 @@
|
|||
%% ==================================================
|
||||
%% ΥΛΟΠΟΙΗΣΗ ΣΥΣΤΗΜΑΤΟΣ
|
||||
%% ==================================================
|
||||
\section{Υλοποίηση Συστήματος}
|
||||
\section{Υλοποίηση συστήματος}
|
||||
Εφόσον ο αρχικός σχεδιασμός είχε ολοκληρωθεί ξεκίνησε η υλοποίηση της εφαρμογής με πρώτη εργασία τον σχεδιασμό της βάσης δεδομένων. Έχοντας ήδη σχεδιασμένο το domain model η δημιουργία του σχήματος της βάσης έγινε γρήγορα και διατηρήθηκε ως την ολοκλήρωση του έργου με μικρές προσθήκες όπου ήταν απαραίτητο.
|
||||
|
||||
Στην συνέχεια, πριν γραφεί κώδικας θα έπρεπε να γίνει η επιλογή και το στήσιμο των εξωτερικών βιβλιοθηκών που θα κρίνονταν απαραίτητα για την λειτουργία του συστήματος. Σε αυτήν την φάση επιλέχθηκαν οι βασικές βιβλιοθήκες (CodeIgniter, Google API Library, jQuery, Bootstrap) και επιλέχθηκε η σημαντικότερη περίπτωση χρήσης για να υλοποιηθεί πρώτη. Αυτή δεν ήταν άλλη από την κράτηση ενός ραντεβού από τον πελάτη. Επιλέχθηκε αυτή η περίπτωση χρήσης γιατί με αυτόν τον τρόπο θα καθορίζονταν εν μέρη και η αρχιτεκτονική του συστήματος καθώς αυτό θα εξελισσόταν σταδιακά με την ολοκλήρωση και των υπόλοιπων περιπτώσεων χρήσης.
|
||||
Στην συνέχεια, πριν γραφεί κώδικας θα έπρεπε να γίνει η επιλογή και το στήσιμο των εξωτερικών βιβλιοθηκών που θα κρίνονταν απαραίτητα για την λειτουργία του συστήματος. Σε αυτήν την φάση επιλέχθηκαν οι βασικές βιβλιοθήκες (CodeIgniter, Google API Library, jQuery, Bootstrap) καθώς και η σημαντικότερη περίπτωση χρήσης για να υλοποιηθεί πρώτη. Αυτή δεν ήταν άλλη από την κράτηση ενός ραντεβού από τον πελάτη. Αυτή η απόφαση πάρθηκε γιατί με αυτόν τον τρόπο θα καθορίζονταν εν μέρη και η αρχιτεκτονική του συστήματος καθώς αυτό θα εξελισσόταν σταδιακά με την ολοκλήρωση και των υπόλοιπων περιπτώσεων χρήσης.
|
||||
|
||||
Η κύρια ροή εργασιών ως προς την υλοποίηση μιας περίπτωσης χρήσης αποτελείτε από τα παρακάτω βήματα:
|
||||
Η κύρια ροή εργασιών ως προς την υλοποίηση μιας περίπτωσης χρήσης αποτελείται από τα παρακάτω βήματα:
|
||||
\begin{enumerate}
|
||||
\item Συγγραφή της κλάσης model για την συγκεκριμένη οντότητα. Μερικές φορές αυτή η διαδικασία μπορεί να συμπεριλάμβανε και την δημιουργία model και για άλλες οντότητες που εμπλέκονταν στην περίπτωση χρήσης, έτσι ώστε να μπορέσει να λειτουργήσει σωστά ο κώδικας.
|
||||
\item Έλεγχος των model με δημιουργία unit tests. Μετά την ολοκλήρωση των model αυτά θα έπρεπε να δοκιμαστούν έτσι ώστε να διασφαλιστεί η σωστή λειτουργία τους. Εκτός αυτού όμως η συγγραφή unit test είναι και μια καλή ευκαιρία ως παράδειγμα της χρήσης των model από το υπόλοιπο σύστημα. Αν εντοπιζόταν κάποιο πρόβλημα κατά την εκτέλεση των test αυτό διορθωνόταν και τα test εντελλόντουσαν πάλι έως ότου να ολοκληρωθούν όλα με επιτυχία.
|
||||
\item Εφόσον τα model ήταν ολοκληρωμένα στην συνέχεια δημιουργήθηκαν οι controllers και οι αντίστοιχες συναρτήσεις που θα ήταν υπεύθυνες για την λειτουργία του view που αντιστοιχούσε στην τρέχον περίπτωση χρήσης. Έτσι εκτός από τις συναρτήσεις που αναλάμβαναν να φορτώσουν μια σελίδα της εφαρμογής συγκεντρώνοντας τα δεδομένα που ήταν απαραίτητα, υλοποιήθηκαν και οι κλήσεις AJAX που ήταν απαραίτητες από την JavaScript. Αυτές οι κλήσεις συνήθως αναλάμβαναν την διεκπεραίωση κάποιας ενέργειας προς την βάση δεδομένων και επέστρεφαν πάντα κάποιο αποτέλεσμα για να μπορέσει να συνεχίσει την λειτουργία της το τμήμα της JavaScript.
|
||||
\item Στην συνέχεια υλοποιούνταν το αντίστοιχο view που θα έβλεπε ο χρήστης. Σε αυτό τοποθετούταν ο κώδικας PHP, HTML και η μορφοποίηση της σελίδας (CSS) γράφοταν στο αντίστοιχο αρχείο έτσι ώστε να παραχθεί ένα αποτέλεσμα φιλικό προς τον χρήστη.
|
||||
\item Συγγραφή της κλάσης model για την συγκεκριμένη οντότητα. Μερικές φορές αυτή η διαδικασία μπορεί να συμπεριλάμβανε και την δημιουργία model και για άλλες οντότητες που εμπλέκονταν στην περίπτωση χρήσης, έτσι ώστε να μπορέσει να λειτουργήσει σωστά ο κώδικας συνολικά. Οι περισσότερες κλάσεις ακολουθούν το ίδιο πρότυπο σχεδίασης και μεθόδων με μικρές διαφοροποιήσεις ανάλογα με την οντότητα που διαχειρίζονται.
|
||||
\item Έλεγχος των model με δημιουργία unit tests. Μετά την ολοκλήρωση των model αυτά θα έπρεπε να δοκιμαστούν έτσι ώστε να διασφαλιστεί η σωστή λειτουργία τους. Εκτός αυτού όμως η συγγραφή unit test είναι και μια καλή ευκαιρία ως παράδειγμα της χρήσης των model από το υπόλοιπο σύστημα. Αν εντοπιζόταν κάποιο πρόβλημα κατά την εκτέλεση των test αυτό διορθωνόταν και τα test εκτελόντουσαν πάλι έως ότου να ολοκληρωθούν όλα με επιτυχία.
|
||||
\item Εφόσον τα model ήταν ολοκληρωμένα στην συνέχεια δημιουργήθηκαν οι controllers και οι αντίστοιχες συναρτήσεις που θα ήταν υπεύθυνες για την λειτουργία του view που αντιστοιχούσε στην εκάστοτε περίπτωση χρήσης. Έτσι εκτός από τις συναρτήσεις που αναλάμβαναν να φορτώσουν μια σελίδα της εφαρμογής συγκεντρώνοντας τα δεδομένα που ήταν απαραίτητα, υλοποιήθηκαν και οι κλήσεις AJAX που ήταν απαραίτητες από την JavaScript. Αυτές οι κλήσεις συνήθως αναλάμβαναν την διεκπεραίωση κάποιας ενέργειας προς την βάση δεδομένων και επέστρεφαν πάντα κάποιο αποτέλεσμα για να μπορέσει να συνεχίσει την λειτουργία της το τμήμα της JavaScript.
|
||||
\item Στην συνέχεια υλοποιούνταν το αντίστοιχο view που θα έβλεπε ο χρήστης. Σε αυτό τοποθετούνταν ο κώδικας PHP, HTML και η μορφοποίηση της σελίδας (CSS) γραφόταν στο αντίστοιχο αρχείο css έτσι ώστε να παραχθεί ένα καλαίσθητο και φιλικό αποτέλεσμα.
|
||||
\item Όταν το view ήταν έτοιμο θα έπρεπε να του προστεθεί και κάποια λειτουργικότητα έτσι ώστε να μπορεί να ανταποκριθεί στις ενέργειες του χρήστη. Για κάθε σελίδα χρησιμοποιούνται μια πληθώρα από βιβλιοθήκες, namespaces, κλάσεις και πρόσθετα JavaScript. Στα αντίστοιχα αρχεία τοποθετήθηκε ο κώδικας που θα ρύθμιζε την λειτουργία της σελίδας και τις ασύγχρονες κλήσεις προς τον server (AJAX).
|
||||
\item Τέλος εφόσον όλα ήταν έτοιμα και η περίπτωση χρήσης είχε υλοποιηθεί χωρίς προβλήματα, όλος ο κώδικας που είχε γραφεί έπρεπε να εξεταστεί (review) για τυχόν προβλήματα λογικής και για την βελτίωση της απόδοσης του κώδικα, μικραίνοντας όσο είναι δυνατόν την σύζευξη και αυξάνοντας την συνοχή.
|
||||
\item Τέλος εφόσον όλα ήταν έτοιμα και η περίπτωση χρήσης είχε υλοποιηθεί χωρίς προβλήματα, όλος ο κώδικας που είχε γραφεί έπρεπε να εξεταστεί (review) για τυχόν προβλήματα λογικής και για την βελτίωση της απόδοσης του, μικραίνοντας όσο είναι δυνατόν την σύζευξη και αυξάνοντας την συνοχή.
|
||||
\end{enumerate}
|
||||
|
||||
Εδώ θα χρειαστεί να αναφερθεί ότι όλες οι κλήσεις AJAX έχουν μεταφερθεί σε μια κλάση controller, ξεχωριστά από τον κύριο controller του backend για να είναι καλύτερα οργανωμένες. Αν μελλοντικά ο αριθμός τους και η πολυπλοκότητα τους αυξηθεί τότε θα χρειαστεί να διαιρεθούν ξανά για να μπορέσουν να συντηρούνται πιο εύκολα.
|
||||
Εδώ θα χρειαστεί να αναφερθεί ότι όλες οι κλήσεις AJAX που αφορούν το backend έχουν μεταφερθεί σε μια κλάση controller, ξεχωριστά από τον κύριο controller του backend για να είναι καλύτερα οργανωμένες. Αν μελλοντικά ο αριθμός τους και η πολυπλοκότητα τους αυξηθεί τότε θα χρειαστεί να διαιρεθούν ξανά για να μπορέσουν να συντηρούνται πιο εύκολα.
|
||||
|
||||
%% ==================================================
|
||||
%% ΠΕΡΙΓΡΑΦΗ ΒΑΣΙΚΩΝ ΑΛΓΟΡΙΘΜΩΝ
|
||||
%% ==================================================
|
||||
\section{Περιγραφή Βασικών Αλγορίθμων}
|
||||
Σε αυτήν την ενότητα θα γίνει ανάλυση κάποιων βασικών αλγορίθμων που αποτελούν κρίσιμα τμήματα για την λειτουργία του συστήματος. Η περιγραφή θα γίνει σχολιάζοντας τα τμήματα κώδικα που απαρτίζουν αυτούς τους αλγορίθμους. Στην επόμενη ενότητα παρέχονται κάποια σχεδιαγράμματα τα οποία μπορούν να βοηθήσουν στην κατανόηση των αλγορίθμων αυτών.
|
||||
\section{Περιγραφή βασικών αλγορίθμων}
|
||||
Σε αυτήν την ενότητα θα γίνει ανάλυση κάποιων βασικών αλγορίθμων που αποτελούν κρίσιμα τμήματα για την λειτουργία του συστήματος. Η περιγραφή θα γίνει σχολιάζοντας τα τμήματα κώδικα που απαρτίζουν αυτούς τους αλγορίθμους αναφέροντας και τις συγκεκριμένες γραμμές στον οποίο αναφέρεται. Στην επόμενη ενότητα παρέχονται κάποια σχεδιαγράμματα τα οποία μπορούν να βοηθήσουν στην κατανόηση αυτών των αλγορίθμων.
|
||||
|
||||
\subsection{Πλήρης Συγχρονισμός Google Calendar}
|
||||
Η διαδικασία του πλήρη συγχρονισμού των ραντεβού με το Google Calendar αποτελεί ένας από τους κυριότερους αλγορίθμους του Easy!Appointments. Η πολυπλοκότητα της διαδικασίας συγχρονισμού δεδομένων κατέστησαν την υλοποίηση αυτού του τμήματος κώδικα αρκετά ενδιαφέρον και το αποτέλεσμα κατάφερε να καλύψει τις αρχικές απαιτήσεις. Μπορεί μελλοντικά να υπάρξουν βελτιώσεις στον κώδικα, αλλά την συγκεκριμένη στιγμή ο αλγόριθμος λειτουργεί επιτυχώς και συγχρονίζει τα ραντεβού του συστήματος με τα συμβάντα που έχει περάσει ο χρήστης στο Google Calendar με επιτυχία.
|
||||
\subsection{Πλήρης συγχρονισμός με το Google Calendar}
|
||||
Η διαδικασία του πλήρη συγχρονισμού των ραντεβού με το Google Calendar αποτελεί ένας από τους κυριότερους αλγορίθμους του Easy!Appointments. Η πολυπλοκότητα της διαδικασίας συγχρονισμού δεδομένων κατέστησαν την υλοποίηση αυτού του τμήματος κώδικα αρκετά ενδιαφέρον και το αποτέλεσμα κατάφερε να καλύψει τις αρχικές απαιτήσεις. Μπορεί μελλοντικά να υπάρξουν βελτιώσεις στον κώδικα, αλλά την συγκεκριμένη στιγμή ο αλγόριθμος λειτουργεί επιτυχώς και συγχρονίζει τα ραντεβού του συστήματος με τα συμβάντα που έχει περάσει ο χρήστης στο Google Calendar.
|
||||
|
||||
\lstinputlisting{snippets/google_sync_algorithm.php}
|
||||
|
||||
Η μέθοδος αυτή καλείται κάθε φορά που πρέπει να τρέξει ο αλγόριθμος συγχρονισμού για έναν πάροχο υπηρεσιών. Στο πρώτο μέρος του κώδικα ελέγχεται αν ο χρήστης έχει τα δικαιώματα να τρέξει αυτήν την μέθοδο και αν έχει δοθεί το αναγνωριστικό της εγγραφής του πάροχου. Έπειτα φορτώνονται τα απαραίτητα models και γίνεται η λήψη των πληροφοριών του πάροχου από την βάση (γραμμές 17 - 31).
|
||||
|
||||
Για να συνεχιστεί η διαδικασία θα πρέπει να ελεγχθεί αν ο πάροχος έχει ενεργό τον συγχρονισμό με το Google Calendar. Αν η επιλογή αυτή είναι ενεργή τότε ο αλγόριθμος χρησιμοποιεί το token του πάροχου για να πιστοποιήσει την χρήση των δεδομένων του στο Google Calendar (γραμμές 34 - 44).
|
||||
Για να συνεχιστεί η διαδικασία θα πρέπει να ελεγχθεί αν ο πάροχος έχει ενεργό τον συγχρονισμό με το Google Calendar. Αν η επιλογή αυτή είναι ενεργή τότε ο αλγόριθμος χρησιμοποιεί το token του πάροχου για να πιστοποιήσει την χρήση των δεδομένων του στο Google Calendar, διαφορετικά η διαδικασία τερματίζεται (γραμμές 34 - 44).
|
||||
|
||||
Για να γίνει εξοικονόμηση κλήσεων αλλά και να μειωθεί ο χρόνος διεκπεραίωσης του αλγορίθμου συγχρονισμού το χρονικό διάστημα μέσα στο οποίο θα συγχρονισθούν τα δεδομένα περιορίζεται στο εύρος που έχει τεθεί ως ρύθμιση για τον κάθε χρήστη πάροχο (προεπιλεγμένη τιμή 5 ημέρες στο παρελθόν και 5 στο μέλλον). Αυτό είναι το χρονικό διάστημα στο οποίο θα ελεγχθούν όλα τα δεδομένα και από τα δύο συστήματα και θα συντονιστούν έτσι ώστε να είναι τα ίδια (γραμμές 48 - 55).
|
||||
Για να γίνει εξοικονόμηση κλήσεων προς την υπηρεσία της Google αλλά και να μειωθεί ο χρόνος διεκπεραίωσης του αλγορίθμου συγχρονισμού, το χρονικό διάστημα μέσα στο οποίο θα συγχρονισθούν τα δεδομένα περιορίζεται στο εύρος ημερών που έχει τεθεί ως ρύθμιση για τον κάθε πάροχο (προεπιλεγμένη τιμή 5 ημέρες στο παρελθόν και 5 στο μέλλον). Αυτό είναι το χρονικό διάστημα στο οποίο θα ελεγχθούν όλα τα δεδομένα και από τα δύο συστήματα και θα συντονιστούν έτσι ώστε να είναι τα ίδια (γραμμές 48 - 55).
|
||||
|
||||
Το επόμενο κομμάτι κώδικα αφού πρώτα λάβει τα ραντεβού από την βάση δεδομένων του Easy!Appointments, εξετάζει τις εγγραφές μια προς μια για το αν έχουν συγχρονιστεί με το Google Calendar. Εδώ υπάρχουν οι εξής περιπτώσεις:
|
||||
\begin{enumerate}
|
||||
|
@ -97,7 +103,7 @@
|
|||
|
||||
Αυτήν την εργασία αναλαμβάνει το επόμενο κομμάτι κώδικα το οποίο χρησιμοποιώντας την βιβλιοθήκη Google API μπορεί να διαβάσει τα συμβάντα τα οποία βρίσκονται στο Google Calendar. Η διαδικασία ξεκινάει με την λήψη αυτών των συμβάντων τα οποία στην συνέχεια εξετάζονται ένα προς ένα για το αν υπάρχουν στο Easy!Appointments. Αν όχι τότε προστίθενται και συγχρονίζονται και στα δύο συστήματα και έτσι διασφαλίζεται η ακεραιότητα των δεδομένων και στα δύο συστήματα (γραμμές 129 - 152).
|
||||
|
||||
\subsection{Υπολογισμός Διαθέσιμων Ωρών Πάροχου}
|
||||
\subsection{Υπολογισμός διαθέσιμων ωρών πάροχου}
|
||||
Ένα κομβικό σημείο στον κώδικα της εφαρμογής είναι ο υπολογισμός των διαθέσιμων ωρών ενός πάρoχου, στις οποίες μπορεί ένας πελάτης να κλείσει ένα ραντεβού για μια υπηρεσία, χωρίς να υπάρχει σύγκρουση με άλλα συμβάντα. Για να επιτευχθεί ο υπολογισμός αυτός χρειάζεται να γίνουν αρκετοί έλεγχοι έτσι ώστε τα αποτελέσματα να είναι σωστά και να μην δημιουργούνται προβλήματα με τα πλάνα των πάροχων υπηρεσιών. Η διαδικασία χωρίζεται σε δύο μεθόδους με την πρώτη να υπολογίζει τα ελεύθερα χρονικά διαστήματα του πάροχου και την δεύτερη να υπολογίζει τις ακριβείς ώρες στις οποίες θα μπορεί ο πελάτης να κλείσει ραντεβού.
|
||||
|
||||
\lstinputlisting{snippets/provider_available_periods.php}
|
||||
|
@ -122,7 +128,7 @@
|
|||
|
||||
Η εφαρμογή που χρησιμοποιήθηκε για τον σχεδιασμό των διαγραμμάτων αυτών είναι η draw.io και πρόκειται για μια διαδικτυακή πλατφόρμα με την οποία μπορούν να γίνουν σχεδιαγράμματα πολλών διαφορετικών τύπων. Το draw.io είναι δωρεάν προς χρήση και μπορεί να βρεθεί στην διεύθυνση http://www.draw.io.
|
||||
|
||||
\subsection{Διαγράμματα Ροής}
|
||||
\subsection{Διαγράμματα ροής}
|
||||
Τα διαγράμματα ροής δείχνουν τον τρόπο και την σειρά με την οποία λειτουργούν οι διεργασίες και τα αντικείμενα μεταξύ τους για την διεκπεραίωση ενός σκοπού. Σε αυτά είναι εύκολο να διακριθούν ποιοι ηθοποιοί, αντικείμενα, διεπαφές και μέθοδοι αλληλεπιδρούν έτσι ώστε τα δεδομένα που χρειάζονται για την εργασία να παραχθούν επιτυχώς και να φτάσουν ακέραια στον προορισμό τους. Σε αυτά τα διαγράμματα ο χρονικός προσδιορισμός της κάθε αλληλεπίδρασης είναι εμφανής και πολύ σημαντικός για να μπορέσει ο προγραμματιστής να καταλάβει με ποια σειρά θα πρέπει να πορευτεί η εκτέλεση έτσι ώστε αυτός να καταλήξει σε σωστό αποτέλεσμα. Συνήθως τα διαγράμματα ροής συγχέονται με το σενάριο κάποιας περίπτωσης χρήσης αλλά μπορούν να διασπαστούν και σε μικρότερα τμήματα τα οποία να επικεντρώνουν στα σημεία που είναι πιο σημαντικά.
|
||||
|
||||
\begin{figure}%% [Η] αυτή η εντολή θα τοποθετήσει το διάγραμμα ακριβώς σε αυτό το σημείο. Το latex όμως πάντα προσπαθεί να αφήσει όσο λιγότερα κενό χόρο γίνεται και έτσι τα διαγράμματα δεν θα εμφανιστούν με την σειρά που γράφονται στον κώδικα.
|
||||
|
@ -139,7 +145,7 @@
|
|||
\label{sd-save-appointment}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Διαγράμματα Δραστηριότητας}
|
||||
\subsection{Διαγράμματα δραστηριότητας}
|
||||
Τα διαγράμματα δραστηριότητας αποτελούν γραφικές παρουσιάσεις της δραστηριότητας του που ακολουθεί το σύστημα ανάλογα με τις αποφάσεις που λαμβάνονται μέσα από τον κώδικα. Σε αυτά τα διαγράμματα μπορούν να φανούν τα σημεία στα οποία υπάρχουν βρόγχοι επανάληψης, τα σημεία όπου μπορούν να συμβούν λογικά σφάλματα (οι απαιτήσεις για συνέχιση της εκτέλεσης δεν πληρούνται) όπως και επίσης τις διαδικασίες που τρέχουν ταυτόχρονα και σε ποιο σημείο γίνεται αυτό. Κατά κύριο λόγο τα διαγράμματα δραστηριότητας δείχνει την συνολική ροή του ελέγχου μέσα από την εκτέλεση μιας συγκεκριμένης διαδικασίας.
|
||||
|
||||
\begin{figure}
|
||||
|
@ -170,7 +176,7 @@
|
|||
\label{ad-provider-available-hours}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Διαγράμματα Κλάσεων}
|
||||
\subsection{Διαγράμματα κλάσεων}
|
||||
Στην τεχνολογία λογισμικού, τα διαγράμματα κλάσεων περιγράφουν την στατική δομή ενός συστήματος δείχνοντας τις κλάσεις, τις ιδιότητες, τις λειτουργίες και τις σχέσεις μεταξύ των αντικειμένων. Το σχεδιαγράμματα αυτά είναι τα βασικότερα για έναν προγραμματιστή διότι μπορεί άμεσα να πληροφορηθεί σχετικά με την δομή του κώδικα και με ποιόν τρόπο θα πρέπει να συνεχιστεί η διαδικασία της υλοποίησης. Επίσης είναι εμφανές και οι αρχιτεκτονικές επιλογές που έχουν γίνει καθώς κάθε σχεδιαστικό πρότυπο που πρέπει να έχει ο κώδικας μπορεί να διακριθεί και να περιγραφή σε αυτά τα διαγράμματα. Καλή πρακτική είναι πάντα ένα διάγραμμα να περιέχει μόνο την ουσία οπότε στο υποκεφάλαιο αυτό εμφανίζονται διαγράμματα κλάσης τα οποία δείχνουν κάποιες σχεδιαστικές επιλογές που έχουν γίνει στην εφαρμογή.
|
||||
|
||||
\begin{figure}
|
||||
|
|
|
@ -1,91 +1,40 @@
|
|||
\chapter{Έλεγχος του Συστήματος}
|
||||
%% ΕΛΕΓΧΟΣ ΣΥΣΤΗΜΑΤΟΣ
|
||||
%% Το μέρος του εγγράφου αυτού περιέχει την περιγραφή της διαδικασίας
|
||||
%% ελέγχου που χρησιμοποιείθηκε για την διασφάλιση της σωστής λειτουργίας
|
||||
%% της εφαρμογής.
|
||||
|
||||
\chapter{Έλεγχος Συστήματος}
|
||||
Σε κάθε τομέα παραγωγής προϊόντων είναι πολύ σημαντικό να παράγονται προϊόντα τα οποία να τηρούν πάντα τις προδιαγραφές τους και να μπορούν να αντεπεξέλθουν στις απαιτήσεις του καταναλωτικού κοινού. Η φήμη και η εμπιστοσύνη που προσδίδει μια εταιρεία είναι κομβικά χαρακτηριστικά για την βιωσιμότητας της. Κάθε επαγγελματίας είναι απαραίτητο να είναι σε θέση να εγγυηθεί για την ποιότητα του προϊόντος ή της υπηρεσίας που παρέχει ως αντάλλαγμα της αμοιβής του.
|
||||
|
||||
Ο τρόπος διασφάλισης της ποιότητας διαφέρει ανάλογα με την φύση του προϊόντος ή της υπηρεσίας και μπορεί να εκτελεστεί με διάφορους μεθόδους. Για παράδειγμα αν το προϊόν ήταν κάποιο τρόφιμο, η εταιρία θα έπρεπε να είναι σίγουρη ότι είναι σε άριστη κατάσταση πριν φτάσει στο τραπέζι του καταναλωτή, διότι αν δεν το έκανε αυτό θα υπήρχαν επιπλοκές στην υγεία των καταναλωτών. Αντίστοιχα μια εταιρία που παρέχει μια υπηρεσία πρέπει να διασφαλίσει και να ελέγξει την ποιότητα παροχής της υπηρεσίας με διάφορους τρόπους. Ένας από αυτούς θα ήταν να λαμβάνει τις παρατηρήσεις των καταναλωτών αφότου λάβουν την υπηρεσία ή να περνάει από εσωτερικές εξετάσεις και εκπαίδευση τους υπαλλήλους της έτσι ώστε να είναι σίγουρη ότι αυτοί θα μπορούν να παρέχουν σωστά και αξιόπιστα την υπηρεσία στους πελάτες.
|
||||
|
||||
Στην διαδικασία ανάπτυξης λογισμικού υπάρχουν αντίστοιχα διάφοροι τρόποι ελέγχου ότι το λογισμικό που αναπτύσσεται τηρεί τις προδιαγραφές του. Κάποιοι από αυτούς τους τρόπους είναι τα unit testing, fuzz testing, δημοσίευση δοκιμαστική έκδοσης (beta version) κ.α. Το πιο κοντινό εργαλείο ελέγχου στον προγραμματιστή είναι η διαδικασία unit testing, η οποία εφαρμόζεται αποκλειστικά σε αντικειμενοστραφή κώδικα. Παρακάτω θα γίνει μια ανάλυση αυτής της τεχνικής ελέγχου και θα αναφερθούν οι μέθοδοι και η διαδικασία ελέγχου πάνω στο Easy!Appointments.
|
||||
|
||||
\section {Unit Testing}
|
||||
\section {Unit testing}
|
||||
Για την υλοποίηση unit tests πάνω στον κώδικα είναι απαραίτητο να τηρούνται δύο πράγματα: (1) η αντικειμενοστραφείς δομή και (2) η χρήση κάποιας βιβλιοθήκης ή εργαλείου το οποίο μπορεί να βοηθήσει στην οργάνωση και καλύτερη υλοποίηση των tests.
|
||||
|
||||
Με τον όρο unit testing εννοείται η δοκιμή μίας “λειτουργικής μονάδας” του λογισμικού που αναπτύσσεται. Η κάθε λειτουργική μονάδα απομονώνεται από τις υπόλοιπες και δοκιμάζεται ξεχωριστά σε διάφορες καταστάσης. Για αυτόν τον λόγο είναι απαραίτητο ο κώδικας να έχει αντικειμενοστραφής δομή. Η διαδικασία χωρίζεται στην συγγραφή πολλαπλών unit test, συναρτήσεων δηλαδή που δοκιμάζουν μια διαδικασία για συγκεκριμένες τιμές εισόδου. Σε κάθε περίπτωση στόχος είναι να υπάρχει ελεγχόμενη έξοδος έτσι ώστε να μπορέσει ο προγραμματιστής να είναι σίγουρος ότι το σύστημα θα λειτουργήσει σωστά σε οποιαδήποτε κατάσταση και αν βρίσκεται. Κατά την διαδικασία αυτήν μπορούν να βρεθούν πολύ εύκολα πολλά προβλήματα και ασυνέπειες στον κώδικα ενός συστήματος, τα οποία χρειάζεται να αντιμετωπιστούν.
|
||||
Με τον όρο unit testing εννοείται η δοκιμή μίας “λειτουργικής μονάδας” του λογισμικού που αναπτύσσεται. Η κάθε λειτουργική μονάδα απομονώνεται από τις υπόλοιπες και δοκιμάζεται ξεχωριστά σε διάφορες κατάστασης. Για αυτόν τον λόγο είναι απαραίτητο ο κώδικας να έχει αντικειμενοστραφής δομή. Η διαδικασία χωρίζεται στην συγγραφή πολλαπλών unit test, συναρτήσεων δηλαδή που δοκιμάζουν μια διαδικασία για συγκεκριμένες τιμές εισόδου. Σε κάθε περίπτωση στόχος είναι να υπάρχει ελεγχόμενη έξοδος έτσι ώστε να μπορέσει ο προγραμματιστής να είναι σίγουρος ότι το σύστημα θα λειτουργήσει σωστά σε οποιαδήποτε κατάσταση και αν βρίσκεται. Κατά την διαδικασία αυτήν μπορούν να βρεθούν πολύ εύκολα πολλά προβλήματα και ασυνέπειες στον κώδικα ενός συστήματος, τα οποία χρειάζεται να αντιμετωπιστούν.
|
||||
|
||||
Για να μπορέσουν να υλοποιηθούν αυτά τα test είναι απαραίτητο να χρησιμοποιηθεί κάποια βιβλιοθήκη ή εργαλείο, το οποίο θα κατέχει τις βασικές συναρτήσεις ελέγχου αποτελεσμάτων και επιπρόσθετα λειτουργίες για την παραγωγή αναφορών, οι οποίες περιέχουν τα αποτελέσματα των δοκιμών. Υπάρχουν πάρα πολλά εργαλεία που κάνουν αυτήν την δουλειά, το καθένα για μια συγκεκριμένη γλώσσα προγραμματισμού. Τα πιο διαδεδομένα εργαλεία είναι αυτά που ανήκουν στην οικογένεια xUnit (Junit, CppUnit, NUnit κ.α).
|
||||
|
||||
Τα εργαλεία αυτά μπορούν συνήθως κάλλιστα να συνεργαστούν μαζί με άλλα εργαλεία ανάπτυξης έτσι ώστε να είναι πολύ εύκολο για τον προγραμματιστή να συμπεριλάβει την διαδικασία unit testing στην υλοποίηση του κάθε συστήματος.
|
||||
|
||||
\section {Easy!Appointments Testing}
|
||||
Η συγγραφή των unit tests για το Easy!Appointmnets έγινε με την χρήση της ενσωματωμένης βιβλιοθήκης που παρέχει το CodeIginter. Η βιβλιοθήκη παρέχει τις βασικές λειτουργίες ελέγχου και παραγωγής αναφορών για τα tests του κώδικα. Προτιμήθηκε έναντι του phpunit λόγω της καλύτερης απόδοσης σε σχέση με το CodeIgniter Framework.
|
||||
\section {Easy!Appointments testing}
|
||||
Η συγγραφή των unit tests για το Easy!Appointments έγινε με την χρήση της ενσωματωμένης βιβλιοθήκης που παρέχει το CodeIginter. Η βιβλιοθήκη παρέχει τις βασικές λειτουργίες ελέγχου και παραγωγής αναφορών για τα tests του κώδικα. Προτιμήθηκε έναντι του phpunit λόγω της καλύτερης απόδοσης σε σχέση με το CodeIgniter Framework.
|
||||
|
||||
Η διαδικασία της δοκιμής του συστήματος ξεκίνησε από τα Models, τις λειτουργικές μονάδες που διαχειρίζονται την κίνηση προς και από την βάση δεδομένων. Είναι απαραίτητο για το σύστημα να κατέχει ακέραια δεδομένα μιας και όλη η εφαρμογή βασίζεται σε αυτά. Η κάθε μέθοδος του κάθε model δοκιμάστηκε ξεχωριστά από τις υπόλοιπες για 3-5 διαφορετικές περιπτώσεις κάθε φορά. Όσο αναπτύσσεται το σύστημα τόσο αυξάνονται και unit tests.
|
||||
Η διαδικασία της δοκιμής του συστήματος ξεκίνησε από τα models, τις λειτουργικές μονάδες που διαχειρίζονται την κίνηση προς και από την βάση δεδομένων. Είναι απαραίτητο για το σύστημα να κατέχει ακέραια δεδομένα μιας και όλη η εφαρμογή βασίζεται σε αυτά. Η κάθε μέθοδος του κάθε model δοκιμάστηκε ξεχωριστά από τις υπόλοιπες για 3-5 διαφορετικές περιπτώσεις. Όσο αναπτύσσεται το σύστημα τόσο αυξάνονται και unit tests.
|
||||
|
||||
Για την σωστή δοκιμή του συστήματος απομονώθηκε το κάθε model και δοκιμάστηκε ανεξάρτητα από τα υπόλοιπα. Κάθε μέθοδος έχει κατά μέσω όρο 3-5 unit test, κάτι που μελλοντικά μπορεί να αυξηθεί όσο επεκτείνεται η εφαρμογή.
|
||||
Για να γίνει αυτόματη εκτέλεση όλων των unit test που αντιστοιχούν σε ένα συγκεκριμένο model γράφτηκε η παρακάτω μέθοδος η οποία αφού ελέγξει τα ονόματα των test μεθόδων, εκτελεί μόνο εκεί τα οποία ξεκινούν από την λέξη "test". Έτσι αν κάποια μέθοδος δεν είναι έτοιμη ή δεν πρέπει να συμπεριληφθεί στην εκτέλεση των unit test αρκεί να αλλάξει την αρχή του ονοματός της και η μέθοδος δεν θα την λάβει υπόψιν.
|
||||
|
||||
\lstinputlisting{snippets/unit_test_automation.php}
|
||||
|
||||
\section {Παραδείγματα}
|
||||
Στον παρακάτω κώδικα δοκιμάζεται η βασική ροή της περίπτωσης χρήσης “προσθήκη ραντεβού”. Σε αυτό το test case η είσοδος της μεθόδου add() είναι σωστή και έτσι περιμένουμε ότι και το αποτέλεσμα της διαδικασίας θα είναι επιτυχία. Στο τέλος αφαιρούμε την εγγραφή που προστέθηκε για να μην μείνουν κατάλοιπα στην βάση. Σε κάθε unit test χρησιμοποιείται μόνο μια μέθοδος του model. Έτσι το κάθε test δεν επηρεάζεται από τυχόν προβλήματα σε άλλες μεθόδους του model.
|
||||
|
||||
\begingroup
|
||||
\fontsize{10pt}{12pt}
|
||||
\begin{verbatim}
|
||||
/**
|
||||
* Test the appointment add method - insert new record.
|
||||
*/
|
||||
private function test_add_appointment_insert() {
|
||||
// Add - insert new appointment record to the database.
|
||||
$appointment_data = array(
|
||||
'start_datetime' => '2013-05-01 12:30:00',
|
||||
'end_datetime' => '2013-05-01 13:00:00',
|
||||
'notes' => 'Some notes right here...',
|
||||
'id_users_provider' => $this->provider_id,
|
||||
'id_users_customer' => $this->customer_id,
|
||||
'id_services' => $this->service_id
|
||||
);
|
||||
$appointment_data['id'] = $this->CI->Appointments_Model
|
||||
->add($appointment_data);
|
||||
$this->CI->unit->run($appointment_data['id'], 'is_int',
|
||||
'Test if add() appointment (insert operation) '
|
||||
. 'returned the db row id.');
|
||||
|
||||
// Check if the record is the one that was inserted.
|
||||
$db_data = $this->CI->db->get_where('ea_appointments',
|
||||
array('id' => $appointment_data['id']))->row_array();
|
||||
$this->CI->unit->run($appointment_data, $db_data, 'Test if add() '
|
||||
. 'appointment (insert operation) has successfully '
|
||||
. 'inserted a record.');
|
||||
\lstinputlisting{snippets/unit_test_insert_example.php}
|
||||
|
||||
// Delete inserted record.
|
||||
$this->CI->db->delete('ea_appointments',
|
||||
array('id' => $appointment_data['id']));
|
||||
}
|
||||
\end{verbatim}
|
||||
\endgroup
|
||||
Στο παρακάτω unit test δοκιμάζεται η μέθοδος get\_value() η οποία επιστρέφει την τιμή ενός πεδίου από την βάση. Στο συγκεκριμένο test case δίνεται ως παράμετρος ένα id εγγραφής, το οποίο δεν υπάρχει στην βάση. Η αναμενόμενη συμπεριφορά από το model είναι να εμφανιστεί ένα exception το οποίο να ειδοποιεί ότι η εγγραφή με το συγκεκριμένο id δεν βρέθηκε στην βάση.
|
||||
|
||||
\begingroup
|
||||
\fontsize{10pt}{12pt}
|
||||
\begin{verbatim}
|
||||
/**
|
||||
* Test the get field value method with a record id that
|
||||
* doesn't exist in the db.
|
||||
*
|
||||
* A database exception is expected.
|
||||
*/
|
||||
private function test_get_value_record_does_not_exist() {
|
||||
$random_record_id = 843521368768;
|
||||
|
||||
$has_thrown_exception = FALSE;
|
||||
|
||||
try {
|
||||
$this->CI->Appointments_Model
|
||||
->get_value('start_datetime', $random_record_id);
|
||||
} catch (InvalidArgumentException $db_exc) {
|
||||
$has_thrown_exception = TRUE;
|
||||
}
|
||||
|
||||
$this->CI->unit->run($has_thrown_exception, TRUE,
|
||||
'Test get_value() with record id that does not exist.');
|
||||
}
|
||||
\end{verbatim}
|
||||
\endgroup
|
||||
\lstinputlisting{snippets/unit_test_get_value_example.php}
|
||||
|
||||
Κάποια unit test δοκιμάζουν τις μεθόδους για σωστές τιμές και αναμένουν την επιτυχή ολοκλήρωση των διαδικασιών τους. Τα περισσότερα όμως tests σκοπό έχουν να δουν την συμπεριφορά του συστήματος για τιμές οι οποίες δεν είναι φυσιολογικές. Με αυτόν τον τρόπο μπορούν να προβλεφθούν πολλά bug και άλλα προβλήματα στον κώδικα και η εφαρμογή να είναι περισσότερο αξιόπιστη και δυνατή απέναντι σε σφάλματα.
|
|
@ -1,4 +1,4 @@
|
|||
%% ΣΕΝΑΡΙΟ ΧΡΗΣΗΣ
|
||||
%% ΣΕΝΑΡΙΑ ΧΡΗΣΗΣ
|
||||
%% Σε αυτό το κεφάλαιο γίνεται περιγραφή ενός σεναρίου χρήσης του συστήματος
|
||||
%% για κάθε έναν από τους ρόλους των χρηστών της εφαρμογής.
|
||||
|
||||
|
@ -6,16 +6,17 @@
|
|||
Το κεφάλαιο αυτό έχει ως στόχο να δώσει μια τυπική περιγραφή της χρήσης της εφαρμογής, για όλους τους διαθέσιμους ρόλους των χρηστών της, έτσι ώστε να γίνει περισσότερο κατανοητός ο τρόπος με τον οποίον θα λειτουργεί το σύστημα κρατήσεων ραντεβού.
|
||||
|
||||
%% ΣΕΝΑΡΙΟ ΧΡΗΣΗΣ ΔΙΑΧΕΙΡΙΣΤΗ
|
||||
\section{Σενάριο Χρήσης Διαχειριστή}
|
||||
\section{Σενάριο χρήσης διαχειριστή}
|
||||
Μετά από αρκετό καιρό χρήσης του Easy!Appointments η εταιρεία προσθέτει μια νέα υπηρεσία στο ενεργητικό της και για τον σκοπό αυτό ανοίγει ένα νέο τμήμα υπαλλήλων. Ο διαχειριστής του συστήματος πρέπει να ενημερώσει την εφαρμογή και να προσθέσει την νέα υπηρεσία, καθώς και τους νέους πάροχους υπηρεσιών, έτσι ώστε να μπορούν οι πελάτες να κλείνουν ραντεβού μαζί τους από εδώ και πέρα. Εφόσον γίνει αυτό, οι πελάτες θα μπορούν να επιλέξουν τις αντίστοιχες εγγραφές από την φόρμα κράτησης ραντεβού.
|
||||
|
||||
%% ΣΕΝΑΡΙΟ ΧΡΗΣΗ ΠΑΡΟΧΟΥ ΥΠΗΡΕΣΙΩΝ
|
||||
\section{Σενάριο Χρήσης Πάροχου Υπηρεσιών}
|
||||
\section{Σενάριο χρήσης πάροχου υπηρεσιών}
|
||||
Ο πάροχος υπηρεσιών της εφαρμογής λαμβάνει μια ειδοποίηση από την εφαρμογή (email) ότι έχει γίνει μια κράτηση για ραντεβού. Βλέποντας τα στοιχεία της κράτησης και την ημερομηνία αποφασίζει ότι δεν θα μπορέσει να είναι εκείνη την στιγμή διαθέσιμος, οπότε συνδέεται στην εφαρμογή και αλλάζει την ημερομηνία του ραντεβού. Αμέσως μετά πηγαίνει στο πρόγραμμά του και ενημερώνει την χρονική στιγμή στην οποία δεν θα είναι διαθέσιμος, έτσι ώστε να μην μπορούν πλέον οι πελάτες να κάνουν κρατήσεις σε εκείνη την χρονική περίοδο. Στην συνέχεια αποστέλλεται ειδοποίηση στον πελάτη και αυτός μπορεί να κρίνει αν τον βολεύει η νέα ημερομηνία. Αν όχι θα πρέπει να ακυρώσει το ραντεβού και να το ξανά-προσθέσει σε κάποια άλλη χρονική στιγμή.
|
||||
|
||||
%% ΣΕΝΑΡΙΟ ΧΡΗΣΗΣ ΠΕΛΑΤΗ
|
||||
\section{Σενάριο Χρήσης Πελάτη}
|
||||
\section{Σενάριο χρήσης πελάτη}
|
||||
Ο πελάτης ενδιαφέρεται να κλείσει ραντεβού στην επιχείρηση για μια συγκεκριμένη υπηρεσία. Πηγαίνει στην σελίδα της επιχείρησης και βλέπει το πλάνο, αφού έχει επιλέξει ποια υπηρεσία και ποιόν υπάλληλο προτιμάει. Στην συνέχεια επιλέγει μια χρονική στιγμή που τον βολεύει και την κατοχυρώνει. Η διαδικασία ολοκληρώνεται με την αποστολή ενός email προς τον πελάτη, το οποίο περιέχει όλες τις πληροφορίες του ραντεβού, έτσι ώστε να είναι πάντα προσβάσιμες. Σε αυτό το email περιέχεται και ένας σύνδεσμος ο οποίος επιτρέπει στον πελάτη να πραγματοποιήσει αλλαγές στο ραντεβού. Από την στιγμή αυτήν και μετά το ραντεβού έχει κατοχυρωθεί και ο πελάτης θα ενημερώνεται για οποιαδήποτε αλλαγή μπορεί να γίνει στο ραντεβού του με email.
|
||||
|
||||
\section{Σενάριο Χρήσης Γραμματέας}
|
||||
%% ΣΕΝΑΡΙΟ ΧΡΗΣΗΣ ΓΡΑΜΜΑΤΕΑ
|
||||
\section{Σενάριο χρήσης γραμματέα}
|
||||
Ένας από τους πάροχους υπηρεσίας έχει κλειστεί εντελώς από ραντεβού και δεν μπορεί να δεχτεί άλλα για αυτήν την εβδομάδα. Ένας άλλος πάροχος προσφέρεται να βοηθήσει και έτσι κάποια ραντεβού πρέπει να μεταφερθούν στο ημερολογιακό πλάνο του δεύτερου πάροχου. Την διαδικασία αυτήν θα πρέπει να την αναλάβει η γραμματεία γιατί όλοι οι άλλοι είναι πολύ απασχολημένοι με το να εξυπηρετήσουν τους πελάτες τους.
|
|
@ -6,7 +6,7 @@
|
|||
Σε αυτό το κεφάλαιο θα γίνει η αναλυτική περιγραφή των περιπτώσεων χρήσης του συστήματος που υλοποιήθηκε. Θα περιγραφούν τόσο η βασική ροή όσο και οι εναλλακτικές ροές για όλες τις περιπτώσεις χρήσης. Το κεφάλαιο χωρίζεται σε τμήματα ανάλογα με τον ρόλο (actor) της εφαρμογής στον οποίο ανήκουν.
|
||||
|
||||
\section{Πελάτης}
|
||||
\subsection{Κράτηση Ραντεβού}
|
||||
\subsection{Κράτηση ραντεβού}
|
||||
Η βασικότερη περίπτωση χρήσης της εφαρμογής είναι η διαδικασία της κράτησης ραντεβού του πελάτη με έναν πάροχο υπηρεσίας για την υπηρεσία που τον ενδιαφέρει. Πρόκειται για την κυριότερη περίπτωση χρήσης, μιας και το σύστημα έχει ως στόχο την ευκολότερη διαχείριση των ραντεβού με τους πελάτες.
|
||||
|
||||
\textbf{ΒΑΣΙΚΗ ΡΟΗ}
|
||||
|
@ -20,7 +20,7 @@
|
|||
\item Όταν ο πελάτης συμπληρώσει τα στοιχεία του και αφήσει κενό ένα πεδίο το οποίο είναι υποχρεωτικό για να ολοκληρωθεί η διαδικασία, θα εμφανιστεί μήνυμα το οποίο θα τον προτρέψει να συμπληρώσει όλα τα υποχρεωτικά πεδία.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Επεξεργασία - Ακύρωση Ραντεβού}
|
||||
\subsection{Επεξεργασία - ακύρωση ραντεβού}
|
||||
Εφόσον καταχωρηθεί ένα ραντεβού είναι πολύ σημαντικό να μπορέσει και να τροποποιηθεί με κάποιον τρόπο. Το σύστημα από την στιγμή που καταχωρεί ένα ραντεβού κρατάει και τα στοιχεία του πελάτη σε μια εγγραφή. Παρ' όλα αυτά δεν θα ήταν καλό να αναγκάζει τον πελάτη να δημιουργεί νέο χρήστη (με username και password) έτσι ώστε να μπορέσει να κάνει αλλαγές. Κάτι τέτοιο θα μείωνε την αποδοτικότητα της εφαρμογής μιας και προσθέτει ένα επιπλέον βήμα στην όλη διαδικασία, το οποίο μάλιστα θεωρείται εκνευριστικό αφού ένας μέσος χρήστης του διαδυκτίου θα χρειαστεί να δημιουργήσει δεκάδες λογαριασμούς σε διάφορες ιστοσελίδες. Λαμβάνοντας αυτά υπόψιν για να μπορέσει ο πελάτης να πραγματοποιήσει αλλαγές ή και ακύρωση σε κάποιο ραντεβού του θα ακολουθεί έναν μοναδικό σύνδεσμο ο οποίος θα του έρχεται με email.
|
||||
|
||||
\textbf{ΒΑΣΙΚΗ ΡΟΗ}
|
||||
|
@ -35,7 +35,7 @@
|
|||
\end{itemize}
|
||||
|
||||
\section {Πάροχος Υπηρεσιών}
|
||||
\subsection {Συγχρονισμός Πλάνου με το Google Calendar}
|
||||
\subsection {Συγχρονισμός πλάνου με το Google Calendar}
|
||||
Βασικό στοιχείο για την χρησιμότητα και την απόδοση του συστήματος είναι η διαχείριση των δεδομένων να γίνεται από πολλά συστήματα. Κάτι τέτοιο μπορεί να επιτεφθχεί με τον συγρονισμό των ραντεβού με το Google Calendar API. Σε αυτό ο χρήστης θα μπορεί να πραγματοποιεί αλλαγές στο πλάνο του μέσω του Google Calendar και αυτές να εφαρμόζονται και στο σύστημα κρατήσεων ραντεβού, κάνοντας έτσι την εργασία του πολύ εύκολη.
|
||||
|
||||
\textbf{ΒΑΣΙΚΗ ΡΟΗ}
|
||||
|
@ -49,7 +49,7 @@
|
|||
\item Πιθανό είναι επίσης να γίνει μια αλλαγή σε ένα συγχρονισμένο συμβάν στο Google Calendar το οποίο όμως να έχει αλλαχθεί και στο Easy!Appointments. Σε αυτήν την περίπτωση θεωρείται ότι υπερισχύει η αλλαγή που έχει γίνει στο Easy!Appointmets διότι δεν υπάρχει η δυνατότητα να ελεγχθεί και στα δύο συστήματα το πότε (χρονική στιγμή) έχει γίνει η τροποποίηση.
|
||||
\end{itemize}
|
||||
|
||||
\subsection {Διαχείριση Ραντεβού}
|
||||
\subsection {Διαχείριση ραντεβού}
|
||||
Όπως και ο πελάτης, έτσι και ο πάροχος υπηρεσιών θα πρέπει να έχει την δυνατότητα να διαχειρίζεται τα ραντεβού του (εφόσον του έχει δοθεί το δικαίωμα από τον διαχειριστή). Με αυτόν τον τρόπο θα έχει την δυνατότητα να πραγματοποιεί αλλαγές στο ημερολόγιο του, να αλλάζει την ημερομηνία των ραντεβού του και να καθορίζει το πλάνο του καταπώς τον βολεύει. Το Easy!Appointments εμφανίζει όλα τα ραντεβού σε ημερολόγιο, στο οποίο ο χρήστης μπορεί να περιηγηθεί χρονικά.
|
||||
|
||||
\textbf{ΒΑΣΙΚΗ ΡΟΗ}
|
||||
|
@ -63,7 +63,7 @@
|
|||
\item Σε αντίθεση με τον πελάτη, ένας πάροχος υπηρεσιών μπορεί να αλλάξει την διάρκεια ενός ραντεβού, ανεξάρτητα από το πόση ώρα διαρκεί το ραντεβού του. Οπότε στην φόρμα επεξεργασίας ενός ραντεβού υπάρχει η δυνατότητα επιλογής ημερομηνίας και ώρας έναρξης και τερματισμού του ραντεβού.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Λήψη ειδοποιήσεων από το Σύστημα}
|
||||
\subsection{Λήψη ειδοποιήσεων από το σύστημα}
|
||||
Κάθε φορά που πραγματοποιείται μια ενέργεια που αφορά κάποιο ραντεβού στο σύστημα ο πάροχος υπηρεσίας θα ενημερώνεται με email (εκτός και αν απενεργοποιήσει αυτήν την ρύθμιση). Έτσι θα είναι πάντα ενήμερος σχετικά με την κατάσταση των ραντεβού του. Σε αυτά τα μηνύματα θα περιέχεται και ένα μοναδικό link το οποίο θα δίνει την δυνατότητα στον πάροχο να πραγματοποίηση αλλαγές γρήγορα στο ραντεβού που τον ενδιαφέρει.
|
||||
|
||||
\textbf{ΒΑΣΙΚΗ ΡΟΗ}
|
||||
|
@ -82,14 +82,14 @@
|
|||
Ο πάροχος μπορεί να αλλάξει τα στοιχεία ενός πελάτη χωρίς να πραγματοποιήσει αλλαγές στις πληροφορίες του ραντεβού του ίδιου.
|
||||
|
||||
\section{Γραμματέας}
|
||||
\subsection{Διαχείριση Ραντεβού}
|
||||
\subsection{Διαχείριση ραντεβού}
|
||||
Ο χρήστης γραμματέας μπορεί να πραγματοποιήσει αλλαγές στα ραντεβού ενός ή περισσοτέρων πάροχων υπηρεσίας. Με αυτόν τον τρόπο μια εταιρεία μπορεί να αναθέσει όλη την διαχείριση των ραντεβού σε ένα άτομο και οι πάροχοι απλώς να βλέπουν τα ραντεβού τους στο πλάνο.
|
||||
|
||||
\textbf{ΒΑΣΙΚΗ ΡΟΗ}
|
||||
|
||||
Ο χρήστης γραμματέας δέχεται τηλεφώνημα από κάποιον πελάτη ο οποίος επιθυμεί να αλλάξει την ώρα του ραντεβού του αλλά δεν έχει σύνδεση με το διαδίκτυο στο σημείο που βρίσκεται. Έτσι ο γραμματέας πραγματοποιεί την αλλαγή του ραντεβού καταπώς μπορεί να βολεύει τόσο τον πάροχο υπηρεσίας όσο και τον πελάτη. Όταν τελειώσει μπορεί να αποθηκεύσει τις αλλαγές στο σύστημα.
|
||||
|
||||
\subsection{Διαχείριση Πελατών}
|
||||
\subsection{Διαχείριση πελατών}
|
||||
Εκτός των ραντεβού, ο χρήστης γραμματέας είναι σε θέση να πραγματοποιήσει αλλαγές και στα στοιχεία των πελατών, οργανώνοντας και κρατώντας πλήρη πελατολόγιο για την επιχείριση. Μελλοντικά θα είναι σε θέση να βρίσκει πολύ εύκολα οποιονδήποτε πελάτη της επιχείρισης και να βλέπει τα στοιχεία του.
|
||||
|
||||
\textbf{ΒΑΣΙΚΗ ΡΟΗ}
|
||||
|
@ -117,19 +117,19 @@
|
|||
|
||||
Ο διαχειριστής εισέρχεται στο backend μέρος της εφαρμογής και επιλέγει την σελίδα των ρυθμίσεων. Εκεί έχει την δυνατότητα να θέσει τις τιμές σε διάφορες παραμέτρους, οι οποίες καθορίζουν τον τρόπο με τον οποίο λειτουργεί το σύστημα. Στόχος είναι αυτός να συμβαδίζει με τον τρόπο λειτουργίας της επιχείρισης έτσι ώστε να μπορεί η εταιρεία να επωφεληθεί από το Easy!Appointments.
|
||||
|
||||
\subsection{Διαχείριση των ραντεβού}
|
||||
\subsection{Διαχείριση ραντεβού}
|
||||
Ο διαχειριστής ως χρήστης έχει πρόσβαση σε όλες τις πληροφορίες του συστήματος. Έτσι μπορεί να μεταβάλει και να προσθέσει ραντεβού στο σύστημα σαν να ήταν ένας πάροχος υπηρεσιών ή ένας χρήστης γραμματέας.
|
||||
|
||||
\textbf {ΒΑΣΙΚΗ ΡΟΗ}
|
||||
|
||||
Ο διαχειριστής συνδέεται στο backend μέρος της εφαρμογής και πηγαίνει στην σελίδα του ημερολογίου. Εκεί μπορεί να δει τα ραντεβού όλων των πάροχων υπηρεσιών και να πραγματοποιήσει αλλαγές σε αυτά. Με το που αποθηκευτούν οι αλλαγές σε ένα ραντεβού ο πελάτης και ο πάροχος θα ενημερωθούν με email, όπως θα γινόταν δηλαδή αν την επεξεργασία την έκανε ένας πάροχος.
|
||||
|
||||
\subsection {Διαχείριση των χρηστών}
|
||||
\subsection {Διαχείριση χρηστών}
|
||||
Τις υπηρεσίες που προσφέρει η εταιρεία τις αναλαμβάνουν κάποιοι υπάλληλοι (ή ομάδες υπαλλήλων), οι οποίοι αναφέρονται στο σύστημα ως πάροχοι υπηρεσιών. Τα στοιχεία τους, τις αρμοδιότητές τους και τα δικαιώματα μέσα στο σύστημα τα ορίζει μόνο ο διαχειριστής του συστήματος, από το backend μέρος της εφαρμογής. Επίσης είναι δυνατή η διαχείριση των διαχειριστών, γραμματειών και πελατών του συστήματος.
|
||||
|
||||
\textbf{ΒΑΣΙΚΗ ΡΟΗ}
|
||||
|
||||
Ο διαχειριστής της εφαρμογής συνδέεται στο backend μέρος του συστήματος και πηγαίνει στην σελίδα των πάροχων υπηρεσίας. Εκεί βλέπει μια λίστα με τους ήδη καταχωρημένους πάροχους υπηρεσιών. Αν θέλει μπορεί να προσθέσει έναν καινούργιο πάροχο, ή να επεξεργαστεί και να διαγράψει κάποιον πάροχο που υπάρχει ήδη στην βάση δεδομένων.
|
||||
|
||||
\subsection {Διαχείριση Υπηρεσιών}
|
||||
\subsection {Διαχείριση υπηρεσιών}
|
||||
Οι πελάτες που θα επισκέπτονται τον ιστότοπο του Easy!Appointments της επιχείρησης θα κλείνουν ραντεβού για συγκεκριμένες υπηρεσίες. Το ποιες υπηρεσίες θα είναι διαθέσιμες και ποιοι πάροχοι υπηρεσιών μπορούν να εξυπηρετήσουν τι, το διαχειρίζεται ο διαχειριστής του συστήματος. Αποτελεί υποπερίπτωση χρήσης της παραμετροποίησης της εφαρμογής.
|
15
doc/thesis/snippets/unit_test_automation.php
Normal file
15
doc/thesis/snippets/unit_test_automation.php
Normal file
|
@ -0,0 +1,15 @@
|
|||
<?php
|
||||
/**
|
||||
* Run all the available tests
|
||||
*/
|
||||
public function run_all() {
|
||||
// All the methods whose names start with "test" are going to be
|
||||
// executed. If you want a method to not be executed remove the
|
||||
// "test" keyword from the beginning.
|
||||
$class_methods = get_class_methods('Unit_tests_admins_model');
|
||||
foreach ($class_methods as $method_name) {
|
||||
if (substr($method_name, 0, 5) === 'test_') {
|
||||
call_user_func(array($this, $method_name));
|
||||
}
|
||||
}
|
||||
}
|
22
doc/thesis/snippets/unit_test_get_value_example.php
Normal file
22
doc/thesis/snippets/unit_test_get_value_example.php
Normal file
|
@ -0,0 +1,22 @@
|
|||
<?php
|
||||
/**
|
||||
* Test the get field value method with a record id that
|
||||
* doesn't exist in the db.
|
||||
*
|
||||
* A database exception is expected.
|
||||
*/
|
||||
private function test_get_value_record_does_not_exist() {
|
||||
$random_record_id = 843521368768;
|
||||
|
||||
$has_thrown_exception = FALSE;
|
||||
|
||||
try {
|
||||
$this->CI->Appointments_Model
|
||||
->get_value('start_datetime', $random_record_id);
|
||||
} catch (InvalidArgumentException $db_exc) {
|
||||
$has_thrown_exception = TRUE;
|
||||
}
|
||||
|
||||
$this->CI->unit->run($has_thrown_exception, TRUE,
|
||||
'Test get_value() with record id that does not exist.');
|
||||
}
|
31
doc/thesis/snippets/unit_test_insert_example.php
Normal file
31
doc/thesis/snippets/unit_test_insert_example.php
Normal file
|
@ -0,0 +1,31 @@
|
|||
<?php
|
||||
/**
|
||||
* Test the appointment add method - insert new record.
|
||||
*/
|
||||
private function test_add_appointment_insert() {
|
||||
// Add - insert new appointment record to the database.
|
||||
$appointment_data = array(
|
||||
'start_datetime' => '2013-05-01 12:30:00',
|
||||
'end_datetime' => '2013-05-01 13:00:00',
|
||||
'notes' => 'Some notes right here...',
|
||||
'id_users_provider' => $this->provider_id,
|
||||
'id_users_customer' => $this->customer_id,
|
||||
'id_services' => $this->service_id
|
||||
);
|
||||
$appointment_data['id'] = $this->CI->Appointments_Model
|
||||
->add($appointment_data);
|
||||
$this->CI->unit->run($appointment_data['id'], 'is_int',
|
||||
'Test if add() appointment (insert operation) '
|
||||
. 'returned the db row id.');
|
||||
|
||||
// Check if the record is the one that was inserted.
|
||||
$db_data = $this->CI->db->get_where('ea_appointments',
|
||||
array('id' => $appointment_data['id']))->row_array();
|
||||
$this->CI->unit->run($appointment_data, $db_data, 'Test if add() '
|
||||
. 'appointment (insert operation) has successfully '
|
||||
. 'inserted a record.');
|
||||
|
||||
// Delete inserted record.
|
||||
$this->CI->db->delete('ea_appointments',
|
||||
array('id' => $appointment_data['id']));
|
||||
}
|
Binary file not shown.
Loading…
Reference in a new issue