* Added new thesis chapter implementation.tex
* Changed the conclusions.tex
This commit is contained in:
parent
60fcb4f154
commit
2ca1d49b46
10 changed files with 125 additions and 1 deletions
Binary file not shown.
Before Width: | Height: | Size: 29 KiB |
BIN
doc/thesis/images/domain-model.png
Normal file
BIN
doc/thesis/images/domain-model.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 36 KiB |
BIN
doc/thesis/images/er.png
Normal file
BIN
doc/thesis/images/er.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 64 KiB |
BIN
doc/thesis/images/sd-save-appointment.png
Normal file
BIN
doc/thesis/images/sd-save-appointment.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 24 KiB |
BIN
doc/thesis/images/sd-sync-appointment.png
Normal file
BIN
doc/thesis/images/sd-sync-appointment.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 15 KiB |
BIN
doc/thesis/images/system-architecture.png
Normal file
BIN
doc/thesis/images/system-architecture.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 17 KiB |
|
@ -2,11 +2,32 @@
|
|||
Το αποτέλεσμα της εκπόνησης της εργασίας αυτής είναι ένα πλήρης σύστημα διαχείρισης ραντεβού, το οποίο μπορεί να παραμετροποιηθεί επαρκώς έτσι ώστε να καλύψει τις ανάγκες οποιασδήποτε επιχείρισης ανεξαρτήτου ειδικότητας και μεγέθους. Ο αρχικός σχεδιασμός αποδείχθηκε σωστός και έτσι το τελικό προϊόν πληροί τις απαιτήσεις για τις οποίες αναπτύχθηκε.
|
||||
|
||||
\section{Προβλήματα}
|
||||
\subsection{Διαχείριση Χρόνου}
|
||||
Σημαντικότερο πρόβλημα σχετικά με την υλοποίηση της εφαρμογής ήταν η χρονική καθυστέρηση μιας και ανάμεσα στην ανάληψη της εργασίας και την περαίωση της, πραγματοποιήθηκε η πρακτική άσκηση σε εταιρεία πληροφορικής, καθώς και εργασία εκτός σχολής με άλλες εταιρείες πληροφορικής. Οι εξωτερικές υποχρεώσεις αυτές αποσπούσαν την συνεχή και ομαλή ανάπτυξη, κάτι που συνεχώς διασπούσε τον ειρμό και τον δημιουργικό οίστρο. Συμπέρασμα αυτού του σημαντικού προβλήματος είναι ότι θα πρέπει να γίνεται σαφής και ορθός προγραμματισμός του χρόνου υλοποίησης ενός έργου γιατί διαφορετικά οι πιθανότητες για χαμηλότερη ποιότητα υπηρεσίας ή ακόμα και αποτυχίας του έργου αυξάνονται εκθετικά.
|
||||
|
||||
\subsection{Συγχρονισμός Δεδομένων Με Το Google Calendar}
|
||||
Όσον αφορά την συνεργασία του συστήματος με την υπηρεσία Google Calendar, αλλά και γενικότερα με άλλες πιθανές υπηρεσίες το ζήτημα παραμένει στο πως θα παραμείνουν τα δεδομένα ακέραια και ενημερωμένα και στα δύο συστήματα, όταν δεν υπάρχει ένα κοινό μέσο αποθήκευσης. Το θέμα γιγαντώνεται μάλιστα όταν δεν υπάρχει πρόσβαση στον κώδικα του ενός από τα δύο συστήματα έτσι ώστε να δημιουργηθεί μια "γέφυρα δεδομένων". Για την επίλυση αυτού του θέματος ήταν αναγκαίο να δημιουργηθεί ένας αλγόριθμος συγχρονισμού ο οποίος θα ενεργοποιούνταν από την πλευρά του Easy!Appointments και θα αναλάμβανε την ενημέρωση και τον δύο συστημάτων με τα τελευταία δεδομένα. Για αυτόν τον σκοπό θα έπρεπε να καταγραφούν και να υλοποιηθούν κάποιοι κανόνες συγχρονισμού οι οποίοι θα μετέφεραν επιτυχώς τα ραντεβού αμφίδρομα και στα δύο συστήματα. Στις περιπτώσεις όπου η μεταφορά αυτή θα ήταν αδύνατη (σύγκρουση δεδομένων) ο χρήστης θα έπρεπε να αποφασίσει ποια εκδοχή των δεδομένων θα υπερισχύσει στο τέλος.
|
||||
|
||||
\subsection{Διαχωρισμός Δικαιωμάτων Χρηστών}
|
||||
Ένα ακόμα πρόβλημα που αντιμετωπίστηκε κατά την διάρκεια την ανάπτυξης του έργου ήταν ο διαχωρισμός των δικαιωμάτων των χρηστών μέσα στο σύστημα. Ο κάθε χρήστης αναλόγως το είδος του (διαχειριστής, πάροχως, γραμματέας) έχει διαφορετικές δυνατότητες και δικαιώματα στα δεδομένα που αποθηκεύονται από το σύστημα. Αυτό συμβαίνει γιατί στις περισσότερες περιπτώσεις θα πρέπει να τηρηθεί η ιεραρχία της επιχείρησης, αλλά και επίσης γιατί θα πρέπει να διασφαλιστεί η ακεραιότητα των δεδομένων από τυχόν εσφαλμένες ενέργειες χρηστών σε βασικές ρυθμίσεις του συστήματος. Για τις κυριότερες ρυθμίσεις απαιτούνται τα δικαιώματα διαχειριστή και έτσι το σύστημα χρειάζεται απαραιτήτως πάντα έναν χρήστη διαχειριστή (ο χρήστης που δημιουργείται κατά την εγκατάσταση είναι ουσιαστικά ο πρώτος διαχειριστής της εφαρμογής). Για να λυθεί αυτό το πρόβλημα η εγγραφή του κάθε χρήστης στην βάση δεδομένων συνδέεται με έναν ρόλο, ο οποίος περιέχει τα δικαιώματα που του αντιστοιχούν. Έτσι για παράδειγμα ένας χρήστης που προορίζεται για πάροχος υπηρεσίας, θα έχει τα δικαιώματα που αντιστοιχούν στον ρόλο "Πάροχος Υπηρεσίας", όπως αυτά είναι αποθηκευμένα στην βάση δεδομένων. Έτσι κάθε φορά που συνδέεται ένας χρήστης στο διαχειριστικό κομμάτι της εφαρμογής τα δεδομένα σχετικά με τα δικαιώματα του και τον ρόλο του διαβάζονται από σελίδα σε σελίδα και η εφαρμογή μπορεί και γνωρίζει με ποιόν τρόπο θα πρέπει να εμφανιστούν τα δεδομένα και ποιες ενέργειες είναι διαθέσιμες στην κάθε περίπτωση.
|
||||
|
||||
\section{Εξέλιξη Της Εφαρμογής}
|
||||
Όπως και σε κάθε έργο λογισμικού υπάρχουν πολλά πράγματα τα οποία μπορούν να εξελιχθούν και να βελτιωθούν, καθώς και δυνατότητες οι οποίες μπορούν να προστεθούν για να κάνουν την εφαρμογή πιο εύχρηστη και εύκολη προς την χρήση.
|
||||
Όπως και σε κάθε έργο λογισμικού, υπάρχουν πολλά πράγματα τα οποία μπορούν να εξελιχθούν και να βελτιωθούν, καθώς και δυνατότητες οι οποίες μπορούν να προστεθούν για να κάνουν την εφαρμογή πιο εύχρηστη και αποδοτικότερη. Οι βελτιώσεις αυτές γίνονται στην φάση της συντήρησης και επέκτασης, σταδιακά, με σκοπό την ύπαρξη ενός ενημερωμένου προϊόντος στην αγορά. Με αυτόν τον τρόπο οι εταιρείες θα μπορούν να εμπιστεύονται την εν λόγω εφαρμογή και να την χρησιμοποιούν ως το δικό τους εργαλείο διαχείρισης των ραντεβού. Παρακάτω περιγράφονται κάποια σημεία στα οποία θα μπορούσε να εξελιχθεί μελλοντικά το σύστημα που παράχθηκε.
|
||||
|
||||
\subsection{Mobile Design}
|
||||
Με την πάροδο του χρόνου όλο και περισσότερες "έξυπνες" συσκευές βρίσκονται στα χέρια των καταναλωτών και έτσι δημιουργείται η ανάγκη για χρήση των διαδικτυακών εφαρμογών από οθόνες που έχουν διαφορετικά μεγέθη οθονών. Εφόσον οι διαστάσεις για τις οθόνες του υπολογιστή έχουν καλυφθεί, το επόμενο βήμα είναι να σχεδιαστεί όλο το σύστημα για κινητές συσκευές και tablet. Με αυτόν τον τρόπο θα μπορούν οι χρήστες του Easy!Appointments να χρησιμοποιούν το σύστημα από το κινητό του πολύ πιο άνετα και έτσι να είναι πάντα ενημερωμένοι σχετικά με τα ραντεβού τους όπου και αν βρίσκονται. Προϋπόθεση για αυτό πάντα είναι μια ενεργή σύνδεση με το διαδίκτυο. Για να υλοποιηθεί αυτή η δυνατότητα θα χρειαστεί να γραφεί CSS κώδικας ο οποίος να εμφανίζει την εφαρμογή διαφορετικά σε κινητές συσκευές.
|
||||
|
||||
\subsection{Μετάφραση Της Διεπαφής Χρήστη}
|
||||
Η πρώτη υλοποίηση του συστήματος έχει γίνει εξολοκλήρου στην αγγλική γλώσσα, όπως και με τα περισσότερα συστήματα που απευθύνονται σε ένα ευρύ καταναλωτικό κοινό. Το Easy!Appointments δέχεται κείμενο και σε άλλες γλώσσες (χρησιμοποιείται το encoding UTF-8) αλλά η διεπαφή, τα μηνύματα και τα αντικείμενα ελέγχου είναι όλα στα Αγγλικά. Για να γίνει πιο εύκολη η χρήση της εφαρμογής και από ανθρώπους οι οποίοι δεν είναι τόσο εξοικειωμένοι με αυτήν την γλώσσα θα πρέπει να μεταφραστεί όλο το σύστημα και σε άλλες κοινές γλώσσες. Για να επιτευχθεί αυτό στην συγκεκριμένη περίπτωση θα πρέπει να χρησιμοποιηθεί η ενσωματωμένη τεχνική του CodeIgniter.
|
||||
|
||||
\subsection{Αναφορές Δεδομένων}
|
||||
Το σύστημα μέσω της λειτουργίας του κρατάει διάφορα δεδομένα (ραντεβού, πελάτες, πάροχοι κτλ). Καλό θα ήταν αυτά τα δεδομένα να μπορούν να εξαχθούν με κάποιον τρόπο έτσι ώστε να μπορέσουν να χρησιμοποιηθούν και με άλλους τρόπους. Μια περίπτωση χρήσης θα ήταν η εξαγωγή των σημερινών ραντεβού ενός πάροχου σε μια εκτυπώσιμη αναφορά, έτσι ώστε να μπορεί ο χρήστης να την τυπώσει και να την έχει ως λίστα στο γραφείο. Μια άλλη περίπτωση χρήσης θα ήταν να εκτυπωθούν τα στοιχεία ενός πελάτη, καθώς και το ιστορικό των ραντεβού του. Οι αναφορές αυτές είναι πολύ χρήσιμες γιατί μπορούν να αναδείξουν γρήγορα δεδομένα και μάλιστα σε εκτυπώσιμη μορφή, κάτι που ακόμα χρειάζονται πολλές εταιρείες.
|
||||
|
||||
\subsection{Στατιστικές Πληροφορίες}
|
||||
Μια χρήσιμη μελλοντική δυνατότητα θα ήταν η συλλογή στατιστικών πληροφοριών σχετικά με τα ραντεβού που κλίνονται στο σύστημα. Από αυτήν την διαδικασία θα μπορούσαν να βγουν σημαντικές πληροφορίες όπως το ποια υπηρεσία ή πάροχος προτιμάται πιο συχνά, ποιες μέρες έχουν τα περισσότερα ραντεβού, πόσο συχνά ακυρώνονται τα ραντεβού και σε πόσο χρονικό διάστημα πριν. Αυτές οι πληροφορίες είναι πολύ σημαντικές για μια εταιρεία η οποία λειτουργεί με κρατήσεις ραντεβού γιατί έτσι μπορεί να γνωρίζει με ποιόν τρόπο λειτουργεί το πελατειακό κοινό της και έτσι να λειτουργεί αναλόγως για να παρέχει καλύτερη εξυπηρέτηση. Ένα παράδειγμα θα ήταν η περίπτωση ενός μεγάλου κομμωτηρίου στην οποία οι πελάτες θα κρατούσαν πάρα πολλά ραντεβού το Σάββατο κάθε εβδομάδας, γιατί πιθανόν έχουν περισσότερο χρόνο. Τα στατιστικά (εκτός της πείρας) θα έδειχναν την αυξημένη κίνηση του Σαββάτου και έτσι ο διαχειριστής θα είχε διαθέσιμους όλους του πάροχους προς ραντεβού, για να μπορέσει να καλυφθεί το κοινό όσο καλύτερα γίνεται.
|
||||
|
||||
\subsection{Δημιουργία RESTful Υπηρεσίας}
|
||||
Κάθε μεγάλο διαδικτυακό σύστημα παρέχει και μια RESTful υπηρεσία η οποία μπορεί να απαντάει με δεδομένα σε διάφορες κλήσεις που της γίνονται, εφόσον βέβαια έχει πιστοποιηθεί ο client που επικοινωνεί μαζί τους. Με αυτόν τον τρόπο θα μπορούν άλλοι προγραμματιστές να φτιάχνουν εφαρμογές οι οποίες θα επικοινωνούν με το Easy!Appointments και θα διαχειρίζονται τα δεδομένα του συστήματος. Η υλοποίηση αυτής της δυνατότητας θα βοηθούσε πολύ την εξέλιξη και την χρήση του Easy!Appoinmtments γιατί από εδώ και πέρα διάφορες εφαρμογές θα υλοποιούνταν κάνοντας δυνατή την χρήση των δεδομένων σε πολλές διαφορετικές περιστάσεις. Κάτι που είναι πάρα πολύ χρήσιμο για κάθε επαγγελματία (παραδείγματος χάρη η χρήση πελατών από CRM εφαρμογή).
|
||||
|
||||
\subsection{Βελτίωση Κώδικα}
|
||||
Τελευταίο αλλά και όχι λιγότερο σημαντικό είναι η συνεχής βελτίωση και ενημέρωση του κώδικα έτσι ώστε να είναι πάντα στην καλύτερη δυνατή κατάσταση. Καθώς εξελίσσεται ένα σύστημα λογισμικού είναι απαραίτητο να βελτιώνεται ο κώδικας και η δομή του. Επίσης είναι απαραίτητο να ενημερώνονται και τα εξωτερικά εργαλεία τα οποία χρησιμοποιούνται έτσι ώστε να διασφαλίζεται η ασφάλεια και η ποιότητα του συστήματος. Κατά καιρούς εμφανίζονται διάφορες ενημερώσεις ασφαλείας αλλά και διορθώσεων σφαλμάτων σε αυτά τα framework (CodeIgniter, jQuery κτλ) τα οποία θα χρειαστεί να συμπεριληφθούν και στο Easy!Appointments. Κάθε φορά που ο χρήστης λαμβάνει μια νέα έκδοση της εφαρμογής θα πρέπει ο κώδικας που την απαρτίζει να βρίσκεται σε πολύ καλή κατάσταση, να έχει ελεγχθεί και να λειτουργεί σωστά έτσι ώστε να εμπνέει εμπιστοσύνη προς τους χρήστες.
|
101
doc/thesis/includes/implementation.tex
Normal file
101
doc/thesis/includes/implementation.tex
Normal file
|
@ -0,0 +1,101 @@
|
|||
\chapter{Σχεδίαση \& Υλοποίηση}
|
||||
Σε αυτό το κεφάλαιο γίνεται ανάλυση του συστήματος στα επιμέρους μέρη και περιγράφεται η διαδικασία της υλοποίησης τους. Επεξηγούνται επίσης τα σημαντικότερα σημεία στον κώδικα και οι αλγόριθμοι που χρησιμοποιούνται για την επίλυση των κυριότερων λειτουργιών. Έχουν συμπεριληφθεί τμήματα κώδικα αλλά και διαγράμματα τα οποία βοηθούν στην κατανόηση των λύσεων που έχουν χρησιμοποιηθεί.
|
||||
|
||||
\subsection{Δεδομένα Συστήματος}
|
||||
Το κυριότερο πρόβλημα που προσπαθεί να λύσει το σύστημα είναι η κράτηση και η διαχείριση ραντεβού από μια επιχείριση. Σε αυτήν την περίπτωση χρήσης έχει επικεντρωθεί η σχεδίαση και η υλοποίηση του συστήματος το οποίο περιέχει και άλλες δυνατότητες οι οποίες μπορούν όμως να θεωρηθούν λιγότερο σημαντικές. Έχοντας υπόψιν την έννοια "ραντεβού" ως την κύρια οντότητα της εφαρμογής, σχεδιάστηκε το παρακάτω μοντέλο το οποίο διευκρινίζει τις σχέσεις των υπόλοιπων οντοτήτων σε σχέση με το ραντεβού αλλά και μεταξύ τους.
|
||||
|
||||
\begin{figure}[ht!]
|
||||
\centering
|
||||
\includegraphics[width=160mm]{images/domain-model.png}
|
||||
\caption{Domain model του συστήματος}
|
||||
\label{domain-model}
|
||||
\end{figure}
|
||||
|
||||
Με βάση αυτό το σχεδιάγραμμα μπορεί πολύ εύκολα να προκύψει και το σχεδιακό μοντέλο της βάσης δεδομένων, δεδομένου ότι έχουμε και τις οντότητες, αλλά και τις σχέσεις μεταξύ τους. Όλοι οι χρήστες της εφαρμογής κληρονομούν την συμπεριφορά τους από μια οντότητα (User) και στην συνέχεια προσθέτουν τις πρόσθετες ιδιαιτερότητες που τους χαρακτηρίζουν. Για παράδειγμα ο χρήστης γραμματέας (Secretary) περιέχει έναν πίνακα από πάροχους (Providers) τους οποίους μπορεί να διαχειριστεί, ή ένα ραντεβού είναι ξεκάθαρο ότι περιέχει στην πληροφορία του έναν πελάτη, έναν πάροχο και μια υπηρεσία.
|
||||
|
||||
\begin{figure}[ht!]
|
||||
\centering
|
||||
\includegraphics[width=160mm]{images/er.png}
|
||||
\caption{Σχεσιακό μοντέλο της βάσης δεδομένων (ER).}
|
||||
\label{er}
|
||||
\end{figure}
|
||||
|
||||
Για την διαχείριση των δεδομένων της βάσης δημιουργήθηκαν ειδικές κλάσεις (models) οι οποίες περιέχουν μεθόδους που χρησιμοποιούνται από τους controllers του συστήματος. Το CodeIgniter δίνει στον προγραμματιστή ένα δικό του μέσο επικοινωνίας με την βάση δεδομένων, το οποίο είναι ένα πολύ ισχυρό και ευέλικτο εργαλείο. Η επονομαζόμενη Database Class του CodeIgniter επιτρέπει στον προγραμματιστεί να εκτελεί ερωτήματα προς την βάση, να παράγει αποτελέσματα και να τα αναλύει σε ξεχωριστές εγγραφές, να κρατάει στην μνήμη ερωτήματα για γρηγορότερη ανταπόκριση (query caching) και κυριότερο την κλάση Active Record. Η κλάση αυτή έχει έναν δικό της τρόπο για την εκτέλεση των ερωτημάτων προς την βάση. Όλα τα τμήματα ενός τυπικού ερωτήματος είναι μέθοδοι σε αυτήν την κλάση και έτσι ο προγραμματιστείς χρησιμοποιεί τις μεθόδους αυτές για να επικοινωνήσει με την βάση δεδομένων. Το θετικό είναι ότι ανεξαρτήτως τον τύπο της βάσης η κλάση αυτή λειτουργεί με τον ίδιο τρόπο (MySQL, PostGre, MSSQL κτλ). Η τεχνική αυτή λέγεται Active Record Database Pattern και έχει αν κάνει με την αλλαγή adapter στην κλάση ανάλογα με τον τύπο της βάσης. Σε κάθε περίπτωση όμως ο τρόπος λειτουργίας της είναι ο ίδιος. Στο παρακάτω τμήμα κώδικα αναφέρεται ένα παράδειγμα για το πως μπορεί να βρεθεί το αναγνωριστικό μιας εγγραφής χρησιμοποιώντας ως κλειδί την διεύθυνση email.
|
||||
|
||||
\begin{verbatim}
|
||||
public function find_record_id($admin) {
|
||||
if (!isset($admin['email'])) {
|
||||
throw new Exception('Admin email was not provided: '
|
||||
. print_r($admin, TRUE));
|
||||
}
|
||||
|
||||
$result = $this->db
|
||||
->select('ea_users.id')
|
||||
->from('ea_users')
|
||||
->join('ea_roles', 'ea_roles.id = ea_users.id_roles', 'inner')
|
||||
->where('ea_users.email', $admin['email'])
|
||||
->where('ea_roles.slug', DB_SLUG_ADMIN)
|
||||
->get();
|
||||
|
||||
if ($result->num_rows() == 0) {
|
||||
throw new Exception('Could not find admin record id.');
|
||||
}
|
||||
|
||||
return intval($result->row()->id);
|
||||
}
|
||||
\end{verbatim}
|
||||
|
||||
\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.
|
||||
|
||||
Πολύ μεγάλο μέρος της εφαρμογής έχει γραφτεί σε JavaScript για να μπορέσει το περιβάλλον εργασίας του χρήστη να γίνει αρκετά φιλικό και οικείο. Το κομμάτι JavaScript κώδικα χωρίζεται σε διάφορες κλάσεις και namespace τα οποία χρησιμοποιούνται από μια ή και παραπάνω σελίδες και στόχο έχουν να "ζωντανέψουν" το περιεχόμενο προσθέτοντας διαδραστικότητα. Πολλές φορές είναι απαραίτητο να εκτελεστούν κλήσεις AJAX προς τον server για την λήψη πρόσθετων πληροφοριών, είτε για να αποσταλούν δεδομένα τα οποία σηματοδοτούν για παράδειγμα κάποια επεξεργασία ή και διαγραφή εγγραφής από την βάση δεδομένων. Το framework jQuery αποτελεί σημαντικό εργαλείο για την διεκπεραίωση αυτής της λειτουργίας διότι δίνει την δυνατότητα στον προγραμματιστή να γράψει κώδικα όμορφα δομημένο και πολύ αποδοτικό, από ότι θα ήταν χωρίς την χρήση του. Αυτή η ιδιότητα της βιβλιοθήκης συντελεί και στην δημοτικότητά της και την χρήση της από κολοσσούς ανάπτυξης λογισμικού.
|
||||
|
||||
Για την μορφοποίηση των σελίδων της εφαρμογής χρησιμοποιήθηκε το πιο διαδεδομένο CSS framework αυτήν την περίοδο, το Bootstap. Χρησιμοποιώντας αυτό το framework γράφτηκε νέο CSS το οποίο μορφοποιεί τις σελίδες έτσι ώστε να ανταποκρίνονται όπως πρέπει σε διάφορα μεγέθη οθονών.
|
||||
|
||||
Στο παρακάτω σχεδιάγραμμα γίνεται σαφής ο διαχωρισμός του κώδικα του συστήματος στα διάφορα τμήματα που το απαρτίζουν και η χρήση των εξωτερικών εργαλείων που συντέλεσαν στην ορθή ανάπτυξη της εφαρμογής.
|
||||
|
||||
\begin{figure}[ht!]
|
||||
\centering
|
||||
\includegraphics[width=100mm]{images/system-architecture.png}
|
||||
\caption{Τα τμήματα που απαρτίζουν το Easy!Appointments.}
|
||||
\label{system-architecture}
|
||||
\end{figure}
|
||||
|
||||
\section{Υλοποίηση Του Συστήματος}
|
||||
Εφόσον ο αρχικός σχεδιασμός είχε ολοκληρωθεί ξεκίνησε η υλοποίηση της εφαρμογής με πρώτη εργασία τον σχεδιασμό της βάσης δεδομένων. Έχοντας ήδη σχεδιασμένο το domain model η δημιουργία του σχήματος της βάσης έγινε γρήγορα και διατηρήθηκε ως την ολοκλήρωση του έργου με μικρές προσθήκες όπου ήταν απαραίτητο.
|
||||
|
||||
Στην συνέχεια, πριν γραφεί κώδικας θα έπρεπε να γίνει η επιλογή και το στήσιμο των εξωτερικών βιβλιοθηκών που θα κρίνονταν απαραίτητα για την λειτουργία του συστήματος. Σε αυτήν την φάση επιλέχθηκαν οι βασικές βιβλιοθήκες (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 Όταν το view ήταν έτοιμο θα έπρεπε να του προστεθεί και κάποια λειτουργικότητα έτσι ώστε να μπορεί να ανταποκριθεί στις ενέργειες του χρήστη. Για κάθε σελίδα χρησιμοποιούνται μια πληθώρα από βιβλιοθήκες, namespaces, κλάσεις και πρόσθετα JavaScript. Στα αντίστοιχα αρχεία τοποθετήθηκε ο κώδικας που θα ρύθμιζε την λειτουργία της σελίδας και τις ασύγχρονες κλήσεις προς τον server (AJAX).
|
||||
\item Τέλος εφόσον όλα ήταν έτοιμα και η περίπτωση χρήσης είχε υλοποιηθεί χωρίς προβλήματα, όλος ο κώδικας που είχε γραφεί έπρεπε να εξεταστεί (review) για τυχόν προβλήματα λογικής και για την βελτίωση της απόδοσης του κώδικα, μικραίνοντας όσο είναι δυνατόν την σύζευξη και αυξάνοντας την συνοχή.
|
||||
\end{enumerate}
|
||||
|
||||
Εδώ θα χρειαστεί να αναφερθεί ότι όλες οι κλήσεις AJAX έχουν μεταφερθεί σε μια κλάση controller, ξεχωριστά από τον κύριο controller του backend για να είναι καλύτερα οργανωμένες. Αν μελλοντικά ο αριθμός τους και η πολυπλοκότητα τους αυξηθεί τότε θα χρειαστεί να διαιρεθούν ξανά για να μπορέσουν να συντηρούνται πιο εύκολα.
|
||||
|
||||
\section{Διαγράμματα Κώδικα}
|
||||
Σε αυτήν την ενότητα θα παρατεθούν κάποια διαγράμματα κώδικα τα οποία θα βοηθήσουν τον αναγνώστη στην κατανόηση της λειτουργίας του συστήματος και στον τρόπο με τον οποίο διεκπεραιώνονται οι εργασίες που απαιτούνται στην εκάστοτε περίπτωση χρήσης.
|
||||
|
||||
\subsection{Διαγράμματα Ροής}
|
||||
Τα διαγράμματα ροής δείχνουν τον τρόπο με τον οποίο λειτουργούν οι διαδικασίες μεταξύ τους. Σε αυτά είναι εύκολο να διακριθούν με ποιον τρόπο επικοινωνούν τα διάφορα συστήματα μεταξύ τους και την πορεία των δεδομένων μέχρι αυτά να φτάσουν τον τελικό προορισμό τους.
|
||||
|
||||
\begin{figure}[!htb]
|
||||
\centering
|
||||
\includegraphics[width=150mm]{images/sd-save-appointment.png}
|
||||
\caption{Στο διάγραμμα ροής εμφανίζεται η διαδικασία που εκτελείται για την αποθήκευση ενός ραντεβού μετά την επιτυχή καταχώρηση του από τον πελάτη.}
|
||||
\label{sd-save-appointment}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[!htb]
|
||||
\centering
|
||||
\includegraphics[width=150mm]{images/sd-sync-appointment.png}
|
||||
\caption{Στο διάγραμμα ροής εμφανίζεται η διαδικασία με την οποία πραγματοποιείται η προσθήκη ενός ραντεβού στο Google Calendar.}
|
||||
\label{sd-save-appointment}
|
||||
\end{figure}
|
Binary file not shown.
|
@ -17,5 +17,7 @@
|
|||
\input{includes/external-tools.tex}
|
||||
\input{includes/usage-scenarios.tex}
|
||||
\input{includes/use-cases.tex}
|
||||
\input{includes/implementation.tex}
|
||||
\input{includes/unit-testing.tex}
|
||||
\input{includes/conclusions.tex}
|
||||
\end{document}
|
Loading…
Reference in a new issue