Browse Source

Merge remote-tracking branch 'origin/refactor/move-implemented-parts-chapter-last' into feature/4-6-design-implementation-differences

develop
Apostolos Fanakis 3 years ago
parent
commit
b15bbae61b
Signed by: Apostolof GPG Key ID: 8600B4C4163B3269
  1. 0
      assets/figures/chapter-4/4.1.implementation-methodology-jenkins-pipeline.png
  2. 0
      assets/figures/chapter-4/4.1.implementation-methodology-kanban.png
  3. 0
      assets/figures/chapter-4/4.2.docker-logo.png
  4. 0
      assets/figures/chapter-4/4.2.ganache-gui.png
  5. 0
      assets/figures/chapter-4/4.2.ganache-logo.png
  6. 0
      assets/figures/chapter-4/4.2.jenkins-logo.png
  7. 0
      assets/figures/chapter-4/4.2.js-ipfs-logo.png
  8. 0
      assets/figures/chapter-4/4.2.libp2p-logo.png
  9. 0
      assets/figures/chapter-4/4.2.node.js-logo.png
  10. 0
      assets/figures/chapter-4/4.2.orbitdb-logo.png
  11. 0
      assets/figures/chapter-4/4.2.react-logo.png
  12. 0
      assets/figures/chapter-4/4.2.react-redux.png
  13. 0
      assets/figures/chapter-4/4.2.redux-logo.png
  14. 0
      assets/figures/chapter-4/4.2.redux-saga-logo.png
  15. 0
      assets/figures/chapter-4/4.2.truffle-logo.png
  16. 0
      assets/figures/chapter-4/4.3.architecture-4.3.2.concordia-application-architecture.png
  17. 0
      assets/figures/chapter-4/4.3.architecture-4.3.3.concordia-contracts-migrator-architecture.png
  18. 0
      assets/figures/chapter-4/4.3.architecture-4.3.4.concordia-pinner-architecture.png
  19. 0
      assets/figures/chapter-4/4.3.architecture-4.3.5.concordia-contracts-provider-architecture.png
  20. 0
      assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-insert.png
  21. 0
      assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-read.png
  22. 0
      assets/figures/chapter-4/4.3.architecture-architecture-overview.png
  23. 0
      assets/figures/chapter-4/4.3.communications-diagram.png
  24. 8
      bibliography/references.bib
  25. 11
      chapters/4.application-implementation/4.0.application-implementation.tex
  26. 14
      chapters/4.application-implementation/4.1.implementation-methodology.tex
  27. 6
      chapters/4.application-implementation/4.1.implemented-parts.tex
  28. 10
      chapters/4.application-implementation/4.2.implementation-technology-stack.tex
  29. 9
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies.tex
  30. 6
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.1.node.js.tex
  31. 4
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.2.docker.tex
  32. 4
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.3.jenkins.tex
  33. 9
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies.tex
  34. 4
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.1.react.tex
  35. 6
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.2.redux.tex
  36. 4
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.3.redux-saga.tex
  37. 6
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies.tex
  38. 4
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.1.truffle.tex
  39. 6
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.2.ganache.tex
  40. 7
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies.tex
  41. 4
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.1.js-ipfs.tex
  42. 8
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.2.orbit-db.tex
  43. 4
      chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.3.libp2p.tex
  44. 78
      chapters/4.application-implementation/4.3.implementation-architecture.tex
  45. 9
      chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.1.development-technologies.tex
  46. 9
      chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.2.ui-technologies.tex
  47. 7
      chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.4.ipfs-technologies.tex
  48. 0
      chapters/4.application-implementation/4.4.problems-faced.tex
  49. 9
      chapters/4.application-implementation/4.5.implemented-parts.tex
  50. BIN
      thesis.pdf

0
assets/figures/chapter-4/4-2-implementation-methodology-jenkins-pipeline.png → assets/figures/chapter-4/4.1.implementation-methodology-jenkins-pipeline.png

Before

Width:  |  Height:  |  Size: 702 KiB

After

Width:  |  Height:  |  Size: 702 KiB

0
assets/figures/chapter-4/4.2.implementation-methodology-kanban.png → assets/figures/chapter-4/4.1.implementation-methodology-kanban.png

Before

Width:  |  Height:  |  Size: 168 KiB

After

Width:  |  Height:  |  Size: 168 KiB

0
assets/figures/chapter-4/4.3.docker-logo.png → assets/figures/chapter-4/4.2.docker-logo.png

Before

Width:  |  Height:  |  Size: 37 KiB

After

Width:  |  Height:  |  Size: 37 KiB

0
assets/figures/chapter-4/4.3.ganache-gui.png → assets/figures/chapter-4/4.2.ganache-gui.png

Before

Width:  |  Height:  |  Size: 97 KiB

After

Width:  |  Height:  |  Size: 97 KiB

0
assets/figures/chapter-4/4.3.ganache-logo.png → assets/figures/chapter-4/4.2.ganache-logo.png

Before

Width:  |  Height:  |  Size: 62 KiB

After

Width:  |  Height:  |  Size: 62 KiB

0
assets/figures/chapter-4/4.3.jenkins-logo.png → assets/figures/chapter-4/4.2.jenkins-logo.png

Before

Width:  |  Height:  |  Size: 122 KiB

After

Width:  |  Height:  |  Size: 122 KiB

0
assets/figures/chapter-4/4.3.js-ipfs-logo.png → assets/figures/chapter-4/4.2.js-ipfs-logo.png

Before

Width:  |  Height:  |  Size: 689 KiB

After

Width:  |  Height:  |  Size: 689 KiB

0
assets/figures/chapter-4/4.3.libp2p-logo.png → assets/figures/chapter-4/4.2.libp2p-logo.png

Before

Width:  |  Height:  |  Size: 49 KiB

After

Width:  |  Height:  |  Size: 49 KiB

0
assets/figures/chapter-4/4.3.node.js-logo.png → assets/figures/chapter-4/4.2.node.js-logo.png

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 20 KiB

0
assets/figures/chapter-4/4.3.orbitdb-logo.png → assets/figures/chapter-4/4.2.orbitdb-logo.png

Before

Width:  |  Height:  |  Size: 112 KiB

After

Width:  |  Height:  |  Size: 112 KiB

0
assets/figures/chapter-4/4.3.react-logo.png → assets/figures/chapter-4/4.2.react-logo.png

Before

Width:  |  Height:  |  Size: 57 KiB

After

Width:  |  Height:  |  Size: 57 KiB

0
assets/figures/chapter-4/4.3.react-redux.png → assets/figures/chapter-4/4.2.react-redux.png

Before

Width:  |  Height:  |  Size: 2.4 MiB

After

Width:  |  Height:  |  Size: 2.4 MiB

0
assets/figures/chapter-4/4.3.redux-logo.png → assets/figures/chapter-4/4.2.redux-logo.png

Before

Width:  |  Height:  |  Size: 46 KiB

After

Width:  |  Height:  |  Size: 46 KiB

0
assets/figures/chapter-4/4.3.redux-saga-logo.png → assets/figures/chapter-4/4.2.redux-saga-logo.png

Before

Width:  |  Height:  |  Size: 25 KiB

After

Width:  |  Height:  |  Size: 25 KiB

0
assets/figures/chapter-4/4.3.truffle-logo.png → assets/figures/chapter-4/4.2.truffle-logo.png

Before

Width:  |  Height:  |  Size: 112 KiB

After

Width:  |  Height:  |  Size: 112 KiB

0
assets/figures/chapter-4/4.4.architecture-4.4.2.concordia-application-architecture.png → assets/figures/chapter-4/4.3.architecture-4.3.2.concordia-application-architecture.png

Before

Width:  |  Height:  |  Size: 103 KiB

After

Width:  |  Height:  |  Size: 103 KiB

0
assets/figures/chapter-4/4.4.architecture-4.4.3.concordia-contracts-migrator-architecture.png → assets/figures/chapter-4/4.3.architecture-4.3.3.concordia-contracts-migrator-architecture.png

Before

Width:  |  Height:  |  Size: 47 KiB

After

Width:  |  Height:  |  Size: 47 KiB

0
assets/figures/chapter-4/4.4.architecture-4.4.4.concordia-pinner-architecture.png → assets/figures/chapter-4/4.3.architecture-4.3.4.concordia-pinner-architecture.png

Before

Width:  |  Height:  |  Size: 62 KiB

After

Width:  |  Height:  |  Size: 62 KiB

0
assets/figures/chapter-4/4.4.architecture-4.4.5.concordia-contracts-provider-architecture.png → assets/figures/chapter-4/4.3.architecture-4.3.5.concordia-contracts-provider-architecture.png

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 31 KiB

0
assets/figures/chapter-4/4.4.architecture-4.4.9.data-flow-insert.png → assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-insert.png

Before

Width:  |  Height:  |  Size: 72 KiB

After

Width:  |  Height:  |  Size: 72 KiB

0
assets/figures/chapter-4/4.4.architecture-4.4.9.data-flow-read.png → assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-read.png

Before

Width:  |  Height:  |  Size: 99 KiB

After

Width:  |  Height:  |  Size: 99 KiB

0
assets/figures/chapter-4/4.4.architecture-architecture-overview.png → assets/figures/chapter-4/4.3.architecture-architecture-overview.png

Before

Width:  |  Height:  |  Size: 186 KiB

After

Width:  |  Height:  |  Size: 186 KiB

0
assets/figures/chapter-4/4.4.communications-diagram.png → assets/figures/chapter-4/4.3.communications-diagram.png

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 15 KiB

8
bibliography/references.bib

@ -100,21 +100,21 @@
author = {ProtoSchool},
url = {https://proto.school/merkle-dags/}
}
@online{4.2-github-flow,
@online{4.1-github-flow,
title = {Understanding the GitHub flow},
author = {GitHub Guides},
url = {https://guides.github.com/introduction/flow/}
}
@misc{4.3-node.js,
@misc{4.2-node.js,
title = {Node.js},
author = {Wikipedia},
url = {https://en.wikipedia.org/wiki/Node.js}
}
@misc{4.3-orbitdb,
@misc{4.2-orbitdb,
title = {OrbitDB},
url = {https://orbitdb.org}
}
@misc{4.3-orbitdb-guide,
@misc{4.2-orbitdb-guide,
title = {Getting Started with OrbitDB},
url = {https://github.com/orbitdb/orbit-db/blob/main/GUIDE.md}
}

11
chapters/4.application-implementation/4.0.application-implementation.tex

@ -1,8 +1,7 @@
\chapter{Υλοποίηση εφαρμογής}\label{chapter:4-application-implementation}
\input{chapters/4.application-implementation/4.1.implemented-parts}
\input{chapters/4.application-implementation/4.2.implementation-methodology}
\input{chapters/4.application-implementation/4.3.implementation-technology-stack}
\input{chapters/4.application-implementation/4.4.implementation-architecture}
\input{chapters/4.application-implementation/4.5.problems-faced}
\input{chapters/4.application-implementation/4.6.design-implementation-differences}
\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}
\input{chapters/4.application-implementation/4.4.problems-faced}
\input{chapters/4.application-implementation/4.5.implemented-parts}

14
chapters/4.application-implementation/4.2.implementation-methodology.tex → chapters/4.application-implementation/4.1.implementation-methodology.tex

@ -1,4 +1,4 @@
\section{Μεθοδολογία υλοποίησης} \label{subsection:4-2-implementation-methodology}
\section{Μεθοδολογία υλοποίησης} \label{subsection:4-1-implementation-methodology}
Για την επίτευξη των στόχων που ορίστηκαν και την οργάνωση της εργασίας που απαιτείται σε διαχειρίσιμα μέρη, σχεδιάστηκε η χρήση διάφορων εργαλείων και μεθόδων ανάπτυξης λογισμικού, όπως το σύστημα ελέγχου εκδόσεων (version control system) Git, η μέθοδος οργάνωσης Scrum και οι διαδικασίες ανάπτυξης DevOps. Τα εργαλεία αυτά είναι δοκιμασμένα και έχουν εδραιωθεί στη σύγχρονη ανάπτυξη λογισμικού.
@ -6,7 +6,7 @@
Το Git είναι δωρεάν λογισμικό ανοιχτού κώδικα το οποίο επιτρέπει και επικουρεί την απρόσκοπτη ανάπτυξη λογισμικού από πολλαπλά μέλη μίας ομάδας, ταυτόχρονα και διανεμημένα. Αυτό επιτυγχάνεται παρέχοντας ένα πλαίσιο από εργαλεία τα οποία βοηθούν την διαχείριση και ενσωμάτωση των διαφορετικών εκδόσεων του κώδικα τις οποίες αναπτύσσει κάθε μέλος της ομάδας ξεχωριστά. Υπάρχουν διάφορα μοντέλα χρήσης του Git και πιο συγκεκριμένα της δυνατότητας που δίνει για δημιουργία, ανάπτυξη και ένωση (merge) κλαδιών (branches).
Για τους σκοπούς της παρούσας διπλωματικής χρησιμοποιήθηκε το μοντέλο GitHub flow\cite{4.2-github-flow}. Το μοντέλο αυτό ορίζει ότι κάθε προγραμματιστής ανοίγει ένα νέο branch για τη ανάπτυξη ενός χαρακτηριστικού της εφαρμογής ή τη διόρθωση ενός μέρους του κώδικα. Έπειτα, όταν η δουλειά έχει ολοκληρωθεί, δημιουργείται ένα αίτημα ένωσης (pull request) με το βασικό κλαδί ανάπτυξης (develop) της εφαρμογής. Η δουλειά υπόκειται σε αξιολόγηση από την υπόλοιπη ομάδα (review) και όταν κριθεί ότι ικανοποιεί τις ανάγκες του έργου, το branch γίνεται merge με το develop. Όταν το develop φτάσει σε ικανό σημείο σταθερότητας και αλλαγών, γίνεται merge με το branch παραγωγής (master). Από το master δημιουργούνται οι τελικές εκδόσεις της εφαρμογής οι οποίες διανέμονται για χρήση στην παραγωγή (production versions), ενώ από το develop δημιουργούνται οι δοκιμαστικές εκδόσεις αιχμής της εφαρμογής οι οποίες χρησιμοποιούνται κατά τον έλεγχο (staging versions).
Για τους σκοπούς της παρούσας διπλωματικής χρησιμοποιήθηκε το μοντέλο GitHub flow\cite{4.1-github-flow}. Το μοντέλο αυτό ορίζει ότι κάθε προγραμματιστής ανοίγει ένα νέο branch για τη ανάπτυξη ενός χαρακτηριστικού της εφαρμογής ή τη διόρθωση ενός μέρους του κώδικα. Έπειτα, όταν η δουλειά έχει ολοκληρωθεί, δημιουργείται ένα αίτημα ένωσης (pull request) με το βασικό κλαδί ανάπτυξης (develop) της εφαρμογής. Η δουλειά υπόκειται σε αξιολόγηση από την υπόλοιπη ομάδα (review) και όταν κριθεί ότι ικανοποιεί τις ανάγκες του έργου, το branch γίνεται merge με το develop. Όταν το develop φτάσει σε ικανό σημείο σταθερότητας και αλλαγών, γίνεται merge με το branch παραγωγής (master). Από το master δημιουργούνται οι τελικές εκδόσεις της εφαρμογής οι οποίες διανέμονται για χρήση στην παραγωγή (production versions), ενώ από το develop δημιουργούνται οι δοκιμαστικές εκδόσεις αιχμής της εφαρμογής οι οποίες χρησιμοποιούνται κατά τον έλεγχο (staging versions).
Το Scrum είναι μία μέθοδος οργάνωσης στην οποία ο επιμελητής του Scrum (Scrum master) διαχωρίζει τα ανεξάρτητα μέρη εργασίας (tasks) που πρέπει να υλοποιηθούν για την ολοκλήρωση των στόχων ενός project. Τα μέρη αυτά περιγράφονται αναλυτικά μαζί με τις απαιτήσεις τους και κατατίθενται σε μία λίστα εργασιών (backlog). Έπειτα, μέσα από συσκέψεις (meetings), επιλέγεται ένας αριθμός από tasks τα οποία ορίζουν το επόμενο προγραμματιστικό κύκλο (sprint). Κάθε task ανατίθεται σε κάποιο μέλος για υλοποίηση. Για το Sprint ορίζεται μία χρονική διάρκεια, στόχος της οποίας είναι η περάτωση όλων των tasks πριν τη λήξη της. Στο τέλος της προθεσμίας που ορίστηκε για το Sprint τα μέλη της ομάδας αποτιμούν τα αποτελέσματα και ορίζουν το επόμενο Sprint. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί.
@ -24,9 +24,9 @@
\begin{figure}[H]
\centering
\includegraphics[width=.8\textwidth]{assets/figures/chapter-4/4.2.implementation-methodology-kanban.png}
\includegraphics[width=.8\textwidth]{assets/figures/chapter-4/4.1.implementation-methodology-kanban.png}
\caption{Στιγμιότυπο οθόνης της διαδικτυακής υπηρεσίας Trello που χρησιμοποιήθηκε για την υλοποίηση του Scrum}
\label{figure:4.2.implementation-methodology-kanban}
\label{figure:4.1.implementation-methodology-kanban}
\end{figure}
Κατά την διαδικασία της ανάπτυξης του κώδικα, εφαρμόστηκαν επίσης οι τακτικές που ορίζονται από το DevOps σε ό,τι αφορά το deployment των υπηρεσιών. Το DevOps ορίζει διάφορα εργαλεία που αποσκοπούν στην απρόσκοπτη, αυτοματοποιημένη και γρήγορα ενσωμάτωση του κώδικα από το στάδιο της συγγραφής μέχρι την ολοκλήρωση και εγκατάσταση. Τα εργαλεία που χρησιμοποιήθηκαν εδώ είναι:
@ -40,7 +40,7 @@
Για την υλοποίηση των τακτικών αυτών επιλέχθηκε μετά από εκτενή έρευνα η πλατφόρμα Jenkins. Το Jenkins συνδυάστηκε με την πλατφόρμα εικονοποίησης Docker ώστε να ακολουθηθούν οι τελευταίες ενδεδειγμένες πρακτικές της βιομηχανίας. Έγινε συγγραφή του αρχείου Jenkinsfile το οποίο περιγράφει με κώδικα την ροή εργασιών (pipeline) που πρέπει να ακολουθηθεί μετά από κάθε αλλαγή στον κώδικα. Η εκτέλεση του pipeline πραγματοποιείται αυτόματα από το Jenkins.
Το pipeline αποτελείται από στάδια και βήματα τα οποία φαίνονται στο σχήμα \ref{figure:4.2.implementation-methodology-jenkins-pipeline}:
Το pipeline αποτελείται από στάδια και βήματα τα οποία φαίνονται στο σχήμα \ref{figure:4.1.implementation-methodology-jenkins-pipeline}:
\begin{enumerate}
\item Αρχικά εκτελείται το βήμα "Version", το οποίο συλλέγει στοιχεία σχετικά με την εκτέλεση του pipeline όπως το κλαδί του κώδικα που πυροδότησε τη ροή και ποια από τα πακέτα λογισμικού που περιλαμβάνονται στο git repository περιέχουν αλλαγές.
@ -52,9 +52,9 @@
\begin{figure}[H]
\centering
\includegraphics[width=.8\textwidth]{assets/figures/chapter-4/4-2-implementation-methodology-jenkins-pipeline.png}
\includegraphics[width=.8\textwidth]{assets/figures/chapter-4/4.1.implementation-methodology-jenkins-pipeline.png}
\caption{Διάγραμμα ροής εργασιών Jenkins}
\label{figure:4.2.implementation-methodology-jenkins-pipeline}
\label{figure:4.1.implementation-methodology-jenkins-pipeline}
\end{figure}
Με την χρήση του Jenkins αυτοματοποιείται με μεγάλη ευκολία ένα σημαντικό μέρος των διαδικασιών ανάπτυξης και δημοσίευσης του κώδικα. Με την χρήση του συγκεκριμένου pipeline γίνεται σίγουρο ό,τι σε κάθε αλλαγή, ασχέτως του κλαδιού ανάπτυξης ο κώδικας ελέγχεται και τα αποτελέσματα των tests είναι αποθηκευμένα και διαθέσιμα για ανάλυση. Ακόμα, για το κλαδί develop, αυτοματοποιείται η ολοκλήρωση των πακέτων και η εγκατάστασή τους σε περιβάλλον δοκιμής (staging), γεγονός που διευκολύνει σημαντικά τις συλλογικές δοκιμές από την ομάδα σε διαφορετικά περιβάλλοντα χρήσης (browsers). Τέλος, για το κλαδί master, αυτοματοποιείται η διαδικασία δημοσίευσης των docker images, μηδενίζοντας έτσι τον χρόνο που πρέπει να καταβάλουν τα μέλη της ομάδας σε αυτό.

6
chapters/4.application-implementation/4.1.implemented-parts.tex

@ -1,6 +0,0 @@
\section{Χαρακτηριστικά που υλοποιήθηκαν}
TODO: move to last, add diagram with colors
TODO: add references to use cases implemented with screenshots of application
TODO: add unimplemented parts like serve (front and contracts) thru IPFS, upgradability
TODO: add differences in architecture

10
chapters/4.application-implementation/4.3.implementation-technology-stack.tex → chapters/4.application-implementation/4.2.implementation-technology-stack.tex

@ -1,8 +1,8 @@
\section{Τεχνολογίες υλοποίησης} \label{subsection:4-3-implementation-technology-stack}
\section{Τεχνολογίες υλοποίησης} \label{subsection:4-2-implementation-technology-stack}
Η παρούσα ενότητα απαρτίζεται από υποενότητες, στις οποίες διατυπώνονται οι \textbf{σημαντικότερες} τεχνολογίες που χρησιμοποιήθηκαν για την υλοποίηση της εφαρμογής. Όλες οι τεχνολογίες αποτελούν δωρεάν λογισμικό ανοιχτού κώδικα.
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.1.development-technologies}
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.2.ui-technologies}
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.3.ethereum-technologies}
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.4.ipfs-technologies}
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies}
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies}
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies}
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies}

9
chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies.tex

@ -0,0 +1,9 @@
\subsection{Τεχνολογίες σχετικές με το development}
Σε αυτήν την υποενότητα περιγράφονται ορισμένα θεμελιώδη εργαλεία και frameworks που συνετέλεσαν στην ανάπτυξη της εφαρμογής.
%TODO: Add janus and build steps diagram
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.1.node.js}
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.2.docker}
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.3.jenkins}

6
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.1.development-technologies/4.3.1.1.node.js.tex → chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.1.node.js.tex

@ -1,8 +1,8 @@
\subsubsection{Node.js} \label{subsection:4-3-1-1-node.js}
\subsubsection{Node.js} \label{subsection:4-2-1-1-node.js}
\logo{chapter-4/4.3.node.js-logo}{Node.js logo}
\logo{chapter-4/4.2.node.js-logo}{Node.js logo}
Το Node.js\footnote{\url{https://nodejs.org/}} είναι ένα περιβάλλον χρόνου εκτέλεσης Javascript πολλαπλών πλατφορμών, το οποίο εκτελείται στη μηχανή V8\footnote{\url{https://v8.dev/}} και παρέχει τη δυνατότητα εκτέλεσης κώδικα Javascript εκτός περιηγητών ιστού. Επιτρέπει στους προγραμματιστές να χρησιμοποιούν Javascript για τη σύνταξη εργαλείων γραμμής εντολών και τη δημιουργία κλιμακωτών διαδικτυακών εφαρμογών (κυρίως για εξυπηρετητές). Έχει αρχιτεκτονική βασισμένη σε συμβάντα (event-driven architecture), με δυνατότητα ασύγχρονης εισόδου/εξόδου (asynchronous I/O).\cite{4.3-node.js}
Το Node.js\footnote{\url{https://nodejs.org/}} είναι ένα περιβάλλον χρόνου εκτέλεσης Javascript πολλαπλών πλατφορμών, το οποίο εκτελείται στη μηχανή V8\footnote{\url{https://v8.dev/}} και παρέχει τη δυνατότητα εκτέλεσης κώδικα Javascript εκτός περιηγητών ιστού. Επιτρέπει στους προγραμματιστές να χρησιμοποιούν Javascript για τη σύνταξη εργαλείων γραμμής εντολών και τη δημιουργία κλιμακωτών διαδικτυακών εφαρμογών (κυρίως για εξυπηρετητές). Έχει αρχιτεκτονική βασισμένη σε συμβάντα (event-driven architecture), με δυνατότητα ασύγχρονης εισόδου/εξόδου (asynchronous I/O).\cite{4.2-node.js}
Ένα από τα σημαντικότερα χαρακτηριστικά του Node.js είναι ο ενσωματωμένος διαχειριστής πακέτων του, ο οποίος ονομάζεται npm. Με τον npm γίνεται εφικτή η εγκατάσταση πακέτων (βιβλιοθηκών) από το μητρώο npm (npm registry\footnote{\url{https://www.npmjs.com/}}), καθώς και η οργάνωση και η διαχείρισή τους στα πλαίσια της ανάπτυξης μίας εφαρμογής που εξαρτάται από αυτά.

4
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.1.development-technologies/4.3.1.2.docker.tex → chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.2.docker.tex

@ -1,6 +1,6 @@
\subsubsection{Docker} \label{subsection:4-3-1-2-docker}
\subsubsection{Docker} \label{subsection:4-2-1-2-docker}
\logo{chapter-4/4.3.docker-logo}{Docker logo}
\logo{chapter-4/4.2.docker-logo}{Docker logo}
Το Docker αποτελεί μία πλατφόρμα η οποία παρέχει λογισμικό εικονοποίησης (virtualization) στο επίπεδο του λειτουργικού συστήματος καθώς και ολοκληρωμένα συστήματα διαμοιρασμού και εκτέλεσης των παραγόμενων εικόνων.

4
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.1.development-technologies/4.3.1.3.jenkins.tex → chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.1.development-technologies/4.2.1.3.jenkins.tex

@ -1,6 +1,6 @@
\subsubsection{Jenkins} \label{subsection:4-3-1-3-jenkins}
\subsubsection{Jenkins} \label{subsection:4-2-1-3-jenkins}
\logo{chapter-4/4.3.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) που υπάρχουν ώστε να παρέχει τις δυνατότητες αυτές για οποιαδήποτε πλατφόρμα, γλώσσα και περιβάλλον ανάπτυξης.

9
chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies.tex

@ -0,0 +1,9 @@
\subsection{Τεχνολογίες σχετικές με το UI}
Στην παρούσα υποενότητα περιγράφονται όσες τεχνολογίες σχετίζονται με τη διεπαφή του χρήστη (UI), δηλαδή με το Presentation tier.
% TODO: add technologies like redux, sagas
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.1.react}
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.2.redux}
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.3.redux-saga}

4
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.2.ui-technologies/4.3.2.1.react.tex → chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.1.react.tex

@ -1,6 +1,6 @@
\subsubsection{React} \label{subsection:4-3-2-1-react}
\subsubsection{React} \label{subsection:4-2-2-1-react}
\logo{chapter-4/4.3.react-logo}{React logo}
\logo{chapter-4/4.2.react-logo}{React logo}
Η React\footnote{\url{https://reactjs.org/}} αποτελεί βιβλιοθήκη Javascript, η οποία χρησιμοποιείται για την κατασκευή διεπαφών χρήστη. Είναι δηλωτική (declarative) και βασίζεται σε components, τα οποία διαχειρίζονται την κατάστασή τους (state) και συντίθενται για να δημιουργήσουν πολύπλοκα διαδραστικά UIs.

6
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.2.ui-technologies/4.3.2.2.redux.tex → chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.2.redux.tex

@ -1,6 +1,6 @@
\subsubsection{Redux} \label{subsection:4-3-2-1-redux}
\subsubsection{Redux} \label{subsection:4-2-2-1-redux}
\logo{chapter-4/4.3.redux-logo}{Redux logo}
\logo{chapter-4/4.2.redux-logo}{Redux logo}
Το Redux\footnote{\url{https://redux.js.org/}} αποτελεί μία βιβλιοθήκη Javascript, η χρήση της οποίας προσφέρει στην εφαρμογή ένα πλήρως διαχειρίσιμο global state.
@ -20,7 +20,7 @@
%TODO: Add proper diagram
\begin{figure}[H]
\centering
\includegraphics[width=.75\textwidth]{assets/figures/chapter-4/4.3.react-redux}
\includegraphics[width=.75\textwidth]{assets/figures/chapter-4/4.2.react-redux}
\caption{Λειτουργία του Redux σε συνδυασμό με React}
\end{figure}

4
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.2.ui-technologies/4.3.2.3.redux-saga.tex → chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.2.ui-technologies/4.2.2.3.redux-saga.tex

@ -1,6 +1,6 @@
\subsubsection{Redux-Saga} \label{subsection:4-3-2-3-redux-saga}
\subsubsection{Redux-Saga} \label{subsection:4-2-2-3-redux-saga}
\logo{chapter-4/4.3.redux-saga-logo}{Redux-Saga logo}
\logo{chapter-4/4.2.redux-saga-logo}{Redux-Saga logo}
Το Redux-Saga\footnote{\url{https://redux.js.org/}} αποτελεί μία βιβλιοθήκη Javascript του οικοσυστήματος του Redux. Πρόκειται για ένα Redux middleware, το οποίο χρησιμοποιεί ESG generator functions\footnote{\url{https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*}} για την εκτέλεση και διαχείριση ποικίλων ασύγχρονων side effect. Αυτές οι συναρτήσεις (sagas) παρέχουν μία πληθώρα επιλογών για την παράλληλη εκτέλεση κώδικα που μπορεί να σχετίζεται με εξωτερικά APIs, όπως με ένα blockchain ή μία βάση δεδομένων. Με αυτόν τον τρόπο, τα τελευταία μπορούν να συμπεριληφθούν στο κεντρικό Redux store και τη διαχείριση του συνολικού state της εφαρμογής.

6
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.3.ethereum-technologies.tex → chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies.tex

@ -1,6 +1,6 @@
\subsection{Τεχνολογίες σχετικές με το Ethereum} \label{subsection:4-3-3-ethereum-technologies}
\subsection{Τεχνολογίες σχετικές με το Ethereum} \label{subsection:4-2-3-ethereum-technologies}
Στην παρούσα υποενότητα περιγράφονται εκείνες οι τεχνολογίες που σχετίζονται με το Ethereum, δηλαδή με το Application tier της τεχνολογικής στοίβας.
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.3.ethereum-technologies/4.3.3.1.truffle}
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.3.ethereum-technologies/4.3.3.2.ganache}
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.1.truffle}
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.2.ganache}

4
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.3.ethereum-technologies/4.3.3.1.truffle.tex → chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.1.truffle.tex

@ -1,6 +1,6 @@
\subsubsection{Truffle} \label{subsection:4-3-3-1-truffle}
\subsubsection{Truffle} \label{subsection:4-2-3-1-truffle}
\logo{chapter-4/4.3.truffle-logo}{Truffle logo}
\logo{chapter-4/4.2.truffle-logo}{Truffle logo}
Το Truffle\footnote{\url{https://trufflesuite.com/truffle/}} είναι ένα από τα δημοφιλέστερα Ethereum development frameworks και αποτελεί τμήμα της σουίτας Truffle.

6
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.3.ethereum-technologies/4.3.3.2.ganache.tex → chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.3.ethereum-technologies/4.2.3.2.ganache.tex

@ -1,6 +1,6 @@
\subsubsection{Ganache} \label{subsection:4-3-3-2-ganache}
\subsubsection{Ganache} \label{subsection:4-2-3-2-ganache}
\logo{chapter-4/4.3.ganache-logo}{Ganache logo}
\logo{chapter-4/4.2.ganache-logo}{Ganache logo}
Το Ganache\footnote{\url{https://trufflesuite.com/ganache/}} είναι ένα λογισμικό που παρέχει ένα βοηθητικό προσωπικό Ethereum blockchain για ταχεία ανάπτυξη αποκεντρωμένων εφαρμογών και αποτελεί επίσης τμήμα της σουίτας Truffle. Διατίθεται τόσο ως desktop εφαρμογή με UI, όσο και ως CLI (command-line interface).
@ -14,7 +14,7 @@ To Ganache παρέχει ισχυρά εργαλεία για την ανάπτ
\begin{figure}[H]
\centering
\includegraphics[width=.95\textwidth]{assets/figures/chapter-4/4.3.ganache-gui}
\includegraphics[width=.95\textwidth]{assets/figures/chapter-4/4.2.ganache-gui}
\caption{Ganache (desktop εφαρμογή)}
\end{figure}

7
chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies.tex

@ -0,0 +1,7 @@
\subsection{Τεχνολογίες σχετικές με το IPFS}
Σε αυτήν την υποενότητα περιγράφονται όσες τεχνολογίες σχετίζονται με το IPFS (βλ. ενότητα \ref{section:2-7-ipfs}), δηλαδή με το Data tier της τεχνολογικής στοίβας της εφαρμογής.
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.1.js-ipfs}
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.2.orbit-db}
\input{chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.3.libp2p}

4
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.4.ipfs-technologies/4.3.4.1.js-ipfs.tex → chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.1.js-ipfs.tex

@ -1,6 +1,6 @@
\subsubsection{js-ipfs} \label{subsection:4-3-4-1-js-ipfs}
\subsubsection{js-ipfs} \label{subsection:4-2-4-1-js-ipfs}
\logo{chapter-4/4.3.js-ipfs-logo}{js-ipfs logo}
\logo{chapter-4/4.2.js-ipfs-logo}{js-ipfs logo}
H υλοποίηση του IPFS που χρησιμοποείται στην εφαρμογή Concordia είναι αυτή σε Javascript και ονομάζεται js-ipfs. Μέσω αυτής της βιβλιοθήκης, παρέχεται η δυνατότητα δημιουργίας ενός IPFS κόμβου, τόσο σε έναν Node.js server, όσο και σε ένα περιβάλλον browser.

8
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.4.ipfs-technologies/4.3.4.2.orbit-db.tex → chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.2.orbit-db.tex

@ -1,8 +1,8 @@
\subsubsection{OrbitDB} \label{subsection:4-3-4-2-orbit-db}
\subsubsection{OrbitDB} \label{subsection:4-2-4-2-orbit-db}
\logo{chapter-4/4.3.orbitdb-logo}{OrbitDB logo}
\logo{chapter-4/4.2.orbitdb-logo}{OrbitDB logo}
Η OrbitDB είναι μία P2P βάση δεδομένων ανοιχτού κώδικα. Χρησιμοποιεί το IPFS για την αποθήκευση των δεδομένων και το IPFS Pubsub για τον αυτόματο συγχρονισμό των βάσεων δεδομένων μεταξύ των peers. Είναι τελικά συνεπής (eventually consistent) και χρησιμοποιεί CRDTs (Conflict-Free Replicated Data Types) για συγχωνεύσεις βάσεων δεδομένων χωρίς συγκρούσεις, πράγμα που την καθιστά εξαιρετική επιλογή για DApps και offline-first web applications.\cite{4.3-orbitdb}
Η OrbitDB είναι μία P2P βάση δεδομένων ανοιχτού κώδικα. Χρησιμοποιεί το IPFS για την αποθήκευση των δεδομένων και το IPFS Pubsub για τον αυτόματο συγχρονισμό των βάσεων δεδομένων μεταξύ των peers. Είναι τελικά συνεπής (eventually consistent) και χρησιμοποιεί CRDTs (Conflict-Free Replicated Data Types) για συγχωνεύσεις βάσεων δεδομένων χωρίς συγκρούσεις, πράγμα που την καθιστά εξαιρετική επιλογή για DApps και offline-first web applications.\cite{4.2-orbitdb}
Κάποια βασικά χαρακτηριστικά της είναι τα εξής:
\begin{itemize}
@ -18,7 +18,7 @@
Όλα τα stores υλοποιούνται πάνω στο \texttt{ipfs-log}, μία αμετάβλητη, operation-based CRDT για κατανεμημένα συστήματα, ενώ υπάρχει και η δυνατότητα δημιουργίας προσαρμοσμένων stores ανάλογα με την περίπτωση.
\item \textbf{Address}: Κάθε βάση δεδομένων λαμβάνει κατά τη δημιουργία της μία διεύθυνση της μορφής \texttt{/orbitdb/CID/DATABASE\_NAME}, όπου \texttt{CID} είναι το IPFS multihash του μανιφέστου της και \texttt{DATABASE\_NAME} το όνομα της βάσης.\cite{4.3-orbitdb-guide}Το μανιφέστο είναι ένα IPFS object που περιέχει πληροφορίες της βάσης όπως το όνομα, τον τύπο και έναν δείκτη στον ελεγκτή πρόσβασης (access controller).
\item \textbf{Address}: Κάθε βάση δεδομένων λαμβάνει κατά τη δημιουργία της μία διεύθυνση της μορφής \texttt{/orbitdb/CID/DATABASE\_NAME}, όπου \texttt{CID} είναι το IPFS multihash του μανιφέστου της και \texttt{DATABASE\_NAME} το όνομα της βάσης.\cite{4.2-orbitdb-guide}Το μανιφέστο είναι ένα IPFS object που περιέχει πληροφορίες της βάσης όπως το όνομα, τον τύπο και έναν δείκτη στον ελεγκτή πρόσβασης (access controller).
\item \textbf{Identity}: Κάθε φορά που προστίθεται μία εγγραφή στη βάση υπογράφεται από τον δημιουργό της, ο οποίος προσδιορίζεται από μία ταυτότητα (identity). Το Identity object, πέρα από τον προεπιλεγμένο τρόπο λειτουργίας, μπορεί να προσαρμοστεί έτσι ώστε να συνδέεται με κάποιο εξωτερικό αναγνωριστικό.
Η μορφή του έχει ως εξής\footnote{Βλ. και \url{https://github.com/orbitdb/orbit-db-identity-provider}}:

4
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.4.ipfs-technologies/4.3.4.3.libp2p.tex → chapters/4.application-implementation/4.2.implementation-technology-stack/4.2.4.ipfs-technologies/4.2.4.3.libp2p.tex

@ -1,6 +1,6 @@
\subsubsection{Libp2p} \label{subsection:4-3-4-3-libp2p}
\subsubsection{Libp2p} \label{subsection:4-2-4-3-libp2p}
\logo{chapter-4/4.3.libp2p-logo}{Libp2p logo}
\logo{chapter-4/4.2.libp2p-logo}{Libp2p logo}
Η libp2p είναι ένα αρθρωτό σύστημα πρωτοκόλλων, προδιαγραφών και βιβλιοθηκών που επιτρέπουν την ανάπτυξη p2p εφαρμογών. Αποτελεί το υποκείμενο επίπεδο δικτύου του IPFS.\ref{2.7-ipfs-docs}

78
chapters/4.application-implementation/4.4.implementation-architecture.tex → chapters/4.application-implementation/4.3.implementation-architecture.tex

@ -1,9 +1,9 @@
\section{Αρχιτεκτονική υλοποίησης} \label{section:4-4-implementation-architecture}
\section{Αρχιτεκτονική υλοποίησης} \label{section:4-3-implementation-architecture}
Το σύστημα υλοποιήθηκε χρησιμοποιώντας το μοντέλο αρχιτεκτονικής των μικροϋπηρεσιών. Το μοντέλο των μικροϋπηρεσιών βασίζεται στην αποδόμηση του συστήματος σε μικρές μονάδες, οι οποίες συνεργάζονται ώστε να προσφέρουν ένα ενιαίο αποτέλεσμα. Η προσέγγιση αυτή έχει πολλά πλεονεκτήματα σε σύγκριση με την ανάπτυξη μονολιθικών εφαρμογών % todo: add reference
. Ο βασικός λόγος για τον οποίο επιλέχθηκε η αρχιτεκτονική μικροϋπηρεσιών είναι η ευκολία που προσφέρει στη γρήγορη ανάπτυξη καινούριων χαρακτηριστικών, ταυτόχρονα από διαφορετικά μέλη μίας ομάδας, ασύγχρονα και χωρίς την ανάγκη συνεχής επικοινωνίας και συνεννόησης μεταξύ τους. Αυτό συμβαίνει επειδή κάθε μέρος του συστήματος (υπηρεσία) είναι αυτόνομο και η ανάπτυξή του είναι διαχωρισμένη από το υπόλοιπο σύστημα με το οποίο είναι αδύναμα συνδεδεμένο (loosely coupled).
Το σύστημα συντίθεται από διάφορες μικροϋπηρεσίες, κάποιες από τις οποίες αναπτύχθηκαν στα πλαίσια αυτής της εργασίας ενώ άλλες αποτελούν δωρεάν λογισμικό ανοιχτού κώδικα. Οι μικροϋπηρεσίες αυτές συνοψίζονται στον παρακάτω πίνακα (πίνακας \ref{table:4-4-microservice-summary}).
Το σύστημα συντίθεται από διάφορες μικροϋπηρεσίες, κάποιες από τις οποίες αναπτύχθηκαν στα πλαίσια αυτής της εργασίας ενώ άλλες αποτελούν δωρεάν λογισμικό ανοιχτού κώδικα. Οι μικροϋπηρεσίες αυτές συνοψίζονται στον παρακάτω πίνακα (πίνακας \ref{table:4-3-microservice-summary}).
\begin{table}[H]
\begin{center}
@ -21,10 +21,10 @@
\end{tabularx}
\end{center}
\caption{Σύντομη περιγραφή υπηρεσιών συστήματος.}
\label{table:4-4-microservice-summary}
\label{table:4-3-microservice-summary}
\end{table}
Στα πλαίσια της εργασίας αναπτύχθηκαν επίσης διάφορα αρθρώματα, κυρίως με τη μορφή βιβλιοθηκών Javascript. Τα αρθρώματα χρησιμοποιούνται από τις υπηρεσίες για την επίτευξη των επιμέρους εργασιών. Η ανάπτυξη του λογισμικού σε ξεχωριστά αρθρώματα επιτρέπει την εύκολη επαναχρησιμοποίηση του κώδικα καθώς και τον διαχωρισμό των αυτόνομων τμημάτων κώδικα. Τα αρθρώματα συνοψίζονται στον παρακάτω πίνακα (πίνακας \ref{table:4-4-software-units-summary}).
Στα πλαίσια της εργασίας αναπτύχθηκαν επίσης διάφορα αρθρώματα, κυρίως με τη μορφή βιβλιοθηκών Javascript. Τα αρθρώματα χρησιμοποιούνται από τις υπηρεσίες για την επίτευξη των επιμέρους εργασιών. Η ανάπτυξη του λογισμικού σε ξεχωριστά αρθρώματα επιτρέπει την εύκολη επαναχρησιμοποίηση του κώδικα καθώς και τον διαχωρισμό των αυτόνομων τμημάτων κώδικα. Τα αρθρώματα συνοψίζονται στον παρακάτω πίνακα (πίνακας \ref{table:4-3-software-units-summary}).
\begin{table}[H]
\begin{center}
@ -41,22 +41,22 @@
\end{tabularx}
\end{center}
\caption{Σύντομη περιγραφή αρθρωμάτων συστήματος.}
\label{table:4-4-software-units-summary}
\label{table:4-3-software-units-summary}
\end{table}
Τα αρθρώματα και οι υπηρεσίες θα περιγραφούν σε μεγαλύτερη ανάλυση στα επόμενα κεφάλαια. Στο παρακάτω σχήμα (σχήμα \ref{figure:4-4-architecture-overview}) φαίνεται η συνολική αρχιτεκτονική του συστήματος.
Τα αρθρώματα και οι υπηρεσίες θα περιγραφούν σε μεγαλύτερη ανάλυση στα επόμενα κεφάλαια. Στο παρακάτω σχήμα (σχήμα \ref{figure:4-3-architecture-overview}) φαίνεται η συνολική αρχιτεκτονική του συστήματος.
\begin{figure}[H]
\centering
\includegraphics[width=.75\textwidth]{assets/figures/chapter-4/4.4.architecture-architecture-overview.png}
\includegraphics[width=.75\textwidth]{assets/figures/chapter-4/4.3.architecture-architecture-overview.png}
\caption{Διάγραμμα αρχιτεκτονικής συστήματος}
\label{figure:4-4-architecture-overview}
\label{figure:4-3-architecture-overview}
\end{figure}
% ===== =====
% Common software units
% ===== =====
\subsection{Αρθρώματα} \label{subsection:4-4-software-units}
\subsection{Αρθρώματα} \label{subsection:4-3-software-units}
Στο κεφάλαιο αυτό θα περιγραφούν με μεγαλύτερη λεπτομέρεια τα αρθρώματα που αναπτύχθηκαν.
@ -103,12 +103,12 @@
% ===== =====
% concordia-app microservice
% ===== =====
\subsection{Concordia Application} \label{subsection:4-4-concordia-application-service}
\subsection{Concordia Application} \label{subsection:4-3-concordia-application-service}
\vspace{0.5cm}
\textbf{Περιγραφή - Στόχοι υπηρεσίας}
Η εφαρμογή Concordia (Concordia Application) εκθέτει τις γραφικές διεπαφές μέσω των οποίων αλληλεπιδρούν οι χρήστες με το σύστημα. Αποτελεί τον δίαυλο επικοινωνίας του τελικού χρήστη με το blockchain και με τη βάση OrbitDB. Η αρχιτεκτονική της υπηρεσίας φαίνεται στο σχήμα \ref{figure:4-4-concordia-application-architecture}. Μέσω της εφαρμογής Concordia οι χρήστες μπορούν να:
Η εφαρμογή Concordia (Concordia Application) εκθέτει τις γραφικές διεπαφές μέσω των οποίων αλληλεπιδρούν οι χρήστες με το σύστημα. Αποτελεί τον δίαυλο επικοινωνίας του τελικού χρήστη με το blockchain και με τη βάση OrbitDB. Η αρχιτεκτονική της υπηρεσίας φαίνεται στο σχήμα \ref{figure:4-3-concordia-application-architecture}. Μέσω της εφαρμογής Concordia οι χρήστες μπορούν να:
\begin{itemize}
\item περιηγηθούν και διαβάσουν το περιεχόμενο της πλατφόρμας
@ -133,9 +133,9 @@
\begin{figure}[H]
\centering
\includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.4.architecture-4.4.2.concordia-application-architecture.png}
\includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.2.concordia-application-architecture.png}
\caption{Αρχιτεκτονική υπηρεσίας Concordia Application}
\label{figure:4-4-concordia-application-architecture}
\label{figure:4-3-concordia-application-architecture}
\end{figure}
Για τη λειτουργία της υπηρεσία Concordia Application είναι απαραίτητα τα αντικείμενα (artifacts) που προκύπτουν από τη μεταγλώττιση των contracts και τη μεταφόρτωση/δημοσίευσή τους στο blockchain. Για την εισαγωγή των artifacts στην υπηρεσία έχουν αναπτυχθεί δύο μέθοδοι.
@ -152,18 +152,18 @@
% ===== =====
% concordia-contracts-migrator microservice
% ===== =====
\subsection{Concordia Contracts Migrator} \label{subsection:4-4-concordia-contracts-migrator}
\subsection{Concordia Contracts Migrator} \label{subsection:4-3-concordia-contracts-migrator}
\vspace{0.5cm}
\textbf{Περιγραφή - Στόχοι υπηρεσίας}
Η υπηρεσία αυτή αποτελείται από ένα εκτελέσιμο πρόγραμμα γραμμής εντολών βασισμένο στο άρθρωμα concordia-contracts που αναλύθηκε σε προηγούμενη υποενότητα (\ref{subsection:4-4-software-units}). Το πρόγραμμα, κατά την εκτέλεσή του, μεταγλωττίζει τα contracts και έπειτα τα μεταφορτώνει στο blockchain το οποίο είναι ορισμένο με χρήση μεταβλητών περιβάλλοντος. Τέλος, αν οι κατάλληλες μεταβλητές περιβάλλοντος είναι ορισμένες, το πρόγραμμα μεταφορτώνει τα τελικά artifacts σε αποθετήριο Concordia Contracts Provider. Η αρχιτεκτονική της υπηρεσίας φαίνεται στο παρακάτω σχήμα (σχήμα \ref{figure:4-4-concordia-contracts-migrator-architecture}).
Η υπηρεσία αυτή αποτελείται από ένα εκτελέσιμο πρόγραμμα γραμμής εντολών βασισμένο στο άρθρωμα concordia-contracts που αναλύθηκε σε προηγούμενη υποενότητα (\ref{subsection:4-3-software-units}). Το πρόγραμμα, κατά την εκτέλεσή του, μεταγλωττίζει τα contracts και έπειτα τα μεταφορτώνει στο blockchain το οποίο είναι ορισμένο με χρήση μεταβλητών περιβάλλοντος. Τέλος, αν οι κατάλληλες μεταβλητές περιβάλλοντος είναι ορισμένες, το πρόγραμμα μεταφορτώνει τα τελικά artifacts σε αποθετήριο Concordia Contracts Provider. Η αρχιτεκτονική της υπηρεσίας φαίνεται στο παρακάτω σχήμα (σχήμα \ref{figure:4-3-concordia-contracts-migrator-architecture}).
\begin{figure}[H]
\centering
\includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.4.architecture-4.4.3.concordia-contracts-migrator-architecture.png}
\includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.3.concordia-contracts-migrator-architecture.png}
\caption{Αρχιτεκτονική υπηρεσίας Concordia Contracts Migrator}
\label{figure:4-4-concordia-contracts-migrator-architecture}
\label{figure:4-3-concordia-contracts-migrator-architecture}
\end{figure}
\vspace{0.5cm}
@ -174,18 +174,18 @@
% ===== =====
% concordia-pinner microservice
% ===== =====
\subsection{Concordia Pinner} \label{subsection:4-4-concordia-pinner-service}
\subsection{Concordia Pinner} \label{subsection:4-3-concordia-pinner-service}
\vspace{0.5cm}
\textbf{Περιγραφή - Στόχοι υπηρεσίας}
Η υπηρεσία καρφιτσώματος περιεχομένου (Concordia Pinner) αποτελεί μία εφαρμογή τερματικού (temrinal application/cmd application) η οποία στοχεύει στο καρφίτσωμα (pinning) του περιεχομένου που αποθηκεύεται στο IPFS μέσω της βάσης OrbitDB. Η υπηρεσία είναι γραμμένη στη γλώσσα προγραμματισμού Javascript. Η αρχιτεκτονική της υπηρεσίας φαίνεται το σχήμα \ref{figure:4-4-concordia-pinner-architecture}.
Η υπηρεσία καρφιτσώματος περιεχομένου (Concordia Pinner) αποτελεί μία εφαρμογή τερματικού (temrinal application/cmd application) η οποία στοχεύει στο καρφίτσωμα (pinning) του περιεχομένου που αποθηκεύεται στο IPFS μέσω της βάσης OrbitDB. Η υπηρεσία είναι γραμμένη στη γλώσσα προγραμματισμού Javascript. Η αρχιτεκτονική της υπηρεσίας φαίνεται το σχήμα \ref{figure:4-3-concordia-pinner-architecture}.
\begin{figure}[H]
\centering
\includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.4.architecture-4.4.4.concordia-pinner-architecture.png}
\includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.4.concordia-pinner-architecture.png}
\caption{Αρχιτεκτονική υπηρεσίας Concordia Pinner}
\label{figure:4-4-concordia-pinner-architecture}
\label{figure:4-3-concordia-pinner-architecture}
\end{figure}
Η υπηρεσία αυτή υλοποιήθηκε για να εγγυηθεί η διαθεσιμότητα του περιεχομένου του συστήματος που αποθηκεύεται στο IPFS (τίτλοι θεμάτων, περιεχόμενο μηνυμάτων και άλλα). Λόγω του τρόπου λειτουργίας % todo: insert reference
@ -202,21 +202,21 @@
% ===== =====
% concordia-contracts-provider microservice
% ===== =====
\subsection{Concordia Contracts Provider} \label{subsection:4-4-concordia-contracts-provider-service}
\subsection{Concordia Contracts Provider} \label{subsection:4-3-concordia-contracts-provider-service}
\vspace{0.5cm}
\textbf{Περιγραφή - Στόχοι υπηρεσίας}
Η υπηρεσία Contracts Provider αποτελεί μία βοηθητική υπηρεσία η οποία υλοποιεί ένα απλό αποθετήριο για τα contract artifacts. Είναι γραμμένη σε Javascript και διαθέτει δύο HTTP \textenglish{endpoints}, ένα για τη μεταφόρτωση (upload) των artifacts προς την υπηρεσία και ένα για τη λήψη (download) από την υπηρεσία. Η υπηρεσία υποστηρίζει επίσης την επισύναψη ετικετών στα artifacts, όπως η έκδοση (version) ή το κλαδί ανάπτυξης (branch, για παράδειγμα \textenglish{master/develop}). Η αρχιτεκτονική της υπηρεσίας φαίνεται το σχήμα \ref{figure:4-4-concordia-contracts-provider-architecture}.
Η υπηρεσία Contracts Provider αποτελεί μία βοηθητική υπηρεσία η οποία υλοποιεί ένα απλό αποθετήριο για τα contract artifacts. Είναι γραμμένη σε Javascript και διαθέτει δύο HTTP \textenglish{endpoints}, ένα για τη μεταφόρτωση (upload) των artifacts προς την υπηρεσία και ένα για τη λήψη (download) από την υπηρεσία. Η υπηρεσία υποστηρίζει επίσης την επισύναψη ετικετών στα artifacts, όπως η έκδοση (version) ή το κλαδί ανάπτυξης (branch, για παράδειγμα \textenglish{master/develop}). Η αρχιτεκτονική της υπηρεσίας φαίνεται το σχήμα \ref{figure:4-3-concordia-contracts-provider-architecture}.
\begin{figure}[H]
\centering
\includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.4.architecture-4.4.5.concordia-contracts-provider-architecture.png}
\includegraphics[width=.6\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.5.concordia-contracts-provider-architecture.png}
\caption{Αρχιτεκτονική υπηρεσίας Concordia Contracts Provider}
\label{figure:4-4-concordia-contracts-provider-architecture}
\label{figure:4-3-concordia-contracts-provider-architecture}
\end{figure}
Η υπηρεσία χρησιμοποιείται σε μία προσπάθεια αποσύνδεσης της βασικής εφαρμογής που υλοποιεί η υπηρεσία Concordia Application από μία συγκεκριμένη έκδοση των contracts. Οι λόγοι που αυτό είναι επιθυμητό αναπτύχθηκαν στην περιγραφή της υπηρεσίας Concordia \textenglish{Application} (υποενότητα \ref{subsection:4-4-concordia-application-service}). Ωστόσο, η υπηρεσία Contracts Provider αποτελεί σημείο κεντροποίησης του συστήματος, για το λόγο αυτό θεωρείται προσωρινή λύση η οποία θα μπορούσε να αντικατασταθεί από αποκεντρωτικές λύσεις όπως η μεταφόρτωση των artifacts στο IPFS και ο διαμοιρασμός τους από εκεί.
Η υπηρεσία χρησιμοποιείται σε μία προσπάθεια αποσύνδεσης της βασικής εφαρμογής που υλοποιεί η υπηρεσία Concordia Application από μία συγκεκριμένη έκδοση των contracts. Οι λόγοι που αυτό είναι επιθυμητό αναπτύχθηκαν στην περιγραφή της υπηρεσίας Concordia \textenglish{Application} (υποενότητα \ref{subsection:4-3-concordia-application-service}). Ωστόσο, η υπηρεσία Contracts Provider αποτελεί σημείο κεντροποίησης του συστήματος, για το λόγο αυτό θεωρείται προσωρινή λύση η οποία θα μπορούσε να αντικατασταθεί από αποκεντρωτικές λύσεις όπως η μεταφόρτωση των artifacts στο IPFS και ο διαμοιρασμός τους από εκεί.
\vspace{0.5cm}
\textbf{Διανομή}
@ -226,7 +226,7 @@
% ===== =====
% rendezvous-ganache microservice
% ===== =====
\subsection{Ganache} \label{subsection:4-4-ganache-service}
\subsection{Ganache} \label{subsection:4-3-ganache-service}
\vspace{0.5cm}
\textbf{Περιγραφή - Στόχοι υπηρεσίας}
@ -241,7 +241,7 @@
% ===== =====
% rendezvous-server microservice
% ===== =====
\subsection{Rendezvous Server} \label{subsection:4-4-rendezvous-server-service}
\subsection{Rendezvous Server} \label{subsection:4-3-rendezvous-server-service}
\vspace{0.5cm}
\textbf{Περιγραφή - Στόχοι υπηρεσίας}
@ -256,17 +256,17 @@
% ===== =====
% microservice communication
% ===== =====
\subsection{Διασύνδεση υπηρεσιών} \label{subsection:4-4-service-communication}
\subsection{Διασύνδεση υπηρεσιών} \label{subsection:4-3-service-communication}
Στο μοντέλο των μικροϋπηρεσιών, βασικό χαρακτηριστικό είναι η επικοινωνία των ξεχωριστών υπηρεσιών και η ανταλλαγή μηνυμάτων για την επίτευξη των λειτουργικοτήτων του συστήματος. Σε αυτήν την υποενότητα θα αναλυθεί ο τρόπος με τον οποίο οι μικροϋπηρεσίες επικοινωνούν μεταξύ τους καθώς και η φύση και το περιεχόμενο των μηνυμάτων που ανταλλάσουν.
Στο παρακάτω σχήμα (σχήμα \ref{figure:4-4-communications-graph}) φαίνεται ο γράφος που οπτικοποιεί τα κανάλια επικοινωνίας μεταξύ των μικροϋπηρεσιών, καθώς και τα κανάλια επικοινωνίας των μικροϋπηρεσιών με το blockchain.
Στο παρακάτω σχήμα (σχήμα \ref{figure:4-3-communications-graph}) φαίνεται ο γράφος που οπτικοποιεί τα κανάλια επικοινωνίας μεταξύ των μικροϋπηρεσιών, καθώς και τα κανάλια επικοινωνίας των μικροϋπηρεσιών με το blockchain.
\begin{figure}[H]
\centering
\includegraphics[width=.9\textwidth]{assets/figures/chapter-4/4.4.communications-diagram.png}
\includegraphics[width=.9\textwidth]{assets/figures/chapter-4/4.3.communications-diagram.png}
\caption{Γράφος οπτικοποίησης των καναλιών επικοινωνίας των μικροϋπηρεσιών}
\label{figure:4-4-communications-graph}
\label{figure:4-3-communications-graph}
\end{figure}
Εδώ αναλύεται η επικοινωνία κάθε μικροϋπηρεσίας:
@ -286,7 +286,7 @@
% ===== =====
% data flow
% ===== =====
\subsection{Ροή πληροφορίας} \label{subsection:4-4-data-flow}
\subsection{Ροή πληροφορίας} \label{subsection:4-3-data-flow}
Στην παρούσα υποενότητα θα αναλυθεί η ροή της πληροφορίας στο σύστημα. Λόγω των πολλαπλών υπηρεσιών, της κατάτμησης την πληροφορίας και των διαφορετικών σημείων αποθήκευσης της, η ροή της πληροφορίας στο σύστημα ακολουθεί ένα σχετικά περίπλοκο μονοπάτι (σε σχέση με κλασσικές, μονολιθικές, κεντροποιημένες εφαρμογές).
@ -296,21 +296,21 @@
Τέλος, παρακάτω δίνεται ένα παράδειγμα εισαγωγής πληροφορίας στο σύστημα και έπειτα ανάκτησης της ίδιας πληροφορίας.
Έστω, χρήστης που δημιουργεί νέο θέμα. Τα δεδομένα που παράγονται είναι ο τίτλος του θέματος και το περιεχόμενο του πρώτου μηνύματος. Μεταδεδομένα της δημιουργίας είναι η διεύθυνση του/της δημιουργού του θέματος. Για την αποθήκευση του θέματος στο σύστημα δημιουργείται πρώτα συναλλαγή στο blockchain ώστε να δημιουργηθεί μία νέα εγγραφή στον πίνακα των θεμάτων. Η εγγραφή αυτή δεν περιέχει τίποτα παρά μόνο τη διεύθυνση του/της δημιουργού χρήστη. Αν η συναλλαγή είναι επιτυχής, θα επιστραφεί ο αύξων αριθμός του νέου θέματος. Έπειτα, στην προσωπική βάση OrbitDB του/της χρήστη και στον πίνακα των θεμάτων θα προστεθεί εγγραφή με αναγνωριστικό τον αύξων αριθμό του θέματος όπου θα αποθηκευτούν τα δεδομένα του τίτλου και πρώτου μηνύματος. Στο σχήμα \ref{figure:4-4-data-flow-insert} παρουσιάζεται γραφικά η διαδικασία.
Έστω, χρήστης που δημιουργεί νέο θέμα. Τα δεδομένα που παράγονται είναι ο τίτλος του θέματος και το περιεχόμενο του πρώτου μηνύματος. Μεταδεδομένα της δημιουργίας είναι η διεύθυνση του/της δημιουργού του θέματος. Για την αποθήκευση του θέματος στο σύστημα δημιουργείται πρώτα συναλλαγή στο blockchain ώστε να δημιουργηθεί μία νέα εγγραφή στον πίνακα των θεμάτων. Η εγγραφή αυτή δεν περιέχει τίποτα παρά μόνο τη διεύθυνση του/της δημιουργού χρήστη. Αν η συναλλαγή είναι επιτυχής, θα επιστραφεί ο αύξων αριθμός του νέου θέματος. Έπειτα, στην προσωπική βάση OrbitDB του/της χρήστη και στον πίνακα των θεμάτων θα προστεθεί εγγραφή με αναγνωριστικό τον αύξων αριθμό του θέματος όπου θα αποθηκευτούν τα δεδομένα του τίτλου και πρώτου μηνύματος. Στο σχήμα \ref{figure:4-3-data-flow-insert} παρουσιάζεται γραφικά η διαδικασία.
% todo: UML diagrams might be wrong, should the ethereum and orbitDb blocks be continuous?
\begin{figure}[H]
\centering
\includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.4.architecture-4.4.9.data-flow-insert.png}
\includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-insert.png}
\caption{Διάγραμμα ακολουθίας δημιουργίας θέματος}
\label{figure:4-4-data-flow-insert}
\label{figure:4-3-data-flow-insert}
\end{figure}
Έστω, χρήστης που επιθυμεί να διαβάσει το προηγούμενο μήνυμα. Αρχικά, πρέπει να διαβαστεί ο πίνακας θεμάτων από το blockchain. Η πληροφορία αυτή εμπλουτίζεται από τα δεδομένα του κάθε θέματος, τα οποία ανακτώνται από τις προσωπικές βάσεις Orbit κάθε χρήστη. Έπειτα, εφόσον το θέμα βρεθεί και ο αύξων αριθμός του είναι γνωστός, πρέπει να διαβαστούν από το blockchain τα μεταδομένα των μηνυμάτων του θέματος και συγκεκριμένα η διευθύνσεις των δημιουργών τους. Τέλος, μέσω του IPFS πρέπει να γίνει αντιγραφή των προσωπικών βάσεων των δημιουργών του κάθε μηνύματος και να αναζητηθούν σε αυτές τα εκάστοτε μηνύματα. Στο σχήμα \ref{figure:4-4-data-flow-read} φαίνεται το διάγραμμα ροής της πληροφορίας κατά την ανάκτηση πληροφοριών από το σύστημα.
Έστω, χρήστης που επιθυμεί να διαβάσει το προηγούμενο μήνυμα. Αρχικά, πρέπει να διαβαστεί ο πίνακας θεμάτων από το blockchain. Η πληροφορία αυτή εμπλουτίζεται από τα δεδομένα του κάθε θέματος, τα οποία ανακτώνται από τις προσωπικές βάσεις Orbit κάθε χρήστη. Έπειτα, εφόσον το θέμα βρεθεί και ο αύξων αριθμός του είναι γνωστός, πρέπει να διαβαστούν από το blockchain τα μεταδομένα των μηνυμάτων του θέματος και συγκεκριμένα η διευθύνσεις των δημιουργών τους. Τέλος, μέσω του IPFS πρέπει να γίνει αντιγραφή των προσωπικών βάσεων των δημιουργών του κάθε μηνύματος και να αναζητηθούν σε αυτές τα εκάστοτε μηνύματα. Στο σχήμα \ref{figure:4-3-data-flow-read} φαίνεται το διάγραμμα ροής της πληροφορίας κατά την ανάκτηση πληροφοριών από το σύστημα.
\begin{figure}[H]
\centering
\includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.4.architecture-4.4.9.data-flow-read.png}
\includegraphics[width=.7\textwidth]{assets/figures/chapter-4/4.3.architecture-4.3.9.data-flow-read.png}
\caption{Διάγραμμα ακολουθίας εύρεσης και ανάκτησης θέματος}
\label{figure:4-4-data-flow-read}
\label{figure:4-3-data-flow-read}
\end{figure}

9
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.1.development-technologies.tex

@ -1,9 +0,0 @@
\subsection{Τεχνολογίες σχετικές με το development}
Σε αυτήν την υποενότητα περιγράφονται ορισμένα θεμελιώδη εργαλεία και frameworks που συνετέλεσαν στην ανάπτυξη της εφαρμογής.
%TODO: Add janus and build steps diagram
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.1.development-technologies/4.3.1.1.node.js}
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.1.development-technologies/4.3.1.2.docker}
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.1.development-technologies/4.3.1.3.jenkins}

9
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.2.ui-technologies.tex

@ -1,9 +0,0 @@
\subsection{Τεχνολογίες σχετικές με το UI}
Στην παρούσα υποενότητα περιγράφονται όσες τεχνολογίες σχετίζονται με τη διεπαφή του χρήστη (UI), δηλαδή με το Presentation tier.
% TODO: add technologies like redux, sagas
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.2.ui-technologies/4.3.2.1.react}
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.2.ui-technologies/4.3.2.2.redux}
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.2.ui-technologies/4.3.2.3.redux-saga}

7
chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.4.ipfs-technologies.tex

@ -1,7 +0,0 @@
\subsection{Τεχνολογίες σχετικές με το IPFS}
Σε αυτήν την υποενότητα περιγράφονται όσες τεχνολογίες σχετίζονται με το IPFS (βλ. ενότητα \ref{section:2-7-ipfs}), δηλαδή με το Data tier της τεχνολογικής στοίβας της εφαρμογής.
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.4.ipfs-technologies/4.3.4.1.js-ipfs}
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.4.ipfs-technologies/4.3.4.2.orbit-db}
\input{chapters/4.application-implementation/4.3.implementation-technology-stack/4.3.4.ipfs-technologies/4.3.4.3.libp2p}

0
chapters/4.application-implementation/4.5.problems-faced.tex → chapters/4.application-implementation/4.4.problems-faced.tex

9
chapters/4.application-implementation/4.6.design-implementation-differences.tex → chapters/4.application-implementation/4.5.implemented-parts.tex

@ -1,4 +1,9 @@
\section{Διαφορές σχεδιασμού-υλοποίησης} \label{section:4-6-design-implementation-differences}
\section{Χαρακτηριστικά που υλοποιήθηκαν} \label{section:4-6-implemented-parts}
TODO: add references to use cases implemented with screenshots of application
TODO: add unimplemented parts like serve (front and contracts) thru IPFS, upgradability
\subsection{Διαφορές σχεδιασμού-υλοποίησης} \label{subsection:4-6-1-design-implementation-differences}
Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα (σχήμα \ref{figure:4.6.design-implementation-differences-sprints}).
@ -8,3 +13,5 @@
\caption{Διαχωρισμός σε sprints}
\label{figure:4.6.design-implementation-differences-sprints}
\end{figure}
TODO: add differences in architecture

BIN
thesis.pdf

Binary file not shown.
Loading…
Cancel
Save