Browse Source

Merge branch 'feature/4-application-implementation' into develop

develop
Ezerous 3 years ago
parent
commit
729a55e60a
  1. 28
      chapters/4.application-implementation/4.1.implementation-methodology.tex
  2. 2
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.3.jenkins.tex
  3. 2
      chapters/4.application-implementation/4.3.implementation-architecture.tex
  4. 12
      chapters/4.application-implementation/4.4.problems-faced.tex
  5. 24
      chapters/4.application-implementation/4.5.implemented-parts.tex
  6. 1
      misc/packages.tex
  7. BIN
      thesis.pdf

28
chapters/4.application-implementation/4.1.implementation-methodology.tex

@ -1,8 +1,8 @@
\section{Μεθοδολογία υλοποίησης} \label{subsection:4-1-implementation-methodology} \section{Μεθοδολογία υλοποίησης} \label{subsection:4-1-implementation-methodology}
Για την επίτευξη των στόχων που ορίστηκαν και την οργάνωση της εργασίας που απαιτείται σε διαχειρίσιμα μέρη, σχεδιάστηκε η χρήση διάφορων εργαλείων και μεθόδων ανάπτυξης λογισμικού, όπως το σύστημα ελέγχου εκδόσεων (version control system) Git, η μέθοδος οργάνωσης Scrum και οι διαδικασίες ανάπτυξης DevOps. Τα εργαλεία αυτά είναι δοκιμασμένα και έχουν εδραιωθεί στη σύγχρονη ανάπτυξη λογισμικού. Για την επίτευξη των στόχων που ορίστηκαν και την οργάνωση της εργασίας που απαιτείται σε διαχειρίσιμα μέρη, χρησιμοποιήθηκαν διάφορα εργαλεία και μέθοδοι ανάπτυξης λογισμικού, όπως το σύστημα ελέγχου εκδόσεων (version control system) Git, η μέθοδος οργάνωσης Scrum και οι διαδικασίες ανάπτυξης DevOps. Τα εργαλεία αυτά είναι δοκιμασμένα και έχουν εδραιωθεί στη σύγχρονη ανάπτυξη λογισμικού.
Μέσα από την χρήση των παραπάνω εργαλείων επιτυγχάνεται η ομαλή συνεργασία στην ανάπτυξη του λογισμικού. Κάθε μέλος της ομάδας δύναται να εργαστεί ανεξάρτητα και χωρίς την ανάγκη διαρκούς επικοινωνίας με τα υπόλοιπα μέλη. Οι στόχοι είναι ορισμένοι, σαφείς και χωρισμένοι σε διαχειρίσιμα μέρη τα οποία δεν καταβάλουν τα μέλη. Ταυτόχρονα, έχοντας ως έδρα καθιερωμένα πρότυπα ανάπτυξης, παρέχεται φορμαλισμός και έτοιμες μέθοδοι επίλυσης προβλημάτων, γεγονός που λειτουργεί καταλυτικά και βοηθά στην αποφυγή τελμάτων κατά τη συγγραφή του κώδικα. Μέσα από την χρήση των παραπάνω εργαλείων επιτυγχάνεται η ομαλή συνεργασία στην ανάπτυξη του λογισμικού. Κάθε μέλος της ομάδας δύναται να εργαστεί ανεξάρτητα και χωρίς την ανάγκη διαρκούς επικοινωνίας με τα υπόλοιπα μέλη. Οι στόχοι είναι ορισμένοι, σαφείς και χωρισμένοι σε διαχειρίσιμα μέρη τα οποία δεν καταβάλλουν τα μέλη. Ταυτόχρονα, έχοντας ως έδρα καθιερωμένα πρότυπα ανάπτυξης, παρέχεται φορμαλισμός και έτοιμες μέθοδοι επίλυσης προβλημάτων, γεγονός που λειτουργεί καταλυτικά και βοηθά στην αποφυγή τελμάτων κατά τη συγγραφή του κώδικα.
Το Git είναι δωρεάν λογισμικό ανοιχτού κώδικα το οποίο επιτρέπει και επικουρεί την απρόσκοπτη ανάπτυξη λογισμικού από πολλαπλά μέλη μίας ομάδας, ταυτόχρονα και διανεμημένα. Αυτό επιτυγχάνεται παρέχοντας ένα πλαίσιο από εργαλεία τα οποία βοηθούν την διαχείριση και ενσωμάτωση των διαφορετικών εκδόσεων του κώδικα τις οποίες αναπτύσσει κάθε μέλος της ομάδας ξεχωριστά. Υπάρχουν διάφορα μοντέλα χρήσης του Git και πιο συγκεκριμένα της δυνατότητας που δίνει για δημιουργία, ανάπτυξη και ένωση (merge) κλαδιών (branches). Το Git είναι δωρεάν λογισμικό ανοιχτού κώδικα το οποίο επιτρέπει και επικουρεί την απρόσκοπτη ανάπτυξη λογισμικού από πολλαπλά μέλη μίας ομάδας, ταυτόχρονα και διανεμημένα. Αυτό επιτυγχάνεται παρέχοντας ένα πλαίσιο από εργαλεία τα οποία βοηθούν την διαχείριση και ενσωμάτωση των διαφορετικών εκδόσεων του κώδικα τις οποίες αναπτύσσει κάθε μέλος της ομάδας ξεχωριστά. Υπάρχουν διάφορα μοντέλα χρήσης του Git και πιο συγκεκριμένα της δυνατότητας που δίνει για δημιουργία, ανάπτυξη και ένωση (merge) κλαδιών (branches).
@ -10,17 +10,17 @@
Το Scrum είναι μία μέθοδος οργάνωσης στην οποία ο επιμελητής του Scrum (Scrum master) διαχωρίζει τα ανεξάρτητα μέρη εργασίας (tasks) που πρέπει να υλοποιηθούν για την ολοκλήρωση των στόχων ενός project. Τα μέρη αυτά περιγράφονται αναλυτικά μαζί με τις απαιτήσεις τους και κατατίθενται σε μία λίστα εργασιών (backlog). Έπειτα, μέσα από συσκέψεις (meetings), επιλέγεται ένας αριθμός από tasks τα οποία ορίζουν το επόμενο προγραμματιστικό κύκλο (sprint). Κάθε task ανατίθεται σε κάποιο μέλος για υλοποίηση. Για το Sprint ορίζεται μία χρονική διάρκεια, στόχος της οποίας είναι η περάτωση όλων των tasks πριν τη λήξη της. Στο τέλος της προθεσμίας που ορίστηκε για το Sprint τα μέλη της ομάδας αποτιμούν τα αποτελέσματα και ορίζουν το επόμενο Sprint. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί. Το Scrum είναι μία μέθοδος οργάνωσης στην οποία ο επιμελητής του Scrum (Scrum master) διαχωρίζει τα ανεξάρτητα μέρη εργασίας (tasks) που πρέπει να υλοποιηθούν για την ολοκλήρωση των στόχων ενός project. Τα μέρη αυτά περιγράφονται αναλυτικά μαζί με τις απαιτήσεις τους και κατατίθενται σε μία λίστα εργασιών (backlog). Έπειτα, μέσα από συσκέψεις (meetings), επιλέγεται ένας αριθμός από tasks τα οποία ορίζουν το επόμενο προγραμματιστικό κύκλο (sprint). Κάθε task ανατίθεται σε κάποιο μέλος για υλοποίηση. Για το Sprint ορίζεται μία χρονική διάρκεια, στόχος της οποίας είναι η περάτωση όλων των tasks πριν τη λήξη της. Στο τέλος της προθεσμίας που ορίστηκε για το Sprint τα μέλη της ομάδας αποτιμούν τα αποτελέσματα και ορίζουν το επόμενο Sprint. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί.
Λόγω του πολύ μικρού μεγέθους της ομάδας, το Scrum ακολουθήθηκε ελαστικά. Συγκεκριμένα, δεν ορίστηκε ένας συγκεκριμένος επιμελητής του board αλλά κάθε μέλος της ομάδας φρόντιζε για τον ορισμό και την περιγραφή ενός μέρους των tasks. Τα sprints δεν ήταν συνεχόμενα και δεν είχαν πάντα τον ίδιο χρόνο εκτέλεσης αλλά προσαρμόζονταν ανάλογα με τις εκάστοτε ανάγκες και τον χρόνο των μελών. Κατά βάση, χρησιμοποιήθηκε η μέθοδος Kanban (που χρησιμοποιείται από το ίδιο το Scrum), για την οπτικοποίηση των tasks. Τα tasks χωρίστηκαν σε λίστες οι οποίες περιλαμβάνουν: Λόγω του πολύ μικρού μεγέθους της ομάδας, το Scrum ακολουθήθηκε ελαστικά. Συγκεκριμένα, δεν ορίστηκε ένας συγκεκριμένος επιμελητής του board αλλά κάθε μέλος της ομάδας φρόντιζε για τον ορισμό και την περιγραφή ενός μέρους των tasks. Τα sprints δεν ήταν συνεχόμενα και δεν είχαν πάντα τον ίδιο χρόνο εκτέλεσης αλλά προσαρμόζονταν ανάλογα με τις εκάστοτε ανάγκες και τον χρόνο των μελών. Κατά βάση, χρησιμοποιήθηκε η μέθοδος Kanban (που χρησιμοποιείται από το ίδιο το Scrum), για την οπτικοποίηση των tasks. Τα tasks χωρίστηκαν κατά κύριο λόγο στις παρακάτω λίστες:
\begin{itemize} \begin{itemize}
\item σε αναμονή (backlog), περιλαμβάνει tasks τα οποία δεν έχουν ακόμα εισαχθεί σε κάποιο sprint \item "Αναμονής" (backlog), η οποία περιέχει tasks τα οποία δεν έχουν ακόμα εισαχθεί σε κάποιο sprint
\item ενεργό sprint (sprint/todo), περιλαμβάνει tasks τα οποία συμμετέχουν στο ενεργό (τωρινό) sprint \item "Ενεργού sprint" (sprint/todo), που περιλαμβάνει tasks τα οποία συμμετέχουν στο ενεργό (τρέχον) sprint
\item εκτέλεση (in progress/doing), περιλαμβάνει tasks για τα οποία έχει ξεκινήσει η ανάπτυξη από κάποιο μέλος της ομάδας \item "Εκτέλεσης" (in progress/doing), η οποία περιλαμβάνει tasks για τα οποία έχει ξεκινήσει η ανάπτυξη από κάποιο μέλος της ομάδας
\item έλεγχος και αξιολόγησης (testing/code review), περιλαμβάνει tasks των οποίων η ανάπτυξη έχει ολοκληρωθεί και βρίσκονται στο στάδιο ελέγχου (testing) ή αναμονής σε pull request \item "Ελέγχου και αξιολόγησης" (testing/code review), η οποία περιέχει tasks των οποίων η ανάπτυξη έχει ολοκληρωθεί και βρίσκονται στο στάδιο ελέγχου (testing) ή αναμονής σε pull request
\item ολοκλήρωση (done), περιλαμβάνει tasks τα οποία έχουν τελειώσει, δηλαδή των οποίων η ανάπτυξη έχει ολοκληρωθεί και το pull request έχει γίνει merge \item "Ολοκλήρωσης" (done), που περιλαμβάνει tasks τα οποία έχουν τελειώσει, δηλαδή των οποίων η ανάπτυξη έχει ολοκληρωθεί και το pull request έχει γίνει merge
\end{itemize} \end{itemize}
Τέλος, ορίστηκαν στις λίστες οι μέγιστοι αριθμοί tasks που μπορούν τα υπάρχουν σε κάθε χρονική στιγμή. Για παράδειγμα, μέχρι τέσσερα tasks στην λίστα εκτέλεσης. Αυτό έγινε για ενθάρρυνση της ολοκλήρωσης των tasks από τα μέλη, σε αντίθεση με την εγκατάλειψή τους σε ημιτελή κατάσταση της ανάπτυξης για την ανάληψη κάποιου νέου task. Τέλος, ορίστηκαν στις λίστες οι μέγιστοι αριθμοί από tasks που μπορούν τα υπάρχουν σε κάθε χρονική στιγμή. Για παράδειγμα, μέχρι τέσσερα tasks στην λίστα εκτέλεσης. Αυτό έγινε για ενθάρρυνση της ολοκλήρωσης των tasks από τα μέλη, σε αντίθεση με την εγκατάλειψή τους σε ημιτελή κατάσταση της ανάπτυξης για την ανάληψη κάποιου νέου task.
\begin{figure}[H] \begin{figure}[H]
\centering \centering
@ -32,10 +32,10 @@
Κατά την διαδικασία της ανάπτυξης του κώδικα, εφαρμόστηκαν επίσης οι τακτικές που ορίζονται από το DevOps σε ό,τι αφορά το deployment των υπηρεσιών. Το DevOps ορίζει διάφορα εργαλεία που αποσκοπούν στην απρόσκοπτη, αυτοματοποιημένη και γρήγορα ενσωμάτωση του κώδικα από το στάδιο της συγγραφής μέχρι την ολοκλήρωση και εγκατάσταση. Τα εργαλεία που χρησιμοποιήθηκαν εδώ είναι: Κατά την διαδικασία της ανάπτυξης του κώδικα, εφαρμόστηκαν επίσης οι τακτικές που ορίζονται από το DevOps σε ό,τι αφορά το deployment των υπηρεσιών. Το DevOps ορίζει διάφορα εργαλεία που αποσκοπούν στην απρόσκοπτη, αυτοματοποιημένη και γρήγορα ενσωμάτωση του κώδικα από το στάδιο της συγγραφής μέχρι την ολοκλήρωση και εγκατάσταση. Τα εργαλεία που χρησιμοποιήθηκαν εδώ είναι:
\begin{itemize} \begin{itemize}
\item συνεχής έλεγχος (continuous testing) \item Συνεχής έλεγχος (continuous testing)
\item συνεχής ολοκλήρωση (continuous integration) \item Συνεχής ολοκλήρωση (continuous integration)
\item συνεχής παράδοση (continuous delivery) \item Συνεχής παράδοση (continuous delivery)
\item συνεχής εγκατάσταση (continuous deployment) \item Συνεχής εγκατάσταση (continuous deployment)
\end{itemize} \end{itemize}
Για την υλοποίηση των τακτικών αυτών επιλέχθηκε μετά από εκτενή έρευνα η πλατφόρμα Jenkins. Το Jenkins συνδυάστηκε με την πλατφόρμα εικονοποίησης Docker ώστε να ακολουθηθούν οι τελευταίες ενδεδειγμένες πρακτικές της βιομηχανίας. Έγινε συγγραφή του αρχείου Jenkinsfile το οποίο περιγράφει με κώδικα την ροή εργασιών (pipeline) που πρέπει να ακολουθηθεί μετά από κάθε αλλαγή στον κώδικα. Η εκτέλεση του pipeline πραγματοποιείται αυτόματα από το Jenkins. Για την υλοποίηση των τακτικών αυτών επιλέχθηκε μετά από εκτενή έρευνα η πλατφόρμα Jenkins. Το Jenkins συνδυάστηκε με την πλατφόρμα εικονοποίησης Docker ώστε να ακολουθηθούν οι τελευταίες ενδεδειγμένες πρακτικές της βιομηχανίας. Έγινε συγγραφή του αρχείου Jenkinsfile το οποίο περιγράφει με κώδικα την ροή εργασιών (pipeline) που πρέπει να ακολουθηθεί μετά από κάθε αλλαγή στον κώδικα. Η εκτέλεση του pipeline πραγματοποιείται αυτόματα από το Jenkins.
@ -57,4 +57,4 @@
\label{figure:4.1.implementation-methodology-jenkins-pipeline} \label{figure:4.1.implementation-methodology-jenkins-pipeline}
\end{figure} \end{figure}
Με την χρήση του Jenkins αυτοματοποιείται με μεγάλη ευκολία ένα σημαντικό μέρος των διαδικασιών ανάπτυξης και δημοσίευσης του κώδικα. Με την χρήση του συγκεκριμένου pipeline γίνεται σίγουρο ό,τι σε κάθε αλλαγή, ασχέτως του κλαδιού ανάπτυξης ο κώδικας ελέγχεται και τα αποτελέσματα των tests είναι αποθηκευμένα και διαθέσιμα για ανάλυση. Ακόμα, για το κλαδί develop, αυτοματοποιείται η ολοκλήρωση των πακέτων και η εγκατάστασή τους σε περιβάλλον δοκιμής (staging), γεγονός που διευκολύνει σημαντικά τις συλλογικές δοκιμές από την ομάδα σε διαφορετικά περιβάλλοντα χρήσης (browsers). Τέλος, για το κλαδί master, αυτοματοποιείται η διαδικασία δημοσίευσης των docker images, μηδενίζοντας έτσι τον χρόνο που πρέπει να καταβάλουν τα μέλη της ομάδας σε αυτό. Με τη χρήση του Jenkins αυτοματοποιείται με μεγάλη ευκολία ένα σημαντικό μέρος των διαδικασιών ανάπτυξης και δημοσίευσης του κώδικα. Με τη χρήση του συγκεκριμένου pipeline γίνεται σίγουρο ό,τι σε κάθε αλλαγή, ασχέτως του κλαδιού ανάπτυξης ο κώδικας ελέγχεται και τα αποτελέσματα των tests είναι αποθηκευμένα και διαθέσιμα για ανάλυση. Ακόμα, για το κλαδί develop, αυτοματοποιείται η ολοκλήρωση των πακέτων και η εγκατάστασή τους σε περιβάλλον δοκιμής (staging), γεγονός που διευκολύνει σημαντικά τις συλλογικές δοκιμές από την ομάδα σε διαφορετικά περιβάλλοντα χρήσης (browsers). Τέλος, για το κλαδί master, αυτοματοποιείται η διαδικασία δημοσίευσης των docker images, μηδενίζοντας έτσι τον χρόνο που πρέπει να καταβάλουν τα μέλη της ομάδας σε αυτό.

2
chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.3.jenkins.tex

@ -2,7 +2,7 @@
\logo{chapter-4/4.2.jenkins-logo}{Jenkins logo} \logo{chapter-4/4.2.jenkins-logo}{Jenkins logo}
Το Jenkins είναι ένας πλήρως παραμετροποιήσιμος και επεκτάσιμος διακομιστής αυτοματοποίησης (automation server). Ο διακομιστής μπορεί να αυτοματοποιήσει τις διαδικασίες ελέγχου, ολοκλήρωσης, παράδοσης και εγκατάστασης του κώδικα, υλοποιώντας έτσι βασικές διαδικασίες που ορίζει το DevOps, συνεχή έλεγχο (continuous testing), συνεχή ολοκλήρωση (continuous integration), συνεχή παράδοση (continuous delivery) και συνεχή εγκατάσταση (continuous deployment). Επίσης, το Jenkins μπορεί να παραμετροποιηθεί μέσω των ρυθμίσεων που προσφέρει και των επεκτάσεων (plugins) που υπάρχουν ώστε να παρέχει τις δυνατότητες αυτές για οποιαδήποτε πλατφόρμα, γλώσσα και περιβάλλον ανάπτυξης. Το Jenkins είναι ένας πλήρως παραμετροποιήσιμος και επεκτάσιμος διακομιστής αυτοματοποίησης (\textenglish{automation server}). Ο διακομιστής μπορεί να αυτοματοποιήσει τις διαδικασίες ελέγχου, ολοκλήρωσης, παράδοσης και εγκατάστασης του κώδικα, υλοποιώντας έτσι βασικές διαδικασίες που ορίζει το DevOps, συνεχή έλεγχο (\textenglish{continuous testing}), συνεχή ολοκλήρωση (\textenglish{continuous integration}), συνεχή παράδοση (\textenglish{continuous delivery}) και συνεχή εγκατάσταση (\textenglish{continuous deployment}). Επίσης, το Jenkins μπορεί να παραμετροποιηθεί μέσω των ρυθμίσεων που προσφέρει και των επεκτάσεων (plugins) που υπάρχουν ώστε να παρέχει τις δυνατότητες αυτές για οποιαδήποτε πλατφόρμα, γλώσσα και περιβάλλον ανάπτυξης.
Στο Jenkins είναι δυνατός ο ορισμός με χρήση κώδικα (σε Groovy και στο DSL που παρέχεται από το Jenkins) πολλαπλών γραμμών εργασιών (pipeline). Οι γραμμές εργασιών συντίθενται από πολλαπλά βήματα τα οποία επιτελούν ξεχωριστούς στόχους προς το τελικό αποτέλεσμα της γραμμής. Τα βήματα μπορούν να τρέχουν σειριακά ή παράλληλα. Ενώ δίνεται η δυνατότητα εκτέλεσης σε πολλαπλά, διανεμημένα συστήματα καθώς και άλλες προχωρημένες λειτουργικότητες. Στο Jenkins είναι δυνατός ο ορισμός με χρήση κώδικα (σε Groovy και στο DSL που παρέχεται από το Jenkins) πολλαπλών γραμμών εργασιών (pipeline). Οι γραμμές εργασιών συντίθενται από πολλαπλά βήματα τα οποία επιτελούν ξεχωριστούς στόχους προς το τελικό αποτέλεσμα της γραμμής. Τα βήματα μπορούν να τρέχουν σειριακά ή παράλληλα. Ενώ δίνεται η δυνατότητα εκτέλεσης σε πολλαπλά, διανεμημένα συστήματα καθώς και άλλες προχωρημένες λειτουργικότητες.

2
chapters/4.application-implementation/4.3.implementation-architecture.tex

@ -231,7 +231,7 @@
\vspace{0.5cm} \vspace{0.5cm}
\textbf{Περιγραφή - Στόχοι υπηρεσίας} \textbf{Περιγραφή - Στόχοι υπηρεσίας}
Η υπηρεσία Ganache αποτελεί μία εφαρμογή τερματικού η οποία είναι μέρος της δωρεάν σουίτας ανοιχτού λογισμικού Truffle. Η εφαρμογή δημιουργεί ένα τοπικό, ιδιωτικό blockchain το οποίο ακολουθεί το πρότυπο του Ethereum. Επίσης, η εφαρμογή δρα ως minner στο δίκτυο, διεκπεραιώνοντας όλες τις συναλλαγές. Η υπηρεσία Ganache αποτελεί μία εφαρμογή τερματικού η οποία είναι μέρος της δωρεάν σουίτας ανοιχτού λογισμικού Truffle. Η εφαρμογή δημιουργεί ένα τοπικό, ιδιωτικό blockchain το οποίο ακολουθεί το πρότυπο του Ethereum. Επίσης, η εφαρμογή δρα ως miner στο δίκτυο, διεκπεραιώνοντας όλες τις συναλλαγές.
\vspace{0.5cm} \vspace{0.5cm}
\textbf{Διανομή} \textbf{Διανομή}

12
chapters/4.application-implementation/4.4.problems-faced.tex

@ -5,16 +5,16 @@
Μία από τις μεγαλύτερες τροχοπέδες που καθυστέρησε σοβαρά την ανάπτυξη ήταν η πρωιμότητα των βιβλιοθηκών και εργαλείων ανάπτυξης. Οι βασικότερες βιβλιοθήκες που χρησιμοποιήθηκαν ήταν σε πρώτο ή δεύτερο πειραματικό στάδιο (alpha και beta phase αντίστοιχα). Συγκεκριμένα: Μία από τις μεγαλύτερες τροχοπέδες που καθυστέρησε σοβαρά την ανάπτυξη ήταν η πρωιμότητα των βιβλιοθηκών και εργαλείων ανάπτυξης. Οι βασικότερες βιβλιοθήκες που χρησιμοποιήθηκαν ήταν σε πρώτο ή δεύτερο πειραματικό στάδιο (alpha και beta phase αντίστοιχα). Συγκεκριμένα:
\begin{itemize} \begin{itemize}
\item όλα τα εργαλεία της σουίτας Truffle ήταν σε alpha phase κατά την ανάπτυξη (κάποια έχουν περάσει σε beta πλέον) \item Όλα τα εργαλεία της σουίτας Truffle ήταν σε alpha phase κατά την ανάπτυξη (κάποια έχουν περάσει σε beta πλέον).
\item το IPFS (συγκεκριμένα η βιβλιοθήκη js-ipfs) βρίσκεται ακόμα σε alpha έκδοση \item Το IPFS (συγκεκριμένα η βιβλιοθήκη js-ipfs) βρίσκεται ακόμα σε alpha έκδοση.
\item η OrbitDB βρίσκεται ακόμα σε alpha phase \item Η OrbitDB βρίσκεται ακόμα σε alpha phase.
\item η γλώσσα των contracts, Solidity, ακόμα δεν έχει βγάλει version 1.0 καθώς αλλάζει διαρκώς με breaking changes\footnote{Από την σελίδα του πηγαίου κώδικα https://github.com/ethereum/solidity} \item Η γλώσσα των contracts, Solidity, ακόμα δεν έχει βγάλει version 1.0 καθώς αλλάζει διαρκώς με breaking changes\footnote{Από τη σελίδα του πηγαίου κώδικα \url{https://github.com/ethereum/solidity}}.
\end{itemize} \end{itemize}
Η έλλειψη αυτή, ώριμων βιβλιοθηκών και εργαλείων προκάλεσε μείζονα προβλήματα. Συχνά έπρεπε να διορθωθούν προβλήματα των βιβλιοθηκών ή να γίνει δουλειά που να τα παρακάμπτει. Άλλες φορές χρειάστηκαν πολλές ώρες αποσφαλμάτωσης και δοκιμών ώστε να δουλέψουν τα χαρακτηριστικά που υπόσχονταν τα εργαλεία. Αυτή η έλλειψη αυτή ώριμων βιβλιοθηκών και εργαλείων προκάλεσε μείζονα προβλήματα. Συχνά έπρεπε να διορθωθούν προβλήματα των βιβλιοθηκών ή να γίνει δουλειά που να τα παρακάμπτει. Άλλες φορές χρειάστηκαν πολλές ώρες αποσφαλμάτωσης και δοκιμών ώστε να δουλέψουν τα χαρακτηριστικά που υπόσχονταν τα εργαλεία.
Ένα άλλο πρόβλημα ήταν η έλλειψη εργαλείων για ορισμένες διαδικασίες. Δύο βασικά παραδείγματα αυτού αποτελούν, πρώτων η έλλειψη υποστήριξης για integration/end-to-end testing των contracts κατά την ανάπτυξη (πλέον υπάρχουν κάποιες λύσεις) και δεύτερων η έλλειψη έτοιμων διαδικασιών, plugins και integrations του Jenkins με τα εργαλεία ανάπτυξης και ειδικά με τη σουίτα Truffle. Ένα άλλο πρόβλημα ήταν η έλλειψη εργαλείων για ορισμένες διαδικασίες. Δύο βασικά παραδείγματα αυτού αποτελούν, πρώτων η έλλειψη υποστήριξης για integration/end-to-end testing των contracts κατά την ανάπτυξη (πλέον υπάρχουν κάποιες λύσεις) και δεύτερων η έλλειψη έτοιμων διαδικασιών, plugins και integrations του Jenkins με τα εργαλεία ανάπτυξης και ειδικά με τη σουίτα Truffle.
Σε παρόμοια κατάσταση βρίσκεται και η γενική συναίνεση σχετικά με τα best practices. Σε διάφορα μέρη της ανάπτυξης παρατηρήθηκε ότι δεν υπήρχε κάποια διαμορφωμένη άποψη στην κοινότητα και κάθε ομάδα ανάπτυξης εφάρμοζε την δική της ιδέα. Αυτό καθιστά δύσκολη την ανάπτυξη από αρχάριους προγραμματιστές χωρίς καθοδήγηση. Ένα άλλο, σχετικό πρόβλημα που παρατηρήθηκε είναι ότι στον χώρο υπάρχει ακόμα πολλής θόρυβος, δηλαδή σημαντικό μέρος των πηγών που βρίσκονται στο διαδίκτυο είναι αντικρουόμενες ή σε πολλές περιπτώσεις οι προτάσεις τους απορρίπτονται από την κοινότητα. Σε παρόμοια κατάσταση βρίσκεται και η γενική συναίνεση σχετικά με τα best practices. Σε διάφορα μέρη της ανάπτυξης παρατηρήθηκε ότι δεν υπήρχε κάποια διαμορφωμένη άποψη στην κοινότητα και κάθε ομάδα ανάπτυξης εφάρμοζε την δική της ιδέα. Αυτό καθιστά δύσκολη την ανάπτυξη από αρχάριους προγραμματιστές χωρίς καθοδήγηση. Ένα άλλο, σχετικό πρόβλημα που παρατηρήθηκε είναι ότι στον χώρο υπάρχει ακόμα πολλής θόρυβος, δηλαδή σημαντικό μέρος των πηγών που βρίσκονται στο διαδίκτυο είναι αντικρουόμενες ή σε πολλές περιπτώσεις οι προτάσεις τους απορρίπτονται από την κοινότητα.
Τελικώς, ένα μη τεχνικό ζήτημα που έπρεπε να αντιμετωπιστεί είναι η αβεβαιότητα της βιωσιμότητας, εξέλιξης και αποδοχής της τεχνολογίας Blockchain και των εφαρμογών που βασίζονται σε αυτή από το ευρύ κοινό. Αυτό συναίνεσε αρνητικά καθώς δημιούργησε μία επιτακτικότητα προσοχής της εμπειρίας του χρήστη (UX), κάτι που φυσιολογικά δεν αποτελεί σημαντικό μέρος της ανάπτυξης ενός PoC. Η ανάγκη για προσοχή του UX πηγάζει από την ανάγκη για συγκράτηση των χρηστών (user retention) με στόχο την αντιστροφή της αβεβαιότητας και την παροχή μίας γνησίως ευχάριστης εμπειρίας. Τελικώς, ένα μη τεχνικό ζήτημα που έπρεπε να αντιμετωπιστεί είναι η αβεβαιότητα της βιωσιμότητας, εξέλιξης και αποδοχής της τεχνολογίας blockchain και των εφαρμογών που βασίζονται σε αυτή από το ευρύ κοινό. Αυτό συναίνεσε αρνητικά καθώς δημιούργησε μία επιτακτικότητα προσοχής της εμπειρίας του χρήστη (UX), κάτι που φυσιολογικά δεν αποτελεί σημαντικό μέρος της ανάπτυξης ενός PoC. Η ανάγκη για προσοχή του UX πηγάζει από την ανάγκη για συγκράτηση των χρηστών (user retention) με στόχο την αντιστροφή της αβεβαιότητας και την παροχή μίας γνησίως ευχάριστης εμπειρίας.

24
chapters/4.application-implementation/4.5.implemented-parts.tex

@ -3,23 +3,23 @@
Κατά την υλοποίηση εμφανίστηκαν διάφορα προβλήματα που δεν είχαν προβλεφθεί όπως αναλύθηκε στο προηγούμενο κεφάλαιο και τα οποία προκάλεσαν καθυστερήσεις στην ολοκλήρωση των tasks. Λόγω των καθυστερήσεων αυτών έγιναν διάφορες αναδιαμορφώσεις του προγραμματισμού των Sprint καθώς και διαπραγματεύσεις της σημαντικότητας των χαρακτηριστικών. Από τον επανασχεδιασμό και τις προσαρμογές αυτές προέκυψαν μερικές αλλαγές στο τελικό σετ των χαρακτηριστικών της πλατφόρμας σε σχέση με ό,τι είχε αρχικά προδιαγραφεί. Τα χαρακτηριστικά που υλοποιήθηκαν τελικά είναι: Κατά την υλοποίηση εμφανίστηκαν διάφορα προβλήματα που δεν είχαν προβλεφθεί όπως αναλύθηκε στο προηγούμενο κεφάλαιο και τα οποία προκάλεσαν καθυστερήσεις στην ολοκλήρωση των tasks. Λόγω των καθυστερήσεων αυτών έγιναν διάφορες αναδιαμορφώσεις του προγραμματισμού των Sprint καθώς και διαπραγματεύσεις της σημαντικότητας των χαρακτηριστικών. Από τον επανασχεδιασμό και τις προσαρμογές αυτές προέκυψαν μερικές αλλαγές στο τελικό σετ των χαρακτηριστικών της πλατφόρμας σε σχέση με ό,τι είχε αρχικά προδιαγραφεί. Τα χαρακτηριστικά που υλοποιήθηκαν τελικά είναι:
\begin{itemize} \begin{itemize}
\item η εγγραφή χρήστη και η δημιουργία των τοπικών βάσεων του όπως περιγράφεται στις \ref{srs:functional-srs-sign-up} \& \ref{srs:functional-srs-create-user-databases} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-signup} \item Η εγγραφή χρήστη και η δημιουργία των τοπικών βάσεων του, όπως περιγράφονται στις \ref{srs:functional-srs-sign-up} \& \ref{srs:functional-srs-create-user-databases} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-signup}.
\item η αυτόματη είσοδος χρήστη όπως περιγράφεται στην \ref{srs:functional-srs-sign-in} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-signin} \item Η αυτόματη είσοδος χρήστη, όπως περιγράφεται στη \ref{srs:functional-srs-sign-in} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-signin}.
\item η δημιουργία θέματος και η δημιουργία ψηφοφοριών όπως περιγράφεται στις \ref{srs:functional-srs-create-topic} \& \ref{srs:functional-srs-create-polls} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-create-topic} \item Η δημιουργία θέματος και η δημιουργία ψηφοφοριών, όπως περιγράφονται στις \ref{srs:functional-srs-create-topic} \& \ref{srs:functional-srs-create-polls} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-create-topic}.
\item η περιήγηση στα υπάρχοντας θέματα όπως περιγράφεται στην \ref{srs:functional-srs-browse-topics} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-fetch-topic} \item Η περιήγηση στα υπάρχοντας θέματα, όπως περιγράφεται στη \ref{srs:functional-srs-browse-topics} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-fetch-topic}.
\item η δημοσίευση μηνύματος όπως περιγράφεται στην \ref{srs:functional-srs-create-post} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-create-post} \item Η δημοσίευση μηνύματος, όπως περιγράφεται στη \ref{srs:functional-srs-create-post} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-create-post}.
\item η επεξεργασία μηνύματος όπως περιγράφεται στην \ref{srs:functional-srs-modify-post} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-modify-post} \item Η επεξεργασία μηνύματος, όπως περιγράφεται στη \ref{srs:functional-srs-modify-post} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-modify-post}.
\item η ψήφιση σε ψηφοφορία όπως περιγράφεται στην \ref{srs:functional-srs-vote-polls} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-vote-in-poll} \item Η ψήφιση σε ψηφοφορία, όπως περιγράφεται στη \ref{srs:functional-srs-vote-polls} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-vote-in-poll}.
\item η ψήφιση σε μηνύματα όπως περιγράφεται στην \ref{srs:functional-srs-vote-posts} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-vote-post} \item Η ψήφιση σε μηνύματα, όπως περιγράφεται στη \ref{srs:functional-srs-vote-posts} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-vote-post}.
\item η διαγραφή των τοπικών δεδομένων όπως περιγράφεται στην \ref{srs:functional-srs-delete-local-data} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-delete-local-data} \item Η διαγραφή των τοπικών δεδομένων, όπως περιγράφεται στη \ref{srs:functional-srs-delete-local-data} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-delete-local-data}.
\end{itemize} \end{itemize}
Τα παραπάνω αντιστοιχούν σε 11 ολοκληρωμένες από τις 13 προδιαγεγραμμένες ΛΑ ή πλήρωση 84.6\%, ποσοστό που θεωρείται από τους συγγραφείς επαρκές για την εξαγωγή συμπερασμάτων για τον χώρο των DApps και υπερβάλλων για τα πλαίσια ενός PoC. Στο παράρτημα \ref{screenshots-appendix} παρατίθενται τα στιγμιότυπα οθόνης των υλοποιημένων χαρακτηριστικών. Τα παραπάνω αντιστοιχούν σε 11 ολοκληρωμένες από τις 13 προδιαγεγραμμένες ΛΑ ή πλήρωση 84.6\%, ποσοστό που θεωρείται από τους συγγραφείς επαρκές για την εξαγωγή συμπερασμάτων για τον χώρο των DApps και υπερβάλλον για τα πλαίσια ενός PoC. Στο παράρτημα \ref{screenshots-appendix} παρατίθενται τα στιγμιότυπα οθόνης των υλοποιημένων χαρακτηριστικών.
Τα χαρακτηριστικά τα οποία παραλήφθηκαν είναι τα παρακάτω: Τα χαρακτηριστικά τα οποία παραλήφθηκαν είναι τα παρακάτω:
\begin{itemize} \begin{itemize}
\item η δημιουργία κοινοτήτων και ο ορισμός εξωτερικών contracts για τα tokens τους όπως περιγράφεται στις \ref{srs:functional-srs-create-communities} \& \ref{srs:functional-srs-assign-community-contract} και στο σενάριο χρήσης \ref{subsection:3-10-use-case-create-community} \item Η δημιουργία κοινοτήτων και ο ορισμός εξωτερικών contracts για τα tokens τους, όπως περιγράφονται στις \ref{srs:functional-srs-create-communities} \& \ref{srs:functional-srs-assign-community-contract} και στο σενάριο χρήσης \ref{subsection:3-10-use-case-create-community}.
\end{itemize} \end{itemize}
Τέλος, η ΜΛΑ που αφορά την ελαχιστοποίηση των fees (\ref{srs:non-functional-srs-minimize-fees}) ακολουθήθηκε κατά το δυνατόν σε όλη τη διαδικασία σχεδιασμού και υλοποίησης. Η ΜΛΑ σχετικά με την αναβαθμισιμότητα των contracts (\ref{srs:non-functional-srs-upgrade-contracts}) καταστρατηγήθηκε λόγω του χρόνου που θα απαιτούσε μία τέτοια υλοποίηση. Τέλος, η ΜΛΑ που αφορά την ελαχιστοποίηση των fees (\ref{srs:non-functional-srs-minimize-fees}) ακολουθήθηκε κατά το δυνατόν σε όλη τη διαδικασία σχεδιασμού και υλοποίησης. Η ΜΛΑ σχετικά με την αναβαθμισιμότητα των contracts (\ref{srs:non-functional-srs-upgrade-contracts}) καταστρατηγήθηκε λόγω του χρόνου που θα απαιτούσε μία τέτοια υλοποίηση.
@ -33,7 +33,7 @@
Η ανάγκη για τα νέα πακέτα λογισμικού προέκυψε κατά την πορεία υλοποίησης της διπλωματικής και προστέθηκαν στον χρονοπρογραμματισμό που είχε γίνει στην αρχή της εργασίας. Στην προσαρμογή αυτή βοήθησαν ιδιαίτερα οι Agile τακτικές που ακολουθήθηκαν και η προσαρμοστικότητα που προσφέρει το Scrum σε μεταβαλλόμενες απαιτήσεις. Η ανάγκη για τα νέα πακέτα λογισμικού προέκυψε κατά την πορεία υλοποίησης της διπλωματικής και προστέθηκαν στον χρονοπρογραμματισμό που είχε γίνει στην αρχή της εργασίας. Στην προσαρμογή αυτή βοήθησαν ιδιαίτερα οι Agile τακτικές που ακολουθήθηκαν και η προσαρμοστικότητα που προσφέρει το Scrum σε μεταβαλλόμενες απαιτήσεις.
Τέλος, κατά την υλοποίηση έγινε γρήγορα αντιληπτή η αξία που προσφέρουν ένα δοκιμαστικό περιβάλλον (staging environment) σε συνδυασμό με ένα CI/CD σύστημα. Για το λόγο αυτό πάρθηκε η απόφαση να μεταφερθεί το sprint που αφορούσε αυτά πολύ νωρίτερα στην διαδικασία υλοποίησης, ώστε να μεγιστοποιηθεί η χρήση του. Τέλος, κατά την υλοποίηση έγινε γρήγορα αντιληπτή η αξία που προσφέρουν ένα δοκιμαστικό περιβάλλον (staging environment) σε συνδυασμό με ένα CI/CD σύστημα. Για το λόγο αυτό λήφθηκε η απόφαση να μεταφερθεί το sprint που αφορούσε αυτά πολύ νωρίτερα στην διαδικασία υλοποίησης, ώστε να μεγιστοποιηθεί η χρήση του.
Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα (σχήμα \ref{figure:4.6.design-implementation-differences-sprints}). Με σκούρο πράσινο χρώμα εμφανίζονται τα tasks τα οποία υπήρχαν στο χρονοπρογραμματισμό από τη αρχή και υλοποιήθηκαν, με ανοιχτό πράσινο αυτά τα οποία δεν υπήρχαν στον αρχικό προγραμματισμό αλλά υλοποιήθηκαν και με κόκκινο αυτά τα οποία δεν υλοποιήθηκαν. Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα (σχήμα \ref{figure:4.6.design-implementation-differences-sprints}). Με σκούρο πράσινο χρώμα εμφανίζονται τα tasks τα οποία υπήρχαν στο χρονοπρογραμματισμό από τη αρχή και υλοποιήθηκαν, με ανοιχτό πράσινο αυτά τα οποία δεν υπήρχαν στον αρχικό προγραμματισμό αλλά υλοποιήθηκαν και με κόκκινο αυτά τα οποία δεν υλοποιήθηκαν.

1
misc/packages.tex

@ -15,6 +15,7 @@
\usepackage{fontawesome5} \usepackage{fontawesome5}
% --- Styling --- % --- Styling ---
\PassOptionsToPackage{hyphens}{url}
\usepackage[bookmarksnumbered]{hyperref} % Extensive support for hypertext \usepackage[bookmarksnumbered]{hyperref} % Extensive support for hypertext
\usepackage{authblk} % Support for footnote style author/affiliation \usepackage{authblk} % Support for footnote style author/affiliation
\usepackage{enumitem} % For item lists \usepackage{enumitem} % For item lists

BIN
thesis.pdf

Binary file not shown.
Loading…
Cancel
Save