\section{Υλοποιημένα χαρακτηριστικά} \label{section:4-5-implemented-parts}

Όπως αναλύθηκε στην προηγούμενη ενότητα, κατά την υλοποίηση εμφανίστηκαν διάφορα προβλήματα που δεν είχαν προβλεφθεί και τα οποία προκάλεσαν καθυστερήσεις στην ολοκλήρωση των task. Εξαιτίας αυτών των καθυστερήσεων έγιναν διάφορες αναδιαμορφώσεις του προγραμματισμού των Sprint, καθώς και διαπραγματεύσεις ως προς τη σημαντικότητα των χαρακτηριστικών. Από τον επανασχεδιασμό και τις προσαρμογές προέκυψαν μερικές αλλαγές στο τελικό σετ των χαρακτηριστικών της πλατφόρμας σε σχέση με ό,τι είχε αρχικά προδιαγραφεί.

Τα χαρακτηριστικά και οι αντίστοιχες Λειτουργικές Απαιτήσεις που τελικά υλοποιήθηκαν είναι τα εξής:

\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-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-browse-community-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-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-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}.
\end{itemize}

Τα παραπάνω αντιστοιχούν σε 11 ολοκληρωμένες από τις 13 προδιαγεγραμμένες ΛΑ ή πλήρωση 84.6\%, ποσοστό που θεωρείται από τους συγγραφείς επαρκές για την εξαγωγή συμπερασμάτων για τον χώρο των DApp και υπερβάλλον για τα πλαίσια ενός PoC. Στο \hyperref[{appendix-a}]{παράρτημα Αʹ} περιλαμβάνονται στιγμιότυπα οθόνης τα οποία αντιστοιχίζονται με τις ΛΑ των υλοποιημένων χαρακτηριστικών.

Τα χαρακτηριστικά τα οποία παραλήφθηκαν είναι η δημιουργία κοινοτήτων και ο ορισμός εξωτερικών contract για τα token τους, όπως περιγράφονται στις \ref{srs:functional-srs-create-communities} \& \ref{srs:functional-srs-assign-community-contract}, καθώς και στο σενάριο χρήσης \ref{subsection:3-10-use-case-create-community}.

Όσον αφορά στις Μη Λειτουργικές Απαιτήσεις, η \ref{srs:non-functional-srs-maximum-decentraliztion}, η οποία απαιτεί τη μεγιστοποίηση της αποκέντρωσης της πλατφόρμας, εκπληρώθηκε σε ικανοποιητικό βαθμό, παρότι φαινομενικά το σύστημα περιλαμβάνει σημεία κεντροποίησης για ορισμένες λειτουργίες του. Ενώ, δηλαδή, η διάθεση του frontend της εφαρμογής και των contract artifact, καθώς και η διαδικασία ανακάλυψης των IPFS peer πραγματοποιούνται μέσω υπηρεσιών που εκτελούνται σε κεντρικούς εξυπηρετητές, στην πραγματικότητα είτε απλά παρέχουν σημαντικές διευκολύνσεις στο περιβάλλον ανάπτυξης, είτε αποτελούν προσωρινά εμπόδια που σχετίζονται με τους τρέχοντες περιορισμούς των υποκείμενων τεχνολογιών. Έτσι, από τη μία πλευρά ο κώδικας της εφαρμογής είναι εφικτό να διατίθεται στους χρήστες με αποκεντρωμένο τρόπο (π.χ. μέσω του ίδιου του IPFS), από την άλλη η παρούσα ανάγκη ύπαρξης των rendezvous server για το peer discovery μένει να επιλυθεί από την προγραμματιστική ομάδα του IPFS.

Επίσης, η ΜΛΑ που αφορά στην ελαχιστοποίηση των fee (\ref{srs:non-functional-srs-minimize-fees}) ακολουθήθηκε κατά το δυνατόν σε ολόκληρες τις διαδικασίες του σχεδιασμού και της υλοποίησης. Αυτό επιτεύχθηκε τόσο με την αποθήκευση των απολύτως απαραίτητων δεδομένων επί του blockchain, όσο και με τη βελτιστοποίηση του κώδικα των smart contract, ώστε να εκτελείται με τον μικρότερο δυνατό αριθμό υπολογιστικών κύκλων.

Τέλος, η ΜΛΑ που σχετίζεται με την αναβαθμισιμότητα των contract (\ref{srs:non-functional-srs-upgrade-contracts}) καταστρατηγήθηκε, λόγω του επιπρόσθετου χρόνου που θα απαιτούσε μία τέτοια υλοποίηση. Ωστόσο, υπάρχουν ήδη πλήρως λειτουργικές μέθοδοι για την επίτευξη αυτού του στόχου, με διαθέσιμα plugin\footnote{\url{https://docs.openzeppelin.com/upgrades-plugins/1.x/}} που μπορούν να ενσωματωθούν απευθείας στις υπάρχουσες ροές εργασίας.

\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 που αφορούσε σε αυτά πολύ νωρίτερα στη διαδικασία υλοποίησης, ώστε να αξιοποιηθεί η χρήση του στο μέγιστο.

\newpage
Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα (σχήμα \ref{figure:4.5.design-implementation-differences-sprints}). Με σκούρο πράσινο χρώμα εμφανίζονται τα task τα οποία υπήρχαν στον χρονοπρογραμματισμό από την αρχή και υλοποιήθηκαν, με ανοιχτό πράσινο αυτά τα οποία δεν υπήρχαν στον αρχικό προγραμματισμό αλλά εισήχθησαν και υλοποιήθηκαν και, τέλος, με κόκκινο εκείνα τα οποία παραλήφθηκαν.

\vspace{\baselineskip}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{assets/figures/chapter-4/4.6.design-implementation-differences-sprints}
    \caption{Διαχωρισμός σε Sprint (στάδιο υλοποίησης)}
    \label{figure:4.5.design-implementation-differences-sprints}
\end{figure}