diff --git a/assets/figures/chapter-3/3.8.implementation-methodology-specification-sprints.png b/assets/figures/chapter-3/3.8.implementation-methodology-specification-sprints.png index 45c172d..00cb691 100644 Binary files a/assets/figures/chapter-3/3.8.implementation-methodology-specification-sprints.png and b/assets/figures/chapter-3/3.8.implementation-methodology-specification-sprints.png differ diff --git a/assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-insert.png b/assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-insert.png deleted file mode 100644 index 04d4255..0000000 Binary files a/assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-insert.png and /dev/null differ diff --git a/assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-read.png b/assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-read.png deleted file mode 100644 index 2d3c295..0000000 Binary files a/assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-read.png and /dev/null differ diff --git a/assets/figures/chapter-4/4.6.design-implementation-differences-sprints.png b/assets/figures/chapter-4/4.6.design-implementation-differences-sprints.png index 2e7fb89..46131c1 100644 Binary files a/assets/figures/chapter-4/4.6.design-implementation-differences-sprints.png and b/assets/figures/chapter-4/4.6.design-implementation-differences-sprints.png differ diff --git a/chapters/1.introduction/1.0.introduction.tex b/chapters/1.introduction/1.0.introduction.tex index 523db09..c427bf1 100644 --- a/chapters/1.introduction/1.0.introduction.tex +++ b/chapters/1.introduction/1.0.introduction.tex @@ -5,4 +5,5 @@ \input{chapters/1.introduction/1.3.problem-definition} \input{chapters/1.introduction/1.4.thesis-goal} \input{chapters/1.introduction/1.5.methodology} -\input{chapters/1.introduction/1.6.document-structure} \ No newline at end of file +\input{chapters/1.introduction/1.6.typography} +\input{chapters/1.introduction/1.7.document-structure} \ No newline at end of file diff --git a/chapters/1.introduction/1.6.typography.tex b/chapters/1.introduction/1.6.typography.tex new file mode 100644 index 0000000..2b6ae70 --- /dev/null +++ b/chapters/1.introduction/1.6.typography.tex @@ -0,0 +1,5 @@ +\section{Τυπογραφικές παραδοχές} \label{section:1-6-typography} + +Η συγγραφή του παρόντος εγγράφου έγινε στο ηλεκτρονικό, τυπογραφικό σύστημα \LaTeX. Στο εξής, το παρόν έγγραφο, η εργασία στην οποία αναφέρεται το έγγραφο αυτό, όπως και οποιοδήποτε μέρος της εργασίας αυτής, θα αναφέρονται στο κείμενο ως "διπλωματική" ή "πτυχιακή" ή "εργασία" ή "αναφορά". + +Ο πηγαίος κώδικας του παρόντος εγγράφου μπορεί να βρεθεί στο αντίστοιχο αποθετήριο κώδικα της διπλωματικής εργασίας\footnote{Δημόσιο αποθετήριο κώδικα αναφοράς της διπλωματικής \url{https://gitlab.com/ecentrics/thesis-report}.}. diff --git a/chapters/1.introduction/1.6.document-structure.tex b/chapters/1.introduction/1.7.document-structure.tex similarity index 96% rename from chapters/1.introduction/1.6.document-structure.tex rename to chapters/1.introduction/1.7.document-structure.tex index adad267..f0f1b62 100644 --- a/chapters/1.introduction/1.6.document-structure.tex +++ b/chapters/1.introduction/1.7.document-structure.tex @@ -1,4 +1,4 @@ -\section{Οργάνωση κεφαλαίων}\label{section:1-6-document-structure} +\section{Οργάνωση κεφαλαίων}\label{section:1-7-document-structure} Η παρούσα διπλωματική εργασία οργανώνεται σε κεφάλαια, ενότητες και υποενότητες, όπως αυτά διατυπώνονται στα \hyperref[toc]{Περιεχόμενα}. Πιο συγκεκριμένα: diff --git a/chapters/3.application-design/3.8.implementation-methodology-specification.tex b/chapters/3.application-design/3.8.implementation-methodology-specification.tex index 2292d31..6313d27 100644 --- a/chapters/3.application-design/3.8.implementation-methodology-specification.tex +++ b/chapters/3.application-design/3.8.implementation-methodology-specification.tex @@ -16,5 +16,3 @@ \caption{Διαχωρισμός σε sprints} \label{figure:3.8.implementation-methodology-specification-sprints} \end{figure} - -%TODO: add tasks for serve (front and contracts) thru IPFS, upgradability diff --git a/chapters/4.application-implementation/4.0.application-implementation.tex b/chapters/4.application-implementation/4.0.application-implementation.tex index 25f3cd3..3bc86e4 100644 --- a/chapters/4.application-implementation/4.0.application-implementation.tex +++ b/chapters/4.application-implementation/4.0.application-implementation.tex @@ -1,5 +1,7 @@ \chapter{Υλοποίηση εφαρμογής}\label{chapter:4-application-implementation} +Στο παρόν κεφάλαιο αναλύονται οι μέθοδοι και οι τεχνολογίες που αναπτύχθηκαν και χρησιμοποιήθηκαν τόσο για την υλοποίηση της ίδιας της εφαρμογής Concordia, όσο και για τη διαμορφώση του συνολικού προγραμματιστικού περιβάλλοντος επί του οποίου αυτή δημιουργήθηκε. + \input{chapters/4.application-implementation/4.1.implementation-methodology} \input{chapters/4.application-implementation/4.2.implementation-technology-stack} \input{chapters/4.application-implementation/4.3.implementation-architecture} diff --git a/chapters/4.application-implementation/4.1.implementation-methodology.tex b/chapters/4.application-implementation/4.1.implementation-methodology.tex index 968ca91..10d849d 100644 --- a/chapters/4.application-implementation/4.1.implementation-methodology.tex +++ b/chapters/4.application-implementation/4.1.implementation-methodology.tex @@ -20,12 +20,14 @@ \item "Ολοκλήρωσης" (done), που περιλαμβάνει tasks τα οποία έχουν τελειώσει, δηλαδή των οποίων η ανάπτυξη έχει ολοκληρωθεί και το pull request έχει γίνει merge \end{itemize} -Τέλος, ορίστηκαν στις λίστες οι μέγιστοι αριθμοί από tasks που μπορούν τα υπάρχουν σε κάθε χρονική στιγμή. Για παράδειγμα, μέχρι τέσσερα tasks στην λίστα εκτέλεσης. Αυτό έγινε για ενθάρρυνση της ολοκλήρωσης των tasks από τα μέλη, σε αντίθεση με την εγκατάλειψή τους σε ημιτελή κατάσταση της ανάπτυξης για την ανάληψη κάποιου νέου task. +Επίσης, ορίστηκαν στις λίστες οι μέγιστοι αριθμοί από tasks που μπορούν τα υπάρχουν σε κάθε χρονική στιγμή (π.χ. μέχρι τέσσερα tasks στην λίστα εκτέλεσης). Αυτό έγινε για ενθάρρυνση της ολοκλήρωσης των tasks από τα μέλη, σε αντίθεση με την εγκατάλειψή τους σε ημιτελή κατάσταση της ανάπτυξης για την ανάληψη κάποιου νέου task. + +Για την υλοποίηση του Scrum χρησιμοποιήθηκε η διαδικτυακή υπηρεσία Trello\footnote{\url{https://trello.com/}}, στιγμιότυπο της οποίας φαίνεται στο παρακάτω σχήμα: \begin{figure}[H] \centering \includegraphics[width=.8\textwidth]{assets/figures/chapter-4/4.1.implementation-methodology-kanban.png} - \caption{Στιγμιότυπο οθόνης της διαδικτυακής υπηρεσίας Trello που χρησιμοποιήθηκε για την υλοποίηση του Scrum} + \caption{Στιγμιότυπο οθόνης της διαδικτυακής υπηρεσίας Trello} \label{figure:4.1.implementation-methodology-kanban} \end{figure} diff --git a/chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-breeze-unit.tex b/chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-breeze-unit.tex index 33807ca..2583ae7 100644 --- a/chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-breeze-unit.tex +++ b/chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-breeze-unit.tex @@ -1,7 +1,7 @@ \subsubsection{Άρθρωμα breeze} \label{subsubsection:4-3-1-eth-breeze-unit} -Το άρθρωμα αυτό αναπτύχθηκε στα πλαίσια της διπλωματικής εργασίας και αποτελεί μία βιβλιοθήκη περίβλημα (wrapper) της βιβλιοθήκης \hyperref[subsection:4-2-4-2-orbit-db]{OrbitDB}, η οποία παρέχει ένα \hyperref[subsection:4-2-2-2-redux]{Redux} store. +Το άρθρωμα αυτό αναπτύχθηκε στα πλαίσια της διπλωματικής εργασίας και αποτελεί μία βιβλιοθήκη περίβλημα (wrapper) της βιβλιοθήκης OrbitDB, η οποία παρέχει ένα Redux store. -Με τη συμπερίληψη του αρθρώματος στο κεντρικό Redux store της εφαρμογής, παρέχεται η δυνατότητα εκτέλεσης των λειτουργιών των OrbitDB βάσεων εντός του γενικότερου flow του frontend της εφαρμογής. Έτσι, οι προγραμματιστικές διεπαφές που προσφέρει η Orbit χρησιμοποιούνται πλέον μέσα από actions, reducers και middleware. +Με τη συμπερίληψη του store του αρθρώματος στο κεντρικό Redux store της εφαρμογής, παρέχεται η δυνατότητα εκτέλεσης των λειτουργιών των OrbitDB βάσεων εντός του γενικότερου flow του frontend της εφαρμογής. Έτσι, οι προγραμματιστικές διεπαφές που προσφέρει η Orbit χρησιμοποιούνται πλέον μέσα από actions, reducers και middleware. Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή βιβλιοθήκης μέσω του μητρώου λογισμικού npm (\url{https://www.npmjs.com/package/@ecentrics/breeze}), ενώ το αποθετήριό του βρίσκεται στο GitLab (\url{https://gitlab.com/ecentrics/breeze}). diff --git a/chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-drizzle-unit.tex b/chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-drizzle-unit.tex index 18ee21a..ecf17a0 100644 --- a/chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-drizzle-unit.tex +++ b/chapters/4.application-implementation/4.3.implementation-architecture/4.3.1.software-units/4.3.1.eth-drizzle-unit.tex @@ -2,6 +2,6 @@ Το άρθρωμα drizzle που χρησιμοποιείται στην υπηρεσία \hyperref[subsection:4-3-2-concordia-application-service]{Concordia Application} είναι μία τροποποιημένη έκδοση της JavaScript βιβλιοθήκης Drizzle (και συγκεκριμένα του @drizzle/store\footnote{\url{https://github.com/trufflesuite/drizzle/tree/develop/packages/store}}), η οποία προσφέρεται από τη σουίτα εργαλείων Truffle. Η τροποποιημένη βιβλιοθήκη αναπτύχθηκε στα πλαίσια της διπλωματικής με στόχο τη διευκόλυνση της χρήσης του Drizle και την επιδιόρθωση προβληματικών σημείων της πρωτότυπης βιβλιοθήκης. -Το άρθρωμα drizzle υλοποιεί τις προγραμματιστικές διεπαφές μέσω των οποίων πραγματοποιείται η επικοινωνία της εφαρμογής με το blockchain. Για την επίτευξη της επικοινωνίας αυτής, η βιβλιοθήκη χρησιμοποιεί τη συλλογή βιβλιοθηκών web3.js η οποία αποτελεί τον πιο διαδεδομένο τρόπο διεπαφής με το blockchain σε αποκεντρωτικές εφαρμογές. Τελικά, παρέχει ένα Redux store, το οποίο συμπεριλαμβάνεται στο κεντρικό store της εφαρμογής. +Το άρθρωμα drizzle υλοποιεί τις προγραμματιστικές διεπαφές μέσω των οποίων πραγματοποιείται η επικοινωνία της εφαρμογής με το blockchain. Για την επίτευξη της επικοινωνίας αυτής, η βιβλιοθήκη χρησιμοποιεί τη συλλογή βιβλιοθηκών web3.js η οποία αποτελεί τον πιο διαδεδομένο τρόπο διεπαφής με το blockchain σε αποκεντρωτικές εφαρμογές. Τελικά, παρέχει ένα \hyperref[subsection:4-2-2-2-redux]{Redux} store, το οποίο συμπεριλαμβάνεται στο κεντρικό store της εφαρμογής. Το άρθρωμα αυτό γίνεται διαθέσιμο για χρήση με τη μορφή βιβλιοθήκης μέσω του μητρώου λογισμικού npm (\url{https://www.npmjs.com/package/@ecentrics/drizzle}), ενώ το αποθετήριό του βρίσκεται στο GitLab (\url{https://gitlab.com/ecentrics/drizzle}). \ No newline at end of file diff --git a/chapters/4.application-implementation/4.3.implementation-architecture/4.3.9.data-flow.tex b/chapters/4.application-implementation/4.3.implementation-architecture/4.3.9.data-flow.tex index 3cffc8a..cbd965b 100644 --- a/chapters/4.application-implementation/4.3.implementation-architecture/4.3.9.data-flow.tex +++ b/chapters/4.application-implementation/4.3.implementation-architecture/4.3.9.data-flow.tex @@ -8,20 +8,20 @@ Τέλος, παρακάτω δίνεται ένα παράδειγμα εισαγωγής πληροφορίας στο σύστημα και έπειτα ανάκτησης της ίδιας πληροφορίας. -Έστω, χρήστης που δημιουργεί νέο θέμα. Τα δεδομένα που παράγονται είναι ο τίτλος του θέματος και το περιεχόμενο του πρώτου μηνύματος. Μεταδεδομένα της δημιουργίας είναι η διεύθυνση του/της δημιουργού του θέματος. Για την αποθήκευση του θέματος στο σύστημα δημιουργείται πρώτα συναλλαγή στο blockchain ώστε να δημιουργηθεί μία νέα εγγραφή στον πίνακα των θεμάτων. Η εγγραφή αυτή δεν περιέχει τίποτα παρά μόνο τη διεύθυνση του/της δημιουργού χρήστη. Αν η συναλλαγή είναι επιτυχής, θα επιστραφεί ο αύξων αριθμός του νέου θέματος. Έπειτα, στην προσωπική βάση OrbitDB του/της χρήστη και στον πίνακα των θεμάτων θα προστεθεί εγγραφή με αναγνωριστικό τον αύξων αριθμό του θέματος όπου θα αποθηκευτούν τα δεδομένα του τίτλου και πρώτου μηνύματος. Στο σχήμα \ref{figure:4-3-data-flow-insert} παρουσιάζεται γραφικά η διαδικασία. +Έστω, χρήστης που δημιουργεί νέο θέμα. Τα δεδομένα που παράγονται είναι ο τίτλος του θέματος και το περιεχόμενο του πρώτου μηνύματος. Μεταδεδομένα της δημιουργίας είναι η διεύθυνση του δημιουργού του θέματος. Για την αποθήκευση του θέματος στο σύστημα δημιουργείται πρώτα συναλλαγή στο blockchain ώστε να δημιουργηθεί μία νέα εγγραφή στον πίνακα των θεμάτων. Η εγγραφή αυτή δεν περιέχει τίποτα παρά μόνο τη διεύθυνση του δημιουργού χρήστη. Αν η συναλλαγή είναι επιτυχής, θα επιστραφεί ο αύξων αριθμός του νέου θέματος. Έπειτα, στην προσωπική βάση OrbitDB του χρήστη και στον πίνακα των θεμάτων θα προστεθεί εγγραφή με αναγνωριστικό τον αύξων αριθμό του θέματος όπου θα αποθηκευτούν τα δεδομένα του τίτλου και πρώτου μηνύματος. Στο σχήμα \ref{figure:4-3-data-flow-insert} παρουσιάζεται γραφικά η διαδικασία. \begin{figure}[H] \centering - \includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-insert.png} + \input{tikz/chapter-3/3-6-use-case-create-topic-sequence-diagram} \caption{Διάγραμμα ακολουθίας δημιουργίας θέματος} \label{figure:4-3-data-flow-insert} \end{figure} -Έστω, χρήστης που επιθυμεί να διαβάσει το προηγούμενο μήνυμα. Αρχικά, πρέπει να διαβαστεί ο πίνακας θεμάτων από το blockchain. Η πληροφορία αυτή εμπλουτίζεται από τα δεδομένα του κάθε θέματος, τα οποία ανακτώνται από τις προσωπικές βάσεις Orbit κάθε χρήστη. Έπειτα, εφόσον το θέμα βρεθεί και ο αύξων αριθμός του είναι γνωστός, πρέπει να διαβαστούν από το blockchain τα μεταδομένα των μηνυμάτων του θέματος και συγκεκριμένα η διευθύνσεις των δημιουργών τους. Τέλος, μέσω του IPFS πρέπει να γίνει αντιγραφή των προσωπικών βάσεων των δημιουργών του κάθε μηνύματος και να αναζητηθούν σε αυτές τα εκάστοτε μηνύματα. Στο σχήμα \ref{figure:4-3-data-flow-read} φαίνεται το διάγραμμα ροής της πληροφορίας κατά την ανάκτηση πληροφοριών από το σύστημα. +Έστω, χρήστης που επιθυμεί να διαβάσει το προηγούμενο θέμα. Αρχικά, πρέπει να διαβαστούν τα μεταδεδομένα του συγκεκριμένου θέματος από το blockchain. Έπειτα, διαβάζονται από το blockchain οι αύξοντες αριθμοί των μηνυμάτων που έχουν δημοσιευτεί στο θέμα αυτό. Σε μία τελευταία ανάκτηση από το blockchain διαβάζονται τα μεταδομένα του κάθε μηνύματος. Έπειτα, η πληροφορία αυτή εμπλουτίζεται από τα δεδομένα του θέματος και των μηνυμάτων, τα οποία ανακτώνται από τις προσωπικές βάσεις Orbit κάθε χρήστη. Στο σχήμα \ref{figure:4-3-data-flow-read} φαίνεται το διάγραμμα ροής της πληροφορίας κατά την ανάκτηση πληροφοριών από το σύστημα. \begin{figure}[H] \centering - \includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-read.png} + \input{tikz/chapter-3/3-6-use-case-fetch-topic-sequence-diagram} \caption{Διάγραμμα ακολουθίας εύρεσης και ανάκτησης θέματος} \label{figure:4-3-data-flow-read} -\end{figure} \ No newline at end of file +\end{figure} diff --git a/chapters/4.application-implementation/4.5.implemented-parts.tex b/chapters/4.application-implementation/4.5.implemented-parts.tex index fa88a7a..22c7298 100644 --- a/chapters/4.application-implementation/4.5.implemented-parts.tex +++ b/chapters/4.application-implementation/4.5.implemented-parts.tex @@ -2,7 +2,7 @@ Όπως αναλύθηκε στο προηγούμενο κεφάλαιο, κατά την υλοποίηση εμφανίστηκαν διάφορα προβλήματα που δεν είχαν προβλεφθεί και τα οποία προκάλεσαν καθυστερήσεις στην ολοκλήρωση των tasks. Λόγω των καθυστερήσεων αυτών έγιναν διάφορες αναδιαμορφώσεις του προγραμματισμού των Sprint καθώς και διαπραγματεύσεις της σημαντικότητας των χαρακτηριστικών. Από τον επανασχεδιασμό και τις προσαρμογές αυτές προέκυψαν μερικές αλλαγές στο τελικό σετ των χαρακτηριστικών της πλατφόρμας σε σχέση με ό,τι είχε αρχικά προδιαγραφεί. -Τα χαρακτηριστικά που τελικά υλοποιήθηκαν είναι: +Τα χαρακτηριστικά και οι αντίστοιχες Λειτουργικές Απαιτήσεις που τελικά υλοποιήθηκαν είναι: \begin{itemize} \item Η εγγραφή χρήστη και η δημιουργία των τοπικών βάσεων του, όπως περιγράφονται στις \ref{srs:functional-srs-sign-up} \& \ref{srs:functional-srs-create-user-databases} και στο σενάριο χρήσης \ref{subsection:3-6-use-case-signup}. @@ -18,26 +18,27 @@ Τα παραπάνω αντιστοιχούν σε 11 ολοκληρωμένες από τις 13 προδιαγεγραμμένες ΛΑ ή πλήρωση 84.6\%, ποσοστό που θεωρείται από τους συγγραφείς επαρκές για την εξαγωγή συμπερασμάτων για τον χώρο των DApps και υπερβάλλον για τα πλαίσια ενός PoC. Στο παράρτημα \ref{screenshots-appendix} παρατίθενται τα στιγμιότυπα οθόνης των υλοποιημένων χαρακτηριστικών. -Το χαρακτηριστικά το οποία παραλήφθηκε είναι η δημιουργία κοινοτήτων και ο ορισμός εξωτερικών contracts για τα tokens τους, όπως περιγράφονται στις \ref{srs:functional-srs-create-communities} \& \ref{srs:functional-srs-assign-community-contract} και στο σενάριο χρήσης \ref{subsection:3-10-use-case-create-community}. +Το χαρακτηριστικό το οποία παραλήφθηκε είναι η δημιουργία κοινοτήτων και ο ορισμός εξωτερικών contracts για τα tokens τους, όπως περιγράφονται στις \ref{srs:functional-srs-create-communities} \& \ref{srs:functional-srs-assign-community-contract} και στο σενάριο χρήσης \ref{subsection:3-10-use-case-create-community}. -Τέλος, η ΜΛΑ που αφορά την ελαχιστοποίηση των fees (\ref{srs:non-functional-srs-minimize-fees}) ακολουθήθηκε κατά το δυνατόν σε όλη τη διαδικασία σχεδιασμού και υλοποίησης. Η ΜΛΑ σχετικά με την αναβαθμισιμότητα των contracts (\ref{srs:non-functional-srs-upgrade-contracts}) καταστρατηγήθηκε λόγω του χρόνου που θα απαιτούσε μία τέτοια υλοποίηση. +Όσον αφορά στις Μη Λειτουργικές Απαιτήσεις, η \ref{srs:non-functional-srs-maximum-decentraliztion}, η οποία απαιτεί τη μεγιστοποίηση της αποκέντρωσης της πλατφόρμας, εκπληρώθηκε σε ικανοποιητικό βαθμό, παρότι φαινομενικά το σύστημα περιλαμβάνει σημεία κεντροποίησης για ορισμένες λειτουργίες του. Ενώ, δηλαδή, η διάθεση του frontend της εφαρμογής και των contract artifacts, καθώς και η διαδικασία ανακάλυψης των IPFS peers πραγματοποιούνται μέσω υπηρεσιών που εκτελούνται σε κεντρικούς εξυπηρετητές, στην πραγματικότητα είτε απλά παρέχουν σημαντικές διευκολύνσεις στο περιβάλλον ανάπτυξης, είτε αποτελούν προσωρινά εμπόδια που σχετίζονται με τους τρέχοντες περιορισμούς των υποκείμενων τεχνολογιών. Έτσι, από τη μία πλευρά ο κώδικας της εφαρμογής είναι εφικτό να διατίθεται στους χρήστες με αποκεντρωμένο τρόπο (π.χ. μέσω του ίδιου του IPFS), από την άλλη η παρούσα ανάγκη ύπαρξης των rendezvous server για το peer discovery μένει να επιλυθεί από την προγραμματιστική ομάδα του IPFS. -Η \ref{srs:non-functional-srs-maximum-decentraliztion} απαιτεί την μεγιστοποίηση της αποκέντρωσης της πλατφόρμας. Παρότι υπάρχουν μέρη τα οποία φαινομενικά έχει παραβιαστεί, όπως η διάθεση της εφαρμογής και των contract artifacts μέσω κεντροποιημένων servers καθώς και η ύπαρξη του rendezvous server, στην πραγματικότητα έχει ακολουθηθεί σε ικανοποιητικό βαθμό. Σχετικά με την εφαρμογή και τα contracts, πάρθηκε η απόφαση να διατεθούν μέσω των αντίστοιχων servers επειδή αυτό προσφέρει μεγάλη ευελιξία και ευκολία στην ανάπτυξη. Θα μπορούσαν εύκολα να διατεθούν μέσω αποκεντρωμένων συστημάτων όπως torrents ή το IPFS και αυτό παραμένει ένα ανοιχτό θέμα. Επίσης ανοιχτό θέμα παραμένει η ανάγκη ύπαρξης του rendezvous server. Λόγω της φύσης του πρωτοκόλλου IPFS και της λειτουργίας που επιτελεί ο server αυτός, είναι αδύνατον να παραληφθεί, ωστόσο είναι ανοιχτό ερευνητικό πεδίο η περαιτέρω αποκέντρωση του πρωτοκόλλου. -%TODO: https://mnot.github.io/avoiding-internet-centralization/draft-nottingham-avoiding-internet-centralization.html#name-necessary-centralization +Επίσης, η ΜΛΑ που αφορά στην ελαχιστοποίηση των fees (\ref{srs:non-functional-srs-minimize-fees}) ακολουθήθηκε κατά το δυνατόν σε ολόκληρες τις διαδικασίες του σχεδιασμού και της υλοποίησης. Αυτό επιτεύχθηκε τόσο με την αποθήκευση των απολύτως απαραίτητων δεδομένων επί του blockchain, όσο και με τη βελτιστοποίηση του κώδικα των smart contracts, ώστε να εκτελείται με τον μικρότερο δυνατό αριθμό υπολογιστικών κύκλων. -\subsection{Διαφορές σχεδιασμού-υλοποίησης} \label{subsection:4-6-1-design-implementation-differences} +Τέλος, η ΜΛΑ που σχετίζεται με την αναβαθμισιμότητα των contracts (\ref{srs:non-functional-srs-upgrade-contracts}) καταστρατηγήθηκε, λόγω του επιπρόσθετου χρόνου που θα απαιτούσε μία τέτοια υλοποίηση. Ωστόσο, υπάρχουν ήδη πλήρως λειτουργικές μέθοδοι για την επίτευξη αυτού του στόχου, με διαθέσιμα plugin\footnote{\url{https://docs.openzeppelin.com/upgrades-plugins/1.x/}} που μπορούν να ενσωματωθούν απευθείας στις υπάρχοντες ροές εργασίας. -Σημαντικές διαφορές υπήρξαν επίσης στην διαδικασία υλοποίησης τόσο όσον αφορά τον αριθμό και τις λειτουργίες των διαφορετικών πακέτων λογισμικού όσο και τον χρονοπρογραμματισμό. Προστέθηκαν τρεις νέες υπηρεσίες, η υπηρεσία "Concordia Contracts Provider", ο προσαρμοσμένος IPFS pinner και η ιστοσελίδα "Concordia Guide". +\subsection{Διαφορές σχεδιασμού-υλοποίησης} \label{subsection:4-5-1-design-implementation-differences} + +Σημαντικές διαφορές υπήρξαν επίσης στην διαδικασία υλοποίησης τόσο όσον αφορά στον αριθμό και στις λειτουργίες των διαφορετικών πακέτων λογισμικού όσο και τον χρονοπρογραμματισμό. Προστέθηκαν τρεις νέες υπηρεσίες, η υπηρεσία "Concordia Contracts Provider", ο προσαρμοσμένος IPFS pinner "Concordia Pinner" και η ιστοσελίδα "Concordia Guide". Η ανάγκη για τα νέα πακέτα λογισμικού προέκυψε κατά την πορεία υλοποίησης της διπλωματικής και προστέθηκαν στον χρονοπρογραμματισμό που είχε γίνει στην αρχή της εργασίας. Στην προσαρμογή αυτή βοήθησαν ιδιαίτερα οι Agile τακτικές που ακολουθήθηκαν και η προσαρμοστικότητα που προσφέρει το Scrum σε μεταβαλλόμενες απαιτήσεις. Τέλος, κατά την υλοποίηση έγινε γρήγορα αντιληπτή η αξία που προσφέρουν ένα δοκιμαστικό περιβάλλον (staging environment) σε συνδυασμό με ένα CI/CD σύστημα. Για το λόγο αυτό λήφθηκε η απόφαση να μεταφερθεί το sprint που αφορούσε αυτά πολύ νωρίτερα στην διαδικασία υλοποίησης, ώστε να μεγιστοποιηθεί η χρήση του. -Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα (σχήμα \ref{figure:4.6.design-implementation-differences-sprints}). Με σκούρο πράσινο χρώμα εμφανίζονται τα tasks τα οποία υπήρχαν στο χρονοπρογραμματισμό από τη αρχή και υλοποιήθηκαν, με ανοιχτό πράσινο αυτά τα οποία δεν υπήρχαν στον αρχικό προγραμματισμό αλλά υλοποιήθηκαν και με κόκκινο αυτά τα οποία δεν υλοποιήθηκαν. +Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα (σχήμα \ref{figure:4.5.design-implementation-differences-sprints}). Με σκούρο πράσινο χρώμα εμφανίζονται τα tasks τα οποία υπήρχαν στο χρονοπρογραμματισμό από τη αρχή και υλοποιήθηκαν, με ανοιχτό πράσινο αυτά τα οποία δεν υπήρχαν στον αρχικό προγραμματισμό αλλά υλοποιήθηκαν και με κόκκινο αυτά τα οποία δεν υλοποιήθηκαν. \begin{figure}[H] \centering \includegraphics[width=\textwidth]{assets/figures/chapter-4/4.6.design-implementation-differences-sprints.png} \caption{Διαχωρισμός σε sprints} - \label{figure:4.6.design-implementation-differences-sprints} + \label{figure:4.5.design-implementation-differences-sprints} \end{figure} diff --git a/misc/packages.tex b/misc/packages.tex index 1dfb418..5ee2b97 100644 --- a/misc/packages.tex +++ b/misc/packages.tex @@ -4,7 +4,7 @@ \usepackage[subpreambles=true]{standalone} % Paper size and margins -\usepackage{geometry} +\usepackage[a4paper, top=2.5cm, bottom=2.5cm, left=2.2cm, right=2.2cm]{geometry} % --- Languages & Fonts --- \usepackage{polyglossia} @@ -31,7 +31,15 @@ \usepackage{appendix} % Appendix helpers \usepackage[onehalfspacing]{setspace} -% --- TikZ and UML diagrams +% --- fancyhdr --- + +\usepackage{fancyhdr} +\pagestyle{fancy} +\fancyhead[L]{\nouppercase{\rightmark}} +\fancyhead[R]{\nouppercase{\leftmark}} +\setlength{\headheight}{15pt} + +% --- TikZ and UML diagrams --- \usepackage{pgf-umlsd} % --- Bibliography --- diff --git a/thesis.pdf b/thesis.pdf index a53502e..cdab72e 100644 Binary files a/thesis.pdf and b/thesis.pdf differ diff --git a/thesis.tex b/thesis.tex index 5960d31..3790b29 100644 --- a/thesis.tex +++ b/thesis.tex @@ -6,9 +6,6 @@ % Sets up the bib files \input{bibliography/bib-setup} -% Paper size and margins -\geometry{a4paper, top=2.5cm, bottom=2.5cm, left=2.2cm, right=2.2cm} - % Make title page \input{misc/title-page}