Ezerous
3 years ago
115 changed files with 1465 additions and 340 deletions
@ -0,0 +1,6 @@ |
|||||
|
# Αυτόνομο κοινωνικό δίκτυο βασισμένο σε τεχνολογίες αποκέντρωσης |
||||
|
|
||||
|
*WIP* |
||||
|
|
||||
|
## How to run |
||||
|
`xelatex.exe -synctex=1 -interaction=nonstopmode -shell-escape "thesis".tex` |
||||
|
Before Width: | Height: | Size: 138 KiB After Width: | Height: | Size: 138 KiB |
|
Before Width: | Height: | Size: 410 KiB After Width: | Height: | Size: 410 KiB |
|
Before Width: | Height: | Size: 250 KiB After Width: | Height: | Size: 250 KiB |
|
Before Width: | Height: | Size: 139 KiB After Width: | Height: | Size: 139 KiB |
|
Before Width: | Height: | Size: 193 KiB After Width: | Height: | Size: 193 KiB |
|
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 44 KiB |
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 120 KiB After Width: | Height: | Size: 120 KiB |
|
After Width: | Height: | Size: 161 KiB |
|
After Width: | Height: | Size: 409 KiB |
|
After Width: | Height: | Size: 639 KiB |
|
After Width: | Height: | Size: 702 KiB |
|
After Width: | Height: | Size: 168 KiB |
|
After Width: | Height: | Size: 37 KiB |
|
After Width: | Height: | Size: 97 KiB |
|
After Width: | Height: | Size: 62 KiB |
|
After Width: | Height: | Size: 122 KiB |
|
After Width: | Height: | Size: 689 KiB |
|
After Width: | Height: | Size: 49 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 112 KiB After Width: | Height: | Size: 112 KiB |
|
After Width: | Height: | Size: 57 KiB |
|
After Width: | Height: | Size: 2.4 MiB |
|
After Width: | Height: | Size: 46 KiB |
|
After Width: | Height: | Size: 25 KiB |
|
After Width: | Height: | Size: 112 KiB |
@ -1,134 +1,120 @@ |
|||||
% See also: https://www.overleaf.com/learn/latex/bibliography_management_with_bibtex |
% See also: https://www.overleaf.com/learn/latex/bibliography_management_with_bibtex |
||||
|
|
||||
@misc{1.2-ethereum-learn, |
@misc{1.2-ethereum-learn, |
||||
title = {Μάθετε για το Ethereum}, |
title = {Μάθετε για το Ethereum}, |
||||
urldate = {2021-03-16}, |
url = {https://ethereum.org/el/learn/}, |
||||
url = {https://ethereum.org/el/learn/} |
urldate = {2021-03-16} |
||||
} |
} |
||||
|
|
||||
@online{1.2-the-meaning-of-decentralization, |
@online{1.2-the-meaning-of-decentralization, |
||||
author = {Vitalik Buterin}, |
|
||||
title = {The Meaning of Decentralization}, |
title = {The Meaning of Decentralization}, |
||||
date = {2017-02-06}, |
author = {Vitalik Buterin}, |
||||
url = {https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274} |
url = {https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274}, |
||||
} |
date = {2017-02-06} |
||||
|
|
||||
@online{1.4-github-flow, |
|
||||
author = {GitHub Guides}, |
|
||||
title = {Understanding the GitHub flow}, |
|
||||
url = {https://guides.github.com/introduction/flow/} |
|
||||
} |
} |
||||
|
|
||||
@book{1.2-virtual-migration, |
@book{1.2-virtual-migration, |
||||
author = {Aneesh, A.}, |
|
||||
title = {Virtual Migration}, |
title = {Virtual Migration}, |
||||
date = {2006}, |
author = {Aneesh, A.}, |
||||
OPTpublisher = {Duke University Press} |
date = 2006, |
||||
|
optpublisher = {Duke University Press} |
||||
} |
} |
||||
|
|
||||
@article{2.2-ecdsa, |
@article{2.2-ecdsa, |
||||
author = {Johnson, Don and Menezes, Alfred and Vanstone, Scott}, |
|
||||
title = {The Elliptic Curve Digital Signature Algorithm (ECDSA)}, |
title = {The Elliptic Curve Digital Signature Algorithm (ECDSA)}, |
||||
year = {2001}, |
author = {Johnson, Don and Menezes, Alfred and Vanstone, Scott}, |
||||
month = {Aug.}, |
year = 2001, |
||||
url = {https://doi.org/10.1007/s102070100002}, |
month = 8, |
||||
journal = {International Journal of Information Security}, |
journal = {International Journal of Information Security}, |
||||
doi = {10.1007/s102070100002} |
doi = {10.1007/s102070100002}, |
||||
|
url = {https://doi.org/10.1007/s102070100002} |
||||
} |
} |
||||
|
|
||||
@online{2.3-merkle-tree, |
@online{2.3-merkle-tree, |
||||
author = {Wikipedia}, |
|
||||
title = {Merkle tree}, |
title = {Merkle tree}, |
||||
|
author = {Wikipedia}, |
||||
url = {https://en.wikipedia.org/wiki/Merkle_tree} |
url = {https://en.wikipedia.org/wiki/Merkle_tree} |
||||
} |
} |
||||
|
|
||||
@online{2.3-merkle-proofs-explained, |
@online{2.3-merkle-proofs-explained, |
||||
author = {Belavadi Prahalad}, |
|
||||
title = {Merkle proofs Explained.}, |
title = {Merkle proofs Explained.}, |
||||
date = {2018-01-07}, |
author = {Belavadi Prahalad}, |
||||
url = {https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5} |
url = {https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5}, |
||||
|
date = {2018-01-07} |
||||
} |
} |
||||
|
|
||||
@inproceedings{2.4-p2p-networking, |
@inproceedings{2.4-p2p-networking, |
||||
|
title = {A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications}, |
||||
author = {Schollmeier, R.}, |
author = {Schollmeier, R.}, |
||||
|
year = 2001, |
||||
booktitle = {Proceedings First International Conference on Peer-to-Peer Computing}, |
booktitle = {Proceedings First International Conference on Peer-to-Peer Computing}, |
||||
title={A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications}, |
pages = {101--102}, |
||||
year={2001}, |
|
||||
pages={101-102}, |
|
||||
doi = {10.1109/P2P.2001.990434} |
doi = {10.1109/P2P.2001.990434} |
||||
} |
} |
||||
|
|
||||
@article{2.5-bitcoin, |
@article{2.5-bitcoin, |
||||
author = {Nakamoto, Satoshi}, |
|
||||
date = {2008-10-31}, |
|
||||
title = {Bitcoin: A Peer-to-Peer Electronic Cash System}, |
title = {Bitcoin: A Peer-to-Peer Electronic Cash System}, |
||||
journal = {Cryptography Mailing list at https://metzdowd.com} |
author = {Nakamoto, Satoshi}, |
||||
|
journal = {Cryptography Mailing list at https://metzdowd.com}, |
||||
|
date = {2008-10-31} |
||||
} |
} |
||||
|
|
||||
@misc{2.5-blockchain, |
@misc{2.5-blockchain, |
||||
author = {Wikipedia}, |
|
||||
title = {Blockchain}, |
title = {Blockchain}, |
||||
|
author = {Wikipedia}, |
||||
url = {https://en.wikipedia.org/wiki/Blockchain} |
url = {https://en.wikipedia.org/wiki/Blockchain} |
||||
} |
} |
||||
|
|
||||
@online{2.6-ethereum-whitepaper, |
@online{2.6-ethereum-whitepaper, |
||||
author = {Vitalik Buterin}, |
|
||||
title = {Ethereum Whitepaper}, |
title = {Ethereum Whitepaper}, |
||||
date = {2013}, |
author = {Vitalik Buterin}, |
||||
|
url = {https://ethereum.org/en/whitepaper}, |
||||
urldate = {2021-06-28}, |
urldate = {2021-06-28}, |
||||
url = {https://ethereum.org/en/whitepaper} |
date = 2013 |
||||
} |
} |
||||
|
|
||||
@online{2.6-ethereum-documentation, |
@online{2.6-ethereum-documentation, |
||||
author = {Ethereum community}, |
|
||||
title = {Ethereum documentation}, |
title = {Ethereum documentation}, |
||||
urldate = {2021-09-05}, |
author = {Ethereum community}, |
||||
url = {https://ethereum.org/en/developers/docs/} |
url = {https://ethereum.org/en/developers/docs/}, |
||||
|
urldate = {2021-09-05} |
||||
} |
} |
||||
|
|
||||
@article{2.6-ethereum-smart-contracts, |
@article{2.6-ethereum-smart-contracts, |
||||
author={Szabo, Nick}, |
|
||||
title = {Formalizing and Securing Relationships on Public Networks}, |
title = {Formalizing and Securing Relationships on Public Networks}, |
||||
url={https://journals.uic.edu/ojs/index.php/fm/article/view/548}, |
author = {Szabo, Nick}, |
||||
doi={10.5210/fm.v2i9.548}, |
year = 1997, |
||||
year={1997}, |
month = 9, |
||||
month={Sep.}, |
|
||||
journal = {First Monday}, |
journal = {First Monday}, |
||||
volume={2}, |
volume = 2, |
||||
number={9}, |
number = 9, |
||||
|
doi = {10.5210/fm.v2i9.548}, |
||||
|
url = {https://journals.uic.edu/ojs/index.php/fm/article/view/548} |
||||
} |
} |
||||
|
|
||||
@book{2.6-ethereum-mastering, |
@book{2.6-ethereum-mastering, |
||||
author = {Andreas M Antonopoulos, Gavin Wood}, |
|
||||
title = {Mastering Ethereum: Building Smart Contracts and DApps}, |
title = {Mastering Ethereum: Building Smart Contracts and DApps}, |
||||
date = {2018}, |
author = {Andreas M Antonopoulos, Gavin Wood}, |
||||
publisher = {O'Reilly Media}, |
publisher = {O'Reilly Media}, |
||||
isbn = {1491971940 }, |
isbn = 1491971940, |
||||
OPTurl = {https://cypherpunks-core.github.io/ethereumbook/}, |
date = 2018, |
||||
|
opturl = {https://cypherpunks-core.github.io/ethereumbook/} |
||||
} |
} |
||||
|
|
||||
@misc{2.7-ipfs, |
@misc{2.7-ipfs, |
||||
title = {IPFS}, |
title = {IPFS}, |
||||
url = {https://ipfs.io/} |
url = {https://ipfs.io/} |
||||
} |
} |
||||
|
|
||||
@misc{2.7-ipfs-docs, |
@misc{2.7-ipfs-docs, |
||||
title = {IPFS documentation}, |
title = {IPFS documentation}, |
||||
url = {https://docs.ipfs.io/} |
url = {https://docs.ipfs.io/} |
||||
} |
} |
||||
|
|
||||
@misc{2.7-merkle-dags-proto-school, |
@misc{2.7-merkle-dags-proto-school, |
||||
author = {ProtoSchool}, |
|
||||
title = {Merkle DAGs: Structuring Data for the Distributed Web}, |
title = {Merkle DAGs: Structuring Data for the Distributed Web}, |
||||
|
author = {ProtoSchool}, |
||||
url = {https://proto.school/merkle-dags/} |
url = {https://proto.school/merkle-dags/} |
||||
} |
} |
||||
|
@online{4.2-github-flow, |
||||
@misc{2.8-orbitdb, |
title = {Understanding the GitHub flow}, |
||||
|
author = {GitHub Guides}, |
||||
|
url = {https://guides.github.com/introduction/flow/} |
||||
|
} |
||||
|
@misc{4.3-node.js, |
||||
|
title = {Node.js}, |
||||
|
author = {Wikipedia}, |
||||
|
url = {https://en.wikipedia.org/wiki/Node.js} |
||||
|
} |
||||
|
@misc{4.3-orbitdb, |
||||
title = {OrbitDB}, |
title = {OrbitDB}, |
||||
url = {https://orbitdb.org} |
url = {https://orbitdb.org} |
||||
} |
} |
||||
|
@misc{4.3-orbitdb-guide, |
||||
@misc{2.8-orbitdb-guide, |
|
||||
title = {Getting Started with OrbitDB}, |
title = {Getting Started with OrbitDB}, |
||||
url = {https://github.com/orbitdb/orbit-db/blob/main/GUIDE.md} |
url = {https://github.com/orbitdb/orbit-db/blob/main/GUIDE.md} |
||||
} |
} |
||||
|
|||||
@ -1 +1,5 @@ |
|||||
\tableofcontents |
% TOC bookmark solution found here: |
||||
|
% https://tex.stackexchange.com/questions/97024/how-to-add-the-pdf-bookmark-of-toc-without-its-name-contents-in-toc |
||||
|
\clearpage |
||||
|
\pdfbookmark{\contentsname}{toc} |
||||
|
\tableofcontents \label{toc} |
||||
|
|||||
@ -1,5 +1,5 @@ |
|||||
\section{Στόχος της διπλωματικής} |
\section{Στόχος της διπλωματικής} \label{section:1-4-thesis-goal} |
||||
|
|
||||
Στόχος της παρούσας διπλωματικής εργασίας είναι η δημιουργία μίας αυτόνομης κοινωνικής πλατφόρμας, η οποία, βασιζόμενη σε τεχνολογίες αποκέντρωσης, θα λειτουργεί ανεξάρτητα από κεντρικές αρχές, παρέχοντας στους χρήστες της πλήρη ελευθερία του λόγου και κυριότητα επί των δεδομένων τους. Παράλληλα, θα παρέχει μία πλατφόρμα για ανώνυμες και αυθεντικές ψηφοφορίες, εν δυνάμει ικανών να αποτελέσουν ένα έγκυρο, έμπιστο και άμεσα δημοκρατικό βήμα λήψης αποφάσεων. |
Στόχος της παρούσας διπλωματικής εργασίας είναι η δημιουργία μίας αυτόνομης κοινωνικής πλατφόρμας, η οποία, βασιζόμενη σε τεχνολογίες αποκέντρωσης, θα λειτουργεί ανεξάρτητα από κεντρικές αρχές, παρέχοντας στους χρήστες της πλήρη ελευθερία του λόγου και κυριότητα επί των δεδομένων τους. Παράλληλα, θα παρέχει μία πλατφόρμα για ανώνυμες και αυθεντικές ψηφοφορίες, εν δυνάμει ικανών να αποτελέσουν ένα έγκυρο, έμπιστο και άμεσα δημοκρατικό βήμα λήψης αποφάσεων. |
||||
|
|
||||
Η proof of concept (PoC) εφαρμογή που αναπτύχθηκε για την επίτευξη του παραπάνω στόχου ονομάζεται Condordia\footnote{Η Concordia είναι η θεά της αρχαίας Ρωμαϊκής θρησκείας που προσωποποιεί την ομόνοια. Στην ελληνική μυθολογία ταυτίζεται με τη θεότητα Ομόνοια ή τη θεά Αρμονία.} και λειτουργεί μέσω ενός συνδυασμού αποκεντρωτικών τεχνολογιών. Πιο συγκεκριμένα, στον επεξεργαστικό πυρήνα της και σαν σημείο αναφοράς αξιοποιεί τo Ethereum blockchain, ενώ για την αποθήκευση του μεγαλύτερου όγκου των δεδομένων χρησιμοποιεί το IPFS μέσω της OrbitDB . Η δε διεπαφή του χρήστη υλοποιείται με σύγχρονες μεθόδους web development σε Javascript (React, Redux κ.ά.). |
Η proof of concept (PoC) εφαρμογή που αναπτύχθηκε για την επίτευξη του παραπάνω στόχου ονομάζεται Concordia\footnote{Η Concordia είναι η θεά της αρχαίας Ρωμαϊκής θρησκείας που προσωποποιεί την ομόνοια. Στην ελληνική μυθολογία ταυτίζεται με τη θεότητα Ομόνοια ή τη θεά Αρμονία.} και λειτουργεί μέσω ενός συνδυασμού αποκεντρωτικών τεχνολογιών. Πιο συγκεκριμένα, στον επεξεργαστικό πυρήνα της και σαν σημείο αναφοράς αξιοποιεί τo Ethereum blockchain, ενώ για την αποθήκευση του μεγαλύτερου όγκου των δεδομένων χρησιμοποιεί το IPFS μέσω της OrbitDB . Η δε διεπαφή του χρήστη υλοποιείται με σύγχρονες μεθόδους web development σε Javascript (React, Redux κ.ά.). |
||||
|
|||||
@ -1,9 +1,9 @@ |
|||||
\section{Μεθοδολογία ανάπτυξης} |
\section{Μεθοδολογία της διπλωματικής} |
||||
|
|
||||
Για την επίτευξη των στόχων που ορίστηκαν και την οργάνωση της εργασίας που απαιτείται σε διαχειρίσιμα μέρη, σχεδιάστηκε η χρήση διάφορων εργαλείων και μεθόδων ανάπτυξης λογισμικού, όπως το σύστημα ελέγχου εκδόσεων (version control system) Git και η μέθοδος οργάνωσης Scrum. Τα εργαλεία αυτά είναι δοκιμασμένα και έχουν εδραιωθεί στη σύγχρονη ανάπτυξη λογισμικού. |
Η πάρούσα διπλωματική είχε έμπνευση τις συζητήσεις μας με τον Δημάκη. |
||||
|
|
||||
Το Git είναι δωρεάν λογισμικό ανοιχτού κώδικα το οποίο επιτρέπει και επικουρεί την απρόσκοπτη ανάπτυξη λογισμικού από πολλαπλά μέλη μίας ομάδας, ταυτόχρονα και διανεμημένα. Αυτό επιτυγχάνεται παρέχοντας ένα πλαίσιο από εργαλεία τα οποία βοηθούν την διαχείριση και ενσωμάτωση των διαφορετικών εκδόσεων του κώδικα τις οποίες αναπτύσσει κάθε μέλος της ομάδας ξεχωριστά. Υπάρχουν διάφορα μοντέλα χρήσης του Git και πιο συγκεκριμένα της δυνατότητας που δίνει για δημιουργία, ανάπτυξη και ένωση κλαδιών (branches). Για τους σκοπούς της παρούσας διπλωματικής χρησιμοποιήθηκε το μοντέλο GitHub flow\cite{1.4-github-flow}. Το μοντέλο αυτό ορίζει ότι κάθε προγραμματιστής θα ανοίγει ένα νέο branch για τη ανάπτυξη ενός νέου χαρακτηριστικού της εφαρμογής ή τη διόρθωση ενός μέρους του κώδικα. Έπειτα, όταν η δουλειά έχει ολοκληρωθεί, το branch ενώνεται (merge) με το βασικό branch της εφαρμογής. |
Αρχικά, πραγματοποιήθηκε έρευνα του χώρου των αποκετρωμένων τεχνολογιών με στόχο την κατανόηση των επιπλοκών αυτών των τεχνολογίων τόσο στην ανάπτυξη του κώδικα όσο και στην χρήση.... |
||||
|
|
||||
Το Scrum είναι μία μέθοδος οργάνωσης στην οποία ο επιμελητής του Scrum (Scrum master) διαχωρίζει τα ανεξάρτητα μέρη εργασίας (tasks) που πρέπει να υλοποιηθούν για την ολοκλήρωση των στόχων ενός project. Τα μέρη αυτά περιγράφονται αναλυτικά μαζί με τις απαιτήσεις τους και κατατίθενται σε μία λίστα εργασιών (backlog). Έπειτα, μέσα από συσκέψεις (meetings), επιλέγεται ένας αριθμός από μέρη εργασίας τα οποία θα αποτελέσουν το επόμενο Sprint. Κάθε μέρος εργασίας ανατίθεται σε κάποιο μέλος για υλοποίηση και ορίζεται για το Sprint μία χρονική διάρκεια, στόχος της οποίας είναι η περάτωση όλων των μερών εργασίας πριν τη λήξη της. Στο τέλος προθεσμίας που ορίστηκε για το Sprint τα μέλη της ομάδας αποτιμούν τα αποτελέσματα και ορίζουν το επόμενο Sprint. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί. |
Στα πρώτα στάδια της έρευνας εξοικειωθήκαμε με τον χώρο .... |
||||
|
|
||||
Μέσα από την χρήση των παραπάνω εργαλείων επιτυγχάνεται η ομαλή συνεργασία στην ανάπτυξη του λογισμικού. Κάθε μέλος της ομάδας δύναται να εργαστεί ανεξάρτητα και χωρίς την ανάγκη διαρκούς επικοινωνίας με τα υπόλοιπα μέλη. Οι στόχοι είναι ορισμένοι, σαφείς και χωρισμένοι σε διαχειρίσιμα μέρη τα οποία δεν καταβάλουν τα μέλη. Ταυτόχρονα, έχοντας ως έδρα καθιερωμένα πρότυπα ανάπτυξης, παρέχεται φορμαλισμός και έτοιμες μέθοδοι επίλυσης προβλημάτων, γεγονός που λειτουργεί καταλυτικά και βοηθά στην αποφυγή τελμάτων κατά τη συγγραφή του κώδικα. |
Έπειτα, έγιναν μερικές πρώτες προσπάθειες για τη δημιουργία ενός proof of concept application... |
||||
|
|||||
@ -1,3 +1,11 @@ |
|||||
\section{Οργάνωση κεφαλαίων} |
\section{Οργάνωση κεφαλαίων} |
||||
|
|
||||
Στο δεύτερο κεφάλαιο γίνεται παρουσίαση του θεωρητικού υπόβαθρου... |
Η παρούσα διπλωματική εργασία οργανώνεται σε κεφάλαια, ενότητες και υποενότητες, όπως αυτά παρατίθενται στα \hyperref[toc]{Περιεχόμενα}. Πιο συγκεκριμένα: |
||||
|
|
||||
|
\begin{itemize} |
||||
|
\item Στο \hyperref[chapter:1-introduction]{\textbf{Κεφάλαιο 1}} |
||||
|
\item Στο \hyperref[chapter:2-theoretical-background]{\textbf{Κεφάλαιο 2}} |
||||
|
\item Στο \hyperref[chapter:3-application-design]{\textbf{Κεφάλαιο 3}} |
||||
|
\item Στο \hyperref[chapter:4-application-implementation]{\textbf{Κεφάλαιο 4}} |
||||
|
\item Στο \hyperref[chapter:5-conclusions]{\textbf{Κεφάλαιο 5}} |
||||
|
\end{itemize} |
||||
@ -1,8 +1,10 @@ |
|||||
\chapter{Σχεδίαση εφαρμογής} |
\chapter{Σχεδίαση εφαρμογής}\label{chapter:3-application-design} |
||||
|
|
||||
\input{chapters/3.application-design/3.1.application-parts} |
\input{chapters/3.application-design/3.1.idea-conception} |
||||
\input{chapters/3.application-design/3.2.user-categories} |
\input{chapters/3.application-design/3.2.technology-stack} |
||||
\input{chapters/3.application-design/3.3.use-cases} |
\input{chapters/3.application-design/3.3.design-methodology} |
||||
\input{chapters/3.application-design/3.4.technology-stack} |
\input{chapters/3.application-design/3.4.user-categories} |
||||
\input{chapters/3.application-design/3.5.implementation-methodology-specification} |
\input{chapters/3.application-design/3.5.software-requirements} |
||||
\input{chapters/3.application-design/3.6.architecture.design} |
\input{chapters/3.application-design/3.6.use-cases} |
||||
|
\input{chapters/3.application-design/3.7.architecture-design} |
||||
|
\input{chapters/3.application-design/3.8.implementation-methodology-specification} |
||||
|
|||||
@ -1,19 +0,0 @@ |
|||||
\section{Λογικά μέρη} |
|
||||
|
|
||||
% Παλιό από Drive |
|
||||
Η πλατφόρμα μπορεί να διαχωριστεί σε δύο λογικά μέρη: |
|
||||
|
|
||||
1) Το πρώτο μέρος αποτελεί μία αυτοτελή και πλήρως αποκεντρωτική πλατφόρμα που στόχος της είναι να παρέχει τη δυνατότητα ελευθερίας λόγου απρόσβλητου σε λογοκρισία και διαγραφή από κεντρικές οντότητες εξουσίας. Στην ουσία εδώ θα μπορεί - σε μια απλοποιημένη εκδοχή - οποιοσδήποτε να δημιουργήσει topics ή να απαντήσει σε άλλα. Επεξεργαστικός πυρήνας θα είναι ένα smart contract το οποίο θα δέχεται από τους χρήστες transactions και θα τα εγγράφει στο Storage Layer: |
|
||||
|
|
||||
% TODO: insert diagram |
|
||||
|
|
||||
Το μειονέκτημα αυτού του κομματιού είναι πως για να λειτουργήσει απαιτεί για κάθε \textenglish{transaction} οι χρήστες να καταβάλουν κάποιο τέλος για τα fees. Αν και υπάρχουν σχέδια από την ομάδα ανάπτυξης του Ethereum για τη μείωσή τους στο μέλλον (έως και 10-2), τα fees στη χρήση της EVM θα είναι αναπόφευκτα. Ωστόσο θα πρέπει να σημειωθεί ότι αφενός παρέχουν μια μορφή προστασίας απέναντι σε κακόβουλους χρήστες που θα πλημμύριζαν την εφαρμογή με ανεπιθύμητο ποσοτικά/ποιοτικά περιεχόμενο (θα τους ήταν οικονομικά ασύμφορη μια τέτοια επίθεση), αφετέρου υπάρχουν κάποια workarounds για να μειωθεί δραστικά η εμπλοκή του χρήστη με την καταβολή τελών, κάτι που περιγράφεται παρακάτω στις κατηγορίες χρηστών. Τα παραπάνω πρακτικά σημαίνουν ότι το Smart Contract θα πρέπει ανά διαστήματα να φορτίζεται (από οποιονδήποτε) με Ethereum ή οι χρήστες (βλ. κατηγορίες χρηστών) να καταβάλουν τα δικά τους έξοδα. |
|
||||
|
|
||||
2) Το δεύτερο μέρος αποτελεί μια μερικώς αποκεντρωτική και μη αυτοτελή πλατφόρμα που έρχεται να λειτουργήσει επιπρόσθετα στην πρώτη. Το κομμάτι αυτό απευθύνεται αποκλειστικά σε επικυρωμένα μέλη του ΑΠΘ και συνιστά ένα αμεσοδημοκρατικό σύστημα ψηφοφορίας που θα εγγυάται σε υψηλό βαθμό την εγκυρότητα και την ανωνυμία των διαδικασιών του. Με λίγα λόγια, θα δημιουργούνται θέματα προς ψηφοφορία (στο πρώτο κομμάτι), πάνω στα οποία θα ψηφίζουν όσοι έχουν το δικαίωμα (αυτοί θα ορίζονται με την κατοχή ενός ανάλογου token στο Ethereum). |
|
||||
|
|
||||
% TODO: insert diagram |
|
||||
|
|
||||
O χρήστης μέσω ενός Frontend (μιας κλασικής ιστοσελίδας ουσιαστικά) θα μπορεί να πιστοποιήσει μέσω login στο it.auth.gr* την ακαδημαϊκή του ταυτότητα. Στη συνέχεια το TDS (Token Distribution Service, ελέγχοντας το admin account των tokens θα παρέχει στο χρήστη δύο tokens. Ένα το οποίο θα του δίνει voting rights (verified user) και ένα που θα κάνει τη πλατφόρμα να του επιστρέφει τα τέλη τα οποία πληρώνουν σε κάθε post τους (trusted user). |
|
||||
|
|
||||
|
|
||||
*Ιδανικά, με τη συνεργασία του ΑΠΘ, το UAS θα αποτελεί υπηρεσία συνεργαζόμενη με την Υποδομή πιστοποίησης και εξουσιοδότησης (βλ. https://it.auth.gr/el/infrastructure/aai). Αυτό σημαίνει ότι οι χρήστες δε θα χρειάζεται να εμπιστευτούν τον UAS με τα it credential τους. |
|
||||
@ -0,0 +1,11 @@ |
|||||
|
\section{Σύλληψη της ιδέας} \label{section:3-1-idea-conception} |
||||
|
|
||||
|
Η σύλληψη της ιδέας για τη δημιουργία της εφαρμογής της παρούσας διπλωματικής εργασίας είχε ως εφαλτήριο την αναγνώριση ενός διδιάστατου προβλήματος. |
||||
|
|
||||
|
Η πρώτη διάσταση εστιάζει στον χώρο των μέσων κοινωνικής δικτύωσης. Εκεί παρατηρείται αδιαμφισβήτη επικράτηση πλατφορμών επικοινωνίας συγκεντρωτικής μορφής (π.χ. Facebook, Twitter, Instagram), ενώ προσπάθειες δηιουργίας αντίστοιχων αποκεντρωτικών εφαρμογών βρίσκονται σε πρώιμα στάδια, τόσο ανάπτυξης, όσο και υιοθέτησης από το ευρύ κοινό. Όπως αναλύθηκε και στην ενότητα \ref{section:1-3-problem-definition}, η τρέχουσα αυτή κατάσταση θέτει αξιοσημείωτα προβλήματα τεχνικής φύσεως (έλλεψη ασφάλειας και διαθεσιμότητας) και, κυρίως, πολιτικής (έλλειψη εμπιστοσύνης, εγγύησης της αυθεντικότητας των δεδομένων και της ελευθερίας του λόγου). |
||||
|
|
||||
|
Η δεύτερη διάσταση εστιάζει στον χώρο της ψηφιακής δημοκρατίας (digital democracy). Συγκεκριμένα, παρατηρείται έλλειψη εργαλείων, ικανών να παρέχουν τη δυνατότητα διενέργειας αυθεντικών δημοκρατικών διαδικασιών. Ψηφοφορίες και αυτοδιαχείριση εντός συστημάτων κεντροποιημένης λογικής αδυνατούν, για αρχιτεκτονικούς λόγους, να εξασφαλίσουν τις απαραίτητες θεμελιώδεις ιδιότητες τέτοιων διαδικασιών, δηλαδή της ανωνυμίας και της επαληθευσιμότητας. |
||||
|
|
||||
|
Βάσει των παραπάνω, γεννήθηκε η ιδέα δημιουργίας μίας εφαρμογής, η οποία, μέσω ενός προτεινόμενου συνδυασμού αποκεντρωτικών τεχνολογιών, να ορίσει έναν ψηφιακό χώρο που θα έρθει αντιμέτωπος με τα παραπάνω. Έτσι, κεντρικός στόχος της πιλοτικής εφαρμογής Concordia, είναι να αποτελέσει μία αυτόνομη κοινωνική πλατφόρμα, που θα κατοχυρώνει στους χρήστες της ελευθερία του λόγου και πλήρη κυριότητα επί των δεδομένων τους. Επιπλέον, θα παρέχει τη δυνατότητα διενέργειας αυθεντικών, ανώνυμων ψηφοφοριών, κάτι που θα την καθιστά ένα αξιόπιστο δημοκρατικό βήμα για τη λήψη αποφάσεων εντός αυτοδιαχειριζόμενων κοινοτήτων της. |
||||
|
|
||||
|
\newpage |
||||
@ -0,0 +1,20 @@ |
|||||
|
\section{Τεχνολογική στοίβα} \label{section:3-2-technology-stack} |
||||
|
|
||||
|
Ξεκινώντας τη σχεδίαση της πλατφόρμας, πραγματοποιήθηκε έρευνα για την επιλογή της τεχνολογικής της στοίβας (technology stack). Αυτή αποφασίστηκε να ακολουθήσει μία προσαρμοσμένη για τα δεδομένα μορφή τριμερούς διάταξης\footnote{Η τριμερής διάταξη (three-tier architecture) διαχωρίζει μία εφαρμογή σε τρία ανεξάρτητα λειτουργικά επίπεδα και αποτελεί την κυρίαρχη επιλογή για διατάξεις παραδοσιακών εφαρμογών πελάτη-εξυπηρετητή.} και να χωριστεί σε τρία λογικά επίπεδα (tiers): |
||||
|
|
||||
|
\begin{enumerate} |
||||
|
\item \textbf{Presentation tier}: Αποτελεί τη διεπαφή του χρήστη (user interface ή UI), μέσω της οποίας ο τελευταίος αλληλεπιδρά με την εφαρμογή. Για την εκπλήρωση των προδιαγραφών, το μοναδικό απαραίτητο χαρακτηριστικό αυτού του τμήματος είναι να μπορεί να εκτελείται αυτούσιο από τη συσκευή του τελικού χρήστη, δηλαδή να μην απαιτείται η ύπαρξη κάποιου εξυπηρετητή για τη λειτουργία του. Λαμβάνοντας, επιπροσθέτως, υπόψιν τις ανάγκες και τους περιορισμούς των λογισμικών των άλλων δύο επιπέδων, το παρόν κομμάτι αποφασίστηκε να σχεδιαστεί ως μία client-side web application σε HTML/CSS/JS. |
||||
|
|
||||
|
\item \textbf{Application tier}: Πρόκειται για το επίπεδο που πραγματοποιεί την επεξεργασία (\textenglish{processing}) της εφαρμογης. Εδώ επιλέχθηκαν το blockchain και τα smart contracts, καθώς τα πλεονεκτήματά τους, όπως αυτά περιγράφηκαν στο κεφάλαιο \ref{chapter:2-theoretical-background}, αρμόζουν απόλυτα με τις ιδιαίτερες απαιτήσεις της εφαρμογής. Συγκεκριμένα, επιλέχθηκε η πλατφόρμα του Ethereum, καθώς αποτελεί τον πρωτοπόρο στο χώρο, διαθέτοντας την ισχυρότερη κοινότητα και την δυνατότητα δημιουργίας πλήρως λειτουργικών εφαρμογών. |
||||
|
|
||||
|
\item \textbf{Data tier}: Το τμήμα αυτό είναι υπεύθυνο για την αποθήκευση του κύριου όγκου των δεδομένων (storage). Για την επίτευξη πλήρους αρχιτεκτονικής αποκέντρωσης των δεδομένων επιλέχθηκε το IPFS (βλ. ενότητα \ref{section:2-7-ipfs}), το οποίο διανέμει το περιεχόμενο της εφαρμογής στους peers που συμμετέχουν σε αυτήν, χωρίς να απαιτεί κάποιο κεντρικό σημείο. Έτσι, κάθε χρήστης θα έχει πλήρη κυριότητα επί των δεδομένων του, ενώ, επιπλέον, θα συμμετέχει στην πλατφόρμα διαμοιράζοντας τα δεδομένα άλλων χρηστών. |
||||
|
\end{enumerate} |
||||
|
|
||||
|
Τελικά, με τη διασύνδεση των προαναφερθέντων τεχνολογιών, προκύπτει σχηματικά η ακόλουθη διάταξη: |
||||
|
|
||||
|
% TODO: Create proper diagram |
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.75\textwidth]{assets/figures/chapter-3/3.2.technology.stack} |
||||
|
\caption{Τεχνολογική στοίβα} |
||||
|
\end{figure} |
||||
@ -1,34 +0,0 @@ |
|||||
\section{Κατηγορίες χρηστών} |
|
||||
|
|
||||
% Παλιό από Drive |
|
||||
\subsection{Πρώτο μέρος} |
|
||||
|
|
||||
Όπως προειπώθηκε, το πρώτο μέρος της πλατφόρμας θα είναι ανοιχτό σε όλους. Ωστόσο, οι χρήστες του μπορούν να διακριθούν στις εξής δύο κατηγορίες: |
|
||||
|
|
||||
\begin{itemize} |
|
||||
\item Έμπιστα μέλη του δικτύου (trusted users) |
|
||||
\item Μη έμπιστα μέλη (untrusted users) |
|
||||
\end{itemize} |
|
||||
|
|
||||
Βασική διαφορά των δύο κατηγοριών είναι πως ενώ οι trusted users θα αποζημιώνονται αυτόματα από το (ενν. φορτισμένο) smart contract και άρα θα είναι απαλλαγμένοι από τέλη, οι δεύτεροι θα πρέπει να καταβάλουν μόνοι τους τα τέλη τους (fees) για κάθε ενέργεια (π.χ. posting). |
|
||||
|
|
||||
Η εμπιστοσύνη ενός χρήστη (trust) μπορεί να οριστεί ως ένας ακέραιος αριθμός με κάποιο κατώφλι, πάνω από το οποίο ο χρήστης θα θεωρείται trusted. Το trust θα μπορεί να αυξομειώνεται ανά πάσα στιγμή, με τους χρήστες να δίνουν και να παίρνουν βαθμούς trust σε/από άλλους. |
|
||||
|
|
||||
Αξίζει να σημειωθεί επίσης ότι επειδή όλες οι συναλλαγές καταγράφονται, είναι δυνατό να υπολογιστεί το συνολικό ποσό του Ethereum που έχει ξοδέψει ένας common user μέχρι να γίνει trusted και έτσι μπορεί σταδιακά να του επιστραφεί μέσω του contract. Αυτό δίνει κίνητρο στους χρήστες να διατηρούν σωστή συμπεριφορά και να συμβάλλουν θετικά στην πλατφόρμα. |
|
||||
|
|
||||
\subsection{Δεύτερο μέρος} |
|
||||
|
|
||||
Για το δεύτερο μέρος της πλατφόρμας, οι χρήστες του μπορούν να διακριθούν στις εξής κατηγορίες: |
|
||||
|
|
||||
\begin{itemize} |
|
||||
\item Πιστοποιημένα μέλη του Α.Π.Θ. (verified users) |
|
||||
\item Μη πιστοποιημένα μέλη του Α.Π.Θ. (untrusted users) |
|
||||
\end{itemize} |
|
||||
|
|
||||
Σχετικά με το δικαίωμα ψήφου για αυθεντικές δημοκρατικές αποφάσεις σχετικές με το ΑΠΘ, αυτό θα το έχουν μόνο οι verified χρήστες του δικτύου. Οι verified χρήστες θα μπορούν επιπλέον να αλληλεπιδρούν με την πλατφόρμα εξαρχής χωρίς την καταβολή τελών (θα ξεκινάνε ως trusted), πράγμα που βέβαια δε σημαίνει ότι χάνοντας trust δε θα μπορούν να χάσουν αυτό το προνόμιο. |
|
||||
|
|
||||
\subsection{Σύνοψη χρηστών} |
|
||||
|
|
||||
Συμπερασματικά προκύπτουν τέσσερις διακριτές κατηγορίες χρηστών με ξεχωριστά δικαιώματα που φαίνονται στο παρακάτω διάγραμμα: |
|
||||
|
|
||||
% TODO: insert diagram |
|
||||
@ -0,0 +1,3 @@ |
|||||
|
\section{Μεθολογία σχεδίασης} \label{section:3-3.design-methodology} |
||||
|
|
||||
|
% TODO: add Agile stuff etc |
||||
@ -1 +0,0 @@ |
|||||
\section{Σενάρια χρήσης} |
|
||||
@ -1,54 +0,0 @@ |
|||||
\section{Τεχνολογίες} |
|
||||
|
|
||||
\subsection{Ethereum} |
|
||||
|
|
||||
Ξεκινώντας την σχεδίαση της πλατφόρμας πραγματοποιήσαμε έρευνα ώστε να ανακαλύψουμε τις πιθανές επιλογές για το κομμάτι της διανεμημένης επεξεργασίας (\textenglish{distributed computing}). Αναλογιστήκαμε τα προτερήματα και μειονεκτήματα διάφορων επιλογών, συμπεριλαμβανομένων των ... |
|
||||
|
|
||||
Επιλέξαμε να προχωρήσουμε με το Ethereum και όχι κάποια άλλη πλατφόρμα επειδή ... |
|
||||
|
|
||||
Το Ethereum είναι ... |
|
||||
Παρέχει Smart Contracts ακολουθώντας το μοντέλο ... |
|
||||
Proof of work είναι ... |
|
||||
Ο τρόπος που υπολογίζεται και πληρώνεται η καταναλώμενη επεξεργαστική ισχύς είναι ... |
|
||||
Αυτά εισάγουν τους εξής περιορισμούς που πρέπει να ληφθούν υπόψιν κατά την υλοποίηση ... |
|
||||
|
|
||||
% Παλιό από Drive |
|
||||
Προχωρώντας την τεχνολογία του blockchain ένα βήμα παραπέρα, ξεκίνησαν να δημιουργούνται προγραμματιστικές πλατφόρμες για την ανάπτυξη αποκεντρωτικών εφαρμογών (\textenglish{Decentralized Applications} ή DApps). Η πρώτη και, μέχρι τώρα, πιο δημοφιλής, ισχυρή και λειτουργική πλατφόρμα είναι το Ethereum. |
|
||||
|
|
||||
Στο Ethereum υπάρχουν δύο είδη λογαριασμών: οι Externally Owned Accounts και οι \textenglish{Contracts Accounts}. Η διαφορά τους είναι ότι ενώ οι πρώτοι ελέγχονται από τους χρήστες, οι δεύτεροι διαθέτουν ένα αμετάβλητο (immutable) κομμάτι κώδικα το οποίο αποτελεί ένα \textenglish{Smart Contract}. Όταν μια συναλλαγή σταλεί σε ένα Smart Contract, ο συσχετιζόμενος κώδικας εκτελείται από την “Ethereum Virtual Machine (EVM)” σε κάθε κόμβο (και εν τέλει όλοι έρχονται σε consensus). Φυσικά, για την εκτέλεση των operations στην EVM (όπως και για τα απλά \textenglish{transactions}) χρειάζεται να δοθούν κάποια fees στους miners ως ανταμοιβή για την εργασία τους. |
|
||||
|
|
||||
|
|
||||
\subsection{IPFS, OrbitDB} |
|
||||
|
|
||||
Όπως η επιλογή του Blockchain, που περιγράφηκε στο προηγούμενο κεφάλαιο (\textenglish{insert reference}), ομοίως και η επιλογή του λογισμικού που θα χρησιμοποιηθεί για την κατανεμημένη αποθήκευση δεδομένων ξεκίνησε με μία έρευνα των επιλογών που υπάρχουν. Αναλογιστήκαμε τα προτερήματα και μειονεκτήματα διάφορων επιλογών, συμπεριλαμβανομένων των ... |
|
||||
|
|
||||
Επιλέξαμε να προχωρήσουμε με το IPFS και την OrbitDB έναντι άλλων λύσεων επειδή ... |
|
||||
|
|
||||
Το IPFS είναι ... |
|
||||
Παρέχει ... με τον εξής τρόπο ... |
|
||||
Δωρεάν ... |
|
||||
Αυτά τα χαρακτηριστικά εισάγουν τους εξής περιορισμούς που πρέπει να ληφθούν υπόψιν κατά την υλοποίηση ... |
|
||||
|
|
||||
Η OrbitDB είναι ... και χρησιμοποιεί το IPFS για να καταφέρει τα εξής χαρακτηριστικά ... |
|
||||
Περιορισμοί πάλι κλπ ... |
|
||||
|
|
||||
% Παλιό από Drive |
|
||||
Ένα από τα προβλήματα που προκύπτουν με την αποκέντρωση εφαρμογών είναι αυτό της εύρεσης των resources που χρειαζόμαστε. Το πρόβλημα έγκειται στο γεγονός ότι δεν υπάρχει ένας server και άρα μία μοναδική διεύθυνση IP από την οποία μπορούμε να πάρουμε το αντικείμενο που ψάχνουμε, διότι όλα είναι διανεμημένα στο δίκτυο. Επιπλέον η αποθήκευση μεγάλου όγκου πληροφοριών στο Ethereum on-chain έχει απαγορευτικά μεγάλο κόστος οπότε απορρίπτεται. |
|
||||
|
|
||||
Το πρόβλημα ανάγεται σε αυτό της επικοινωνίας μεταξύ των κόμβων. Αν καθοριστεί ένα πρότυπο επικοινωνίας μεταξύ των κόμβων τότε τα αντικείμενα μπορούν να βρεθούν ζητώντας τα από τους γειτονικούς κόμβους, οι οποίοι με τη σειρά τους θα τα ζητήσουν από τους δικούς τους γείτονες και ου το κάθε εξής, μέχρι το αντικείμενο να βρεθεί και να σταλεί στον κόμβο που αρχικά το ζήτησε. |
|
||||
|
|
||||
Το IPFS είναι ένα νέο πρωτόκολλο μεταφοράς υπερκειμένου που βρίσκεται ακόμα υπό ανάπτυξη. Όπως το γνωστό πρωτόκολλο HTTP, για συγκεντρωτικά συστήματα, έτσι και το IPFS, για αποκεντρωτικά συστήματα, καθορίζει το πρότυπο το οποίο θα χρησιμοποιούν τα τερματικά του δικτύου για να επικοινωνούν μεταξύ τους. Χρησιμοποιεί κρυπτογραφικές τεχνικές, όπως αυτές που είδαμε παραπάνω, καθώς και διάφορες άλλες τεχνολογίες για να: |
|
||||
|
|
||||
\begin{itemize} |
|
||||
\item συντονίσει τη παράδοση περιεχομένου |
|
||||
\item υλοποιήσει στρώμα σύνδεσης μέσω οποιουδήποτε πρωτοκόλλου δικτύου |
|
||||
\item ορίσει ένα σύστημα ονομάτων τομέων (DNS) |
|
||||
\item υλοποιήσει στρώμα δρομολόγησης |
|
||||
\item διαμοιράσει αρχεία με peer-to-peer (P2P) τεχνικές |
|
||||
\end{itemize} |
|
||||
|
|
||||
Έτσι το IPFS ορίζει ένα νέο δίκτυο υπολογιστών που συμπληρώνει τα ήδη υπάρχοντα (www, Tor, .bit) διατηρώντας πλήρως αποκεντρωμένη αρχιτεκτονική και κανένα κεντρικό σημείο αποτυχίας. |
|
||||
|
|
||||
Συνοπτικά, δηλαδή, στο IPFS αποθηκεύονται διευθυνσιοδοτημένα βάσει περιεχομένου (\textenglish{content addressable}) αρχεία, τα οποία ανακτώνται βάσει του hash των περιεχομένων τους (αντί για την τοποθεσία τους), ενώ ανακαλύπτονται και διαμοιράζονται μέσω του παρεχόμενου P2P network layer. Αξίζει, ωστόσο, να σημειωθεί πως το layer αυτό δεν εγγυάται από μόνο του το hosting των αρχείων και το διαθέσιμο bandwidth για την ανάκτηση τους, πράγμα που σημαίνει ότι θα πρέπει να γίνει παροχή υποδομής από τους χρήστες ικανής να υποστηρίξει έναν ελάχιστο αριθμό κόμβων αποθήκευσης. |
|
||||
|
|
||||
Πρόκειται για συμπληρωματικές τεχνολογίες στις παραπάνω που στόχο έχουν την οργάνωση των αποθηκευμένων πληροφοριών σε μορφή βάσεων δεδομένων. |
|
||||
@ -0,0 +1,48 @@ |
|||||
|
\section{Κατηγορίες χρηστών} \label{section:3-4-user-categories} |
||||
|
|
||||
|
Οι χρήστες (actors) της πλατφόρμας χωρίζονται σε πρωτεύοντες ή ενεργούς και δευτερεύοντες ή παθητικούς. Πρωτεύοντες χρήστες είναι εκείνοι που εκκινούν διεργασίες στο σύστημα. Δευτερεύοντες είναι οι χρήστες με τους οποίους αλληλεπιδρά το σύστημα, αλλά οι ίδιοι δεν εκκινούν διεργασίες σε αυτό. Συνολικά οι χρήστες που συμμετέχουν στο σύστημα είναι οι: |
||||
|
|
||||
|
\begin{itemize} |
||||
|
\item Επισκέπτες |
||||
|
\item Εγγεγραμμένα μέλη |
||||
|
\item Δημιουργοί κοινοτήτων %TODO: Έχει νόημα σαν ρόλος ή μπορεί να είναι απλά "εγγεγραμμένο μέλος"; |
||||
|
\item Συμβόλαια κοινοτήτων |
||||
|
\end{itemize} |
||||
|
|
||||
|
\subsection{Ενεργοί χρήστες} |
||||
|
|
||||
|
Οι ενεργοί χρήστες στο σύστημα είναι οι επισκέπτες, τα εγγεγραμμένα μέλη και οι δημιουργοί κοινοτήτων. |
||||
|
|
||||
|
Όλοι οι χρήστες στο σύστημα είναι αρχικά επισκέπτες. Οι επισκέπτες έχουν τη δυνατότητα να βλέπουν το περιεχόμενο της κοινότητας, αλλά δε μπορούν να συμμετέχουν δημιουργώντας νέο περιεχόμενο (δημοσιεύοντας νέα θέματα ή μηνύματα). Επίσης, δε μπορούν να συμμετέχουν στις ψηφοφορίες της κοινότητας ή να ψηφίσουν τα μηνύματα. |
||||
|
|
||||
|
Όταν ένας επισκέπτης εγγράφεται στο σύστημα, αποκτά έναν μοναδικό, αύξοντα αριθμό χρήστη και αποτελεί πλέον εγγεγραμμένο μέλος της κοινότητας. Τα εγγεγραμμένα μέλη έχουν τα δικαιώματα των επισκεπτών και μπορούν επιπλέον να προσθέσουν περιεχόμενο στην πλατφόρμα μέσω της δημιουργίας νέων θεμάτων, της δημοσίευσης μηνυμάτων και της ψήφισης στις ψηφοφορίες στις οποίες έχουν δικαίωμα. |
||||
|
|
||||
|
Οι δημιουργοί κοινοτήτων είναι οι χρήστες οι οποίοι χρησιμοποιούν την δυνατότητα του συστήματος να δημιουργήσει κοινότητες, τα μέλη των οποίων διαφοροποιούνται βάσει ενός εξωτερικού token. Το token που ορίζει τα μέλη μίας κοινότητας προέρχεται από ένα έξυπνο συμβόλαιο το οποίο ορίζεται κατά τη δημιουργία της κοινότητας. Οι δημιουργοί κοινοτήτων πρέπει να είναι εγγεγραμμένα μέλη της κοινότητας. Ένας δημιουργός κοινότητας δεν έχει παραπάνω δικαιώματα από αυτά των απλών εγγεγραμμένων χρηστών. |
||||
|
|
||||
|
\subsection{Παθητικοί χρήστες} |
||||
|
|
||||
|
Παθητικοί χρήστες τους συστήματος είναι τα συμβόλαια των κοινοτήτων. Τα συμβόλαια αυτά δεν εκκινούν διεργασίες στο σύστημα και δεν αλληλεπιδρούν με αυτό άμεσα. Αποτελούν αυτόνομες εξωτερικές οντότητες, οι οποίες ορίζουν τους χρήστες κοινοτήτων μέσω της διάθεσης αναγνωριστικών token στα μέλη τους. Συγκεκριμένα, μέσω του διαμοιρασμού των token, καθορίζουν ποιοι χρήστες της πλατφόρμας έχουν δικαίωμα ψήφου στις ψηφοφορίες που αφορούν την κοινότητα. |
||||
|
|
||||
|
\subsection{Σύνοψη χρηστών} |
||||
|
|
||||
|
Συμπερασματικά προκύπτουν τρεις διακριτές κατηγορίες ενεργών χρηστών με ξεχωριστά δικαιώματα όπως φαίνεται στο παρακάτω σχήμα: |
||||
|
|
||||
|
\begin{threeparttable}[H] |
||||
|
\begin{center} |
||||
|
\begin{tabularx}{\textwidth}{p{2.3cm} X X X X X X X X X} |
||||
|
\toprule |
||||
|
\multirow{7}{2.3cm}{Κατηγορία χρήστη} &\multicolumn{9}{c}{Δικαιώματα} \\ [0.5ex] |
||||
|
& \spheading{70}{6em}{Προβολή θεμάτων} & \spheading{70}{8em}{Προβολή μηνυμάτων} & \spheading{70}{8em}{Προβολή ψηφοφοριών} & \spheading{70}{8em}{Προβολή ψήφων μηνυμάτων} & \spheading{70}{8em}{Δημιουργία θεμάτων} & \spheading{70}{8em}{Δημιουργία μηνυμάτων} & \spheading{70}{8em}{Δημιουργία ψηφοφοριών} & \spheading{70}{8em}{Ψήφιση σε ψηφοφορίες} & \spheading{70}{8em}{Ψήφιση μηνυμάτων} \\ [0.5ex] |
||||
|
\midrule |
||||
|
Επισκέπτες & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{red}{\faIcon{times}} & \textcolor{red}{\faIcon{times}} & \textcolor{red}{\faIcon{times}} & \textcolor{red}{\faIcon{times}} & \textcolor{red}{\faIcon{times}} \\ [0.5ex] |
||||
|
Εγγεγραμμένα μέλη & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}}\tnote{*} & \textcolor{OliveGreen}{\faIcon{check}}\tnote{*} & \textcolor{OliveGreen}{\faIcon{check}} \\ [0.5ex] |
||||
|
Δημιουργοί κοινοτήτων & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}} & \textcolor{OliveGreen}{\faIcon{check}}\tnote{*} & \textcolor{OliveGreen}{\faIcon{check}}\tnote{*} & \textcolor{OliveGreen}{\faIcon{check}} \\ [0.5ex] |
||||
|
\bottomrule |
||||
|
\end{tabularx} |
||||
|
\begin{tablenotes} |
||||
|
\item[*] \footnotesize{Μόνο στις υποκοινότητες στις οποίες κατέχει το αντίστοιχο token και σε αυτές οι οποίες δεν έχουν ορισμένο token.} |
||||
|
\end{tablenotes} |
||||
|
\end{center} |
||||
|
\caption{Δικαιώματα χρήσης ανά κατηγορία χρήστη} |
||||
|
\label{table:3-4-user-category-permissions} |
||||
|
\end{threeparttable} |
||||
@ -1,38 +0,0 @@ |
|||||
\section{Προδιαγραφή μεθόδου υλοποίησης και χρονοπρογραμματισμός} |
|
||||
|
|
||||
\subsection{Προδιαγραφή κύκλων} |
|
||||
|
|
||||
Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται ως εξής: |
|
||||
|
|
||||
% TODO: insert diagram |
|
||||
|
|
||||
\subsection{Πρώτη φάση} |
|
||||
|
|
||||
% Παλιό από Drive |
|
||||
Στήνεται ένα Ethereum Private Network ως βάση πάνω στην οποία θα δουλέψουμε. Πάνω σε αυτό γράφουμε τα contracts που θα είναι υπεύθυνα για διεκπεραίωση ή μη των posts. |
|
||||
Στη συνέχεια αναπτύσσεται ο απαραίτητος κώδικας που υλοποιεί το posting χρησιμοποιώντας τις βιβλιοθήκες που δίνονται από το IPFS για την επικοινωνία μεταξύ των κόμβων του δικτύου και αυτές που δίνονται από τη BigChainDB για την αποθήκευση των πληροφοριών με διανεμημένο τρόπο. |
|
||||
Γίνονται δοκιμές για την εξακρίβωση της σωστής λειτουργίας του αποτελέσματος και διορθώνονται τυχόν λάθη στο κώδικα. |
|
||||
|
|
||||
\subsection{Δεύτερη φάση} |
|
||||
|
|
||||
% Παλιό από Drive |
|
||||
Υλοποιείται το δικαίωμα ψήφου και posting χωρίς fees. Αυτό γίνεται μέσω δύο contracts που θα δημιουργούν δύο διαφορετικά tokens (voting token, feeless token) και θα τα αποδίδουν στον εκάστοτε χρήστη που πρέπει να πάρει το δικαίωμα. |
|
||||
Αναπτύσσεται κώδικας που να υλοποιεί τη διαδικασία ψηφοφορίας. |
|
||||
Γίνονται δοκιμές για την εξακρίβωση της σωστής λειτουργίας του αποτελέσματος και διορθώνονται τυχόν λάθη στο κώδικα. Σε αυτή τη φάση η απόδοση των tokens θα γίνει χειροκίνητα για το σκοπό της δοκιμής. |
|
||||
|
|
||||
\subsection{Τρίτη φάση} |
|
||||
|
|
||||
% Παλιό από Drive |
|
||||
Υλοποιείται ένα σύστημα απόδοσης εμπιστοσύνης (ΣΑΠ). |
|
||||
Αναπτύσσονται τα contracts που είναι απαραίτητα για τη λειτουργία του ΣΑΠ καθώς και για την αυτόματη απόδοση feeless token στους trusted χρήστες. |
|
||||
Γίνονται δοκιμές για την εξακρίβωση της σωστής λειτουργίας του αποτελέσματος και διορθώνονται τυχόν λάθη στο κώδικα. |
|
||||
Εφόσον η εφαρμογή περάσει το στάδιο των δοκιμών είναι έτοιμη για alpha deployment, είναι δηλαδή έτοιμη για χρήση από το κοινό, υπολείπονται όμως χαρακτηριστικά που είναι ιδιαίτερα θεμιτά αλλά όχι απαραίτητα για τη λειτουργία. |
|
||||
|
|
||||
\subsection{Τέταρτη φάση} |
|
||||
|
|
||||
% Παλιό από Drive |
|
||||
Αναπτύσσεται ο κώδικας του (μοναδικού) συγκεντρωτικού τμήματος του συστήματος το οποίο ανήκει στο δεύτερο κομμάτι - του UAS: Έτσι αυτοματοποιείται η διαδικασία απόδοσης των token, που στην προηγούμενη φάση έγινε χειροκίνητα. |
|
||||
Γίνονται δοκιμές για την εξακρίβωση της σωστής λειτουργίας του αποτελέσματος και διορθώνονται τυχόν λάθη στο κώδικα. |
|
||||
Εφόσον η εφαρμογή περάσει το στάδιο των δοκιμών είναι έτοιμη για ένα beta deployment, ώστε να γίνει πιο ευρύς έλεγχος από μία ομάδα δοκιμών και να παρθεί feedback για την εμπειρία χρήστη. |
|
||||
|
|
||||
Για το τελικό deployment θα μπορούσε να τεθεί ως στόχος η κατά το δυνατόν μείωση των τελών για τη λειτουργία της πλατφόρμας, ανεπτυγμένα χαρακτηριστικά επικοινωνίας όπως δόμηση των συζητήσεων σε κατηγορίες, προφίλ χρηστών και άλλα χαρακτηριστικά ευκολίας χρήσης. |
|
||||
@ -0,0 +1,123 @@ |
|||||
|
\section{Απαιτήσεις λογισμικού} \label{section:3-5-software-requirements} |
||||
|
|
||||
|
Στην παρούσα ενότητα περιγράφονται οι βασικές απαιτήσεις λογισμικού ( \textenglish{software requirements}) της εφαρμογής. |
||||
|
|
||||
|
Η πρώτη κατηγορία είναι αυτή των Λειτουργικών Απαιτήσεων (ΛΑ), η οποία αναφέρεται στη συμπεριφορά του συστήματος, δηλαδή στον τρόπο που θα αντιδρά και στις εξόδους που θα παράγει ανάλογα με τις εισόδους. |
||||
|
|
||||
|
\begin{enumerate}[label=\textbf{<ΛΑ-\arabic*>}, leftmargin=\parindent, align=left, labelwidth=\parindent, labelsep=0pt] |
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-sign-up}} |
||||
|
{Ο χρήστης πρέπει να μπορεί να εγγραφεί στην εφαρμογή με τον Ethereum λογαριασμό του.} |
||||
|
{Ο χρήστης πρέπει να μπορεί να εγγραφεί στην εφαρμογή, πατώντας το κουμπί "Sign Up" και συμπληρώνοντας τα απαραίτητα πεδία σύμφωνα με τις οδηγίες. Το πεδίο "Username" είναι υποχρεωτικό να συμπληρωθεί και ορίζεται με μοναδικό τρόπο. Σε περίπτωση που ο χρήστης εισάγει μη διαθέσιμο Username, το σύστημα θα πρέπει να μην επιτρέπει στον χρήστη να συνεχίσει και να προβάλει αντίστοιχο μήνυμα λάθους. Τα πεδία "Profile picture URL" και "Location" είναι προαιρετικά.} |
||||
|
{5}{Η απαίτηση είναι ύψιστης προτεραιότητας για τους επισκέπτες καθώς μόνο μέσω της εγγραφής μπορούν να χρησιμοποιήσουν τα υπόλοιπα χαρακτηριστικά της εφαρμογής.} |
||||
|
{5}{Η απαίτηση αυτή είναι ύψιστης σημασίας για το σύστημα επειδή επηρεάζει τη λειτουργικότητά του.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-sign-in}} |
||||
|
{Ο χρήστης πρέπει να συνδέεται αυτόματα, εφόσον είναι εγγεγραμμένος.} |
||||
|
{Το σύστημα πρέπει να διαπιστώνει αυτόματα εάν το τρέχον Ethereum address έχει λογαριασμό στην εφαρμογή και εάν ναι, να συνδέει να τον χρήστη, ανακτώντας το Username του από το blockchain και προβάλλοντας το στο μενού.} |
||||
|
{5}{Η απαίτηση είναι ύψιστης προτεραιότητας για τους επισκέπτες καθώς μέσω της σύνδεσης ενεργοποιούνται τα χαρακτηριστικά της δημιουργίας θεμάτων και δημοσίευσης μηνυμάτων.} |
||||
|
{1}{Η σύνδεση αφορά μόνο τη γραφική διεπαφή του χρήστη με την πλατφόρμα και δεν αποτελεί στοιχείο που επιδρά στο υπόλοιπο σύστημα.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-create-user-databases}} |
||||
|
{Το σύστημα πρέπει να δημιουργεί τις βάσεις δεδομένων του χρήστη.} |
||||
|
{Το σύστημα πρέπει να δημιουργεί τις βάσεις δεδομένων του χρήστη, εάν αυτές δεν υπάρχουν ήδη τοπικά. Όταν ο χρήστης ξεκλειδώσει τον Ethereum λογαριασμό του, το σύστημα θα πρέπει να τον προτρέπει να υπογράψει με το ιδιωτικό του κλειδί μία συναλλαγή που θα εξασφαλίζει τη γνησιότητα των βάσεών του και των δεδομένων που αυτές θα εμπεριέχουν.} |
||||
|
{5}{Η απαίτηση αυτή είναι υψηλής σημασίας για τον χρήστη καθώς η δημιουργία των βάσεων είναι απαραίτητη για την διατήρηση των δεδομένων που δημοσιοποιεί.} |
||||
|
{5}{Η απαίτηση αυτή είναι υψηλής σημασίας για το σύστημα για τους ίδιους λόγους.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-create-topic}} |
||||
|
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί θέματα (topics).} |
||||
|
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί νέα θέματα. Αυτό το επιτυγχάνει πατώντας το κουμπί "New Topic", συμπληρώνοντας τα υποχρεωτικά πεδία της φόρμας ("Topic subject" και "First post content"), πατώντας το κουμπί "Create Topic" και επιβεβαιώνοντας τη συναλλαγή στο Ethereum.} |
||||
|
{5}{Η απαίτηση αυτή είναι υψηλής σημασίας καθώς επιτελεί έναν από τους βασικούς στόχους της πλατφόρμας.} |
||||
|
{5}{Η απαίτηση αυτή είναι υψηλής σημασίας για τον ίδιο λόγο.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-browse-topics}} |
||||
|
{Ο χρήστης πρέπει να μπορεί να περιηγείται σε θέματα.} |
||||
|
{Το σύστημα πρέπει να μπορεί να προβάλλει τα θέματα που έχουν δημιουργηθεί στην αρχική οθόνη. Ο χρήστης πρέπει να μπορεί να περιηγείται σε αυτά πατώντας πάνω τους και, έπειτα, χρησιμοποιώντας τα βέλη, να περιηγηθεί στο ιστορικό των μηνυμάτων του θέματος.} |
||||
|
{5}{Η απαίτηση αυτή είναι υψηλής σημασίας επειδή επιτρέπει στους επισκέπτες να έχουν πρόσβαση στο υλικό που είναι δημοσιευμένο στην πλατφόρμα.} |
||||
|
{5}{Η απαίτηση αυτή είναι υψηλής σημασίας επειδή αποτελεί βασικό χαρακτηριστικό της πλατφόρμας για την χρηστικότητά της.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-create-post}} |
||||
|
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί μηνύματα (posts).} |
||||
|
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί μηνύματα στο θέμα που επιθυμεί. Αυτό επιτυγχάνεται συμπληρώνοντας το πεδίο νέου μηνύματος στην οθόνη του θέματος, πατώντας το κουμπί "Post" και επιβεβαιώνοντας τη συναλλαγή στο Ethereum.} |
||||
|
{5}{Η απαίτηση αυτή είναι ύψιστης σημασίας για τους χρήστες επειδή αποτελεί ένα από τα βασικότερα χαρακτηριστικά της πλατφόρμας.} |
||||
|
{5}{Η απαίτηση αυτή είναι υψίστης σημασίας για το σύστημα καθώς αποτελεί θεμελιώδες κομμάτι για την επίτευξη του βασικότερου στόχου της, αυτού της δημιουργίας διαλόγου.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-modify-post}} |
||||
|
{Ο χρήστης πρέπει να μπορεί να τροποποιεί τα μηνύματά του.} |
||||
|
{Ο χρήστης πρέπει να μπορεί να τροποποιεί τα μηνύματά του. Αυτό το επιτυγχάνει πατώντας το κουμπί επεξεργασίας στο εκάστοτε μήνυμα, τροποποιώντας το μήνυμα και πατώντας το κουμπί επιβεβαίωσης. Στη συνέχεια, το σύστημα τροποποιεί το περιεχόμενο του μηνύματος στη βάση δεδομένων του χρήστη ανάλογα. Σε περίπτωση που ο χρήστης αλλάξει γνώμη κατά τη διάρκεια της διαδικασίας της επεξεργασίας, μπορεί να πατήσει το κουμπί ακύρωσης και να αναιρέσει τις αλλαγές που πραγματοποίησε.} |
||||
|
{4}{Η απαίτηση αυτή αποτελεί σημαντικό χαρακτηριστικό που απευθύνεται κυρίως στην χρηστικότητα της πλατφόρμας.} |
||||
|
{3}{Η απαίτηση αυτή είναι μέτριας σημαντικότητας για το σύστημα επειδή αυτό θα μπορούσε να είναι λειτουργικό χωρίς το χαρακτηριστικό της επεξεργασίας μηνυμάτων.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-vote-posts}} |
||||
|
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να ψηφίζει σε μηνύματα άλλων χρηστών.} |
||||
|
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να υπερψηφίζει ή να καταψηφίζει μηνύματα άλλων χρηστών. Αυτό το επιτυγχάνει πατώντας τα παρακείμενα κουμπιά "+" ή "-" αντίστοιχα και επιβεβαιώνοντας τη συναλλαγή στο Ethereum (οι ψήφοι αποθηκεύονται εκεί). Η διαδικασία ισχύει και για την τροποποίηση ή την αφαίρεση μίας ψήφου από τον χρήστη.} |
||||
|
{3}{Η απαίτηση αυτή είναι μέτριας σημασίας για τους χρήστες καθώς αποτελεί ένα χρήσιμο αλλά όχι απαραίτητο χαρακτηριστικό.} |
||||
|
{4}{Η απαίτηση αυτή είναι μεγάλης σημασίας για το σύστημα επειδή δημιουργεί δεδομένα τα οποία είναι χρήσιμα για τον υπολογισμό της εμπιστοσύνης των χρηστών.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-create-polls}} |
||||
|
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί ψηφοφορίες (polls).} |
||||
|
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να δημιουργεί ψηφοφορίες. Αυτό το επιτυγχάνει πατώντας "Add Poll" στην οθόνη δημιουργία θέματος και συμπληρώνοντας τα απαραίτητα πεδία.} |
||||
|
{5}{Η απαίτηση αυτή είναι ύψιστης σημασίας για τους χρήστες καθώς οι αμεσοδημοκρατικές διαδικασίες αποτελούν μία από τις κυριότερες χρήσεις της πλατφόρμας} |
||||
|
{5}{Η απαίτηση αυτή είναι μεγάλης σημασίας για το σύστημα επειδή αποτελεί βασική προδιαγραφή του.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-vote-polls}} |
||||
|
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να ψηφίζει σε ψηφοφορίες.} |
||||
|
{Ο εγγεγραμμένος χρήστης πρέπει να μπορεί να ψηφίζει σε ψηφοφορίες, σύμφωνα με τους εκάστοτε κανόνες.} |
||||
|
{5}{Η απαίτηση αυτή είναι ύψιστης σημασίας για τους χρήστες καθώς αποτελεί μία από τις ---- insert same as above} |
||||
|
{5}{Η απαίτηση αυτή είναι υψηλής σημασίας για το σύστημα καθώς αποτελεί σημαντικό χαρακτηριστικό του.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-delete-local-data}} |
||||
|
{Ο χρήστης πρέπει να μπορεί να διαγράφει τα τοπικά δεδομένα.} |
||||
|
{Ο χρήστης πρέπει να μπορεί να διαγράφει τα τοπικά δεδομένα. Αυτό το επιτυγχάνει πατώντας στο κουμπί "Clear databases" του μενού και επιβεβαιώνοντας τη διαγραφή μέσω ενός pop-up διαλόγου.} |
||||
|
{2}{Η απαίτηση αυτή είναι χαμηλής σημασία για τους χρήστες, διότι αποτελεί απλά μία διευκόλυνση για τη διαγραφή των δεδομένων που έχουν αποθηκεύσει τοπικά.} |
||||
|
{3}{Η απαίτηση αυτή είναι μέτριας σημασίας για το σύστημα καθώς συνάδει με την φιλοσοφία της πλατφόρμας σχετικά με την κυριότητα των δεδομένων από τους χρήστες.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-create-communities}} |
||||
|
{Ο χρήστης πρέπει να μπορεί να δημιουργεί κοινότητες.} |
||||
|
{Ο χρήστης πρέπει να μπορεί να δημιουργεί κοινότητες, μέσω κουμπιού της αρχικής οθόνης.} |
||||
|
{4}{Η απαίτηση αυτή είναι μεγάλης σημασίας για τους χρήστες καθώς παρέχει την ευελιξία της δημιουργίας κοινοτήτων.} |
||||
|
{4}{Η απαίτηση αυτή είναι μεγάλης σημασίας για την πλατφόρμα επειδή θα γενικεύσει τη χρήση της σε περισσότερες κοινότητες προσελκύοντας μεγαλύτερο αριθμό χρηστών.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:functional-srs-assign-community-contract}} |
||||
|
{Κατά τη δημιουργία κοινότητας, ο χρήστης πρέπει να έχει τη δυνατότητα να ορίσει ένα contract που θα παρέχει προσαρμοσμένα tokens για αυτήν.} |
||||
|
{Κατά τη δημιουργία κοινότητας, ο χρήστης πρέπει να έχει τη δυνατότητα να ορίσει ένα contract που θα παρέχει προσαρμοσμένα tokens για αυτήν. Τα tokens αυτά θα διαμοιράζονται με τον τρόπο που επιθυμεί η κοινότητα και θα είναι εκείνα τα οποία θα καθορίζουν τους έγκυρους ψηφοφόρους της.} |
||||
|
{4}{Η απαίτηση αυτή είναι μεγάλης σημασίας καθώς παρέχει στις κοινότητες τη δυνατότητα διενέργειας ανώνυμων ψηφοφοριών.} |
||||
|
{4}{Η απαίτηση αυτή είναι μεγάλης σημασίας για το σύστημα διότι θα παρέχει στις κοινότητες την απαιτούμενη αυτονομία στον ορισμό των διαδικασιών της κοινότητας.} |
||||
|
\end{enumerate} |
||||
|
|
||||
|
Η δεύτερη κατηγορία είναι αυτή των Μη Λειτουργικών Απαιτήσεων (ΜΛΑ). Περιλαμβάνει απαιτήσεις αρχιτεκτονικής σημασίας, οι οποίες καθορίζουν κριτήρια ή περιορισμούς του τρόπου λειτουργίας του συστήματος και σχετίζονται με χαρακτηριστικά όπως η αποδοτικότητα, η αξιοπιστία και η ευχρηστία του. |
||||
|
|
||||
|
\begin{enumerate}[label=\textbf{<ΜΛΑ-\arabic*>}, leftmargin=\parindent, align=left, labelwidth=\parindent, labelsep=0pt] |
||||
|
\sysReqItem |
||||
|
{\label{srs:non-functional-srs-maximum-decentraliztion}} |
||||
|
{Η πλατφόρμα πρέπει να είναι κατά το δυνατόν αρχιτεκτονικά αποκεντρωμένη.} |
||||
|
{Οι τεχνολογίες στις οποίες βασίζεται η πλατφόρμα πρέπει ιδανικά να μη δημιουργούν κεντρικά σημεία. Επιπλέον, ο κώδικας και η δημόσια διάθεση του πρέπει να γίνονται με αποκεντρωμένο τρόπο.} |
||||
|
{5}{Η αρχιτεκτονική αποκέντρωση της πλατφόρμας αποτελεί απαίτηση υψίστης σημασίας για τον χρήστη, καθώς διασφαλίζει την ελευθερία του λόγου του κτλ --κεφ 1.2} |
||||
|
{5}{Η αρχιτεκτονική αποκέντρωση της πλατφόρμας αποτελεί απαίτηση υψίστης σημασίας για το σύστημα, καθώς το καθιστά ασφαλές σε επιθέσεις κτλ --κεφ 1.2} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:non-functional-srs-minimize-fees}} |
||||
|
{Τα fees για τη χρήση του Ethereum blockchain πρέπει να ελαχιστοποιούνται.} |
||||
|
{Τα fees που πρέπει να καταβάλλονται για τη χρήση του Ethereum blockchain εξαρτώνται άμεσα τόσο από τον όγκο των δεδομένων προς αποθήκευση, όσο και από τους κύκλους επεξεργασίας των smart contracts της εφαρμογής. Ως προς τα δεδομένα, οι προγραμματιστές θα πρέπει να μεριμνούν ώστε ο κύριος όγκος τους να αποθηκεύεται επί του IPFS, ενώ επί του blockchain να αποθηκεύονται μόνο όσα πραγματικά χρειάζονται. Ως προς την απαιτούμενη επεξεργαστική ισχύ, πρέπει να βελτιστοποιείται ο κώδικας των smart contracts, έτσι ώστε οι διάφορες λειτουργίες τους να εκτελούνται με τους λιγότερους δυνατούς επεξεργαστικούς κύκλους.} |
||||
|
{4}{Η απαίτηση αυτή είναι μεγάλης σημασίας για τους χρήστες καθώς ναι μεν δεν είναι απαραίτητη για τη χρήση της αλλά είναι ιδιαίτερα σημαντική για την ένταξη χρηστών με χαμηλότερες οικονομικές δυνατότητες.} |
||||
|
{5}{Η απαίτηση αυτή είναι μεγάλης σημασίας για το σύστημα διότι αποτελεί σημαντικό παράγοντα που επιδρά στην προσέλκυση και διατήρηση ενεργών χρηστών.} |
||||
|
|
||||
|
\sysReqItem |
||||
|
{\label{srs:non-functional-srs-upgrade-contracts}} |
||||
|
{Τα contracts της εφαρμογής πρέπει να είναι αναβαθμίσιμα.} |
||||
|
{Τα contracts της εφαρμογής πρέπει μπορούν να αναβαθμιστούν, έτσι ώστε να μπορούν να προστίθενται λειτουργίες και να διορθώνονται σφάλματα. Η αναβαθμισιμότητά τους θα πρέπει να επιτυγχάνεται με μεθόδους που να μην υπονομεύουν τη λειτουργικότητα των προηγούμενων εκδόσεων.} |
||||
|
{2}{Η απαίτηση αυτή είναι χαμηλής σημασίας για τους χρήστες καθώς αφορά την ανάπτυξη και όχι τη χρήση της.} |
||||
|
{5}{Η απαίτηση αυτή είναι υψηλής σημασίας για το σύστημα επειδή προσφέρει τη δυνατότητα εξέλιξης και υλοποίησης νέων χαρακτηριστικών.} |
||||
|
\end{enumerate} |
||||
@ -1 +0,0 @@ |
|||||
\section{Αρχιτεκτονική} |
|
||||
@ -0,0 +1,17 @@ |
|||||
|
\section{Σενάρια χρήσης} \label{section:3-6-use-cases} |
||||
|
|
||||
|
Βασικό μέρος της σχεδίασης της πλατφόρμας ήταν η καταγραφή των απαιτήσεων η οποία έγινε στην προηγούμενη ενότητα (\ref{section:3-5-software-requirements}) καθώς και η σχεδίαση και ανάπτυξη των σεναρίων χρήσης. Τα σενάρια χρήσης αντιστοιχίζουν πιθανές ενέργειες των χρηστών με αποκρίσεις του συστήματος. Μέσω της αντιστοίχισης αυτής παρουσιάζεται η λειτουργικότητα του συστήματος και περιγράφονται τόσο οι λειτουργικές όσο και οι μη λειτουργικές απαιτήσεις του συστήματος. |
||||
|
|
||||
|
Παρατίθενται εδώ τα σενάρια χρήσης που δίνουν τις απαραίτητες πληροφορίες για την κατανόηση της λειτουργίας του συστήματος. |
||||
|
|
||||
|
\input{chapters/3.application-design/3.6.use-cases/3.6.1.use-case-sign-up} |
||||
|
\input{chapters/3.application-design/3.6.use-cases/3.6.2.use-case-sign-in} |
||||
|
\input{chapters/3.application-design/3.6.use-cases/3.6.3.use-case-create-topic} |
||||
|
\input{chapters/3.application-design/3.6.use-cases/3.6.4.use-case-fetch-topic} |
||||
|
\input{chapters/3.application-design/3.6.use-cases/3.6.5.use-case-create-post} |
||||
|
\input{chapters/3.application-design/3.6.use-cases/3.6.6.use-case-modify-post} |
||||
|
\input{chapters/3.application-design/3.6.use-cases/3.6.7.use-case-vote-in-poll} |
||||
|
\input{chapters/3.application-design/3.6.use-cases/3.6.8.use-case-vote-post} |
||||
|
\input{chapters/3.application-design/3.6.use-cases/3.6.9.delete-local-data} |
||||
|
|
||||
|
%TODO: Add missing use cases |
||||
@ -0,0 +1,78 @@ |
|||||
|
% ===== ===== |
||||
|
% Use case 1 |
||||
|
% ===== ===== |
||||
|
\subsection{Σενάριο χρήσης 1: Εγγραφή χρήστη} \label{subsection:3-6-use-case-signup} |
||||
|
|
||||
|
Το σενάριο χρήσης 1, <ΣΧ-1>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την εγγραφή ενός χρήστη στο σύστημα. Στους πίνακες \ref{table:3-6-use-case-sign-up} και \ref{table:3-6-use-case-sign-up-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-1> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-sign-up-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
||||
|
|
||||
|
\useCaseTable |
||||
|
{Εγγράφομαι στο σύστημα} |
||||
|
{Στόχος του σεναρίου χρήσης είναι ο επισκέπτης να μπορεί να εγγραφεί στο σύστημα ως χρήστης.} |
||||
|
{\ref{srs:functional-srs-sign-up}, \ref{srs:functional-srs-create-user-databases}} |
||||
|
{\ref{srs:non-functional-srs-minimize-fees}} |
||||
|
{Ο επισκέπτης πατάει το κουμπί εγγραφή.} |
||||
|
{Ο επισκέπτης πρέπει να έχει ανοίξει την σελίδα της εφαρμογής.} |
||||
|
{Σενάριο χρήσης 1, εγγραφή χρήστη στο σύστημα.} |
||||
|
{\label{table:3-6-use-case-sign-up}} |
||||
|
|
||||
|
% ===== Base flow ===== |
||||
|
|
||||
|
\useCaseBaseFlowTable |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει το κουμπί εγγραφή. & Το σύστημα εμφανίζει την φόρμα ``Εγγραφή Χρήστη''. \\ [0.5ex] |
||||
|
\midrule |
||||
|
2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί ``Υποβολή''. & Το σύστημα εισάγει νέο χρήστη στο blockchain. \\ [0.5ex] |
||||
|
\midrule |
||||
|
3 & - & Το σύστημα δημιουργεί τις προσωπικές βάσεις βάσεις δεδομένων OrbitDb του χρήστη. \\ [0.5ex] |
||||
|
\midrule |
||||
|
4 & - & Το σύστημα εμφανίζει την φόρμα ``Πληροφορίες Χρήστη''. \\ [0.5ex] |
||||
|
\midrule |
||||
|
5 & Ο χρήστης συμπληρώνει τις προσωπικές του πληροφορίες και πατάει το κουμπί ``Υποβολή''. & Το σύστημα εισάγει τις πληροφορίες χρήστη στην προσωπική του βάση OrbitDb. \\ [0.5ex] |
||||
|
} |
||||
|
{Το σύστημα μεταβαίνει στην αρχική σελίδα της εφαρμογής.} |
||||
|
{Σενάριο χρήσης 1 - Βασική ροή} |
||||
|
{\label{table:3-6-use-case-sign-up-base-flow}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-sign-up-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 1 - Διάγραμμα βασικής ροής} |
||||
|
\label{figure:3-6-use-case-sign-up-base-flow-sequence-diagram} |
||||
|
\end{figure} |
||||
|
|
||||
|
% ===== Alternate flows ===== |
||||
|
|
||||
|
Το <ΣΧ-1> περιέχει επίσης τρεις εναλλακτικές ροές που μπορεί να προκύψουν βάσει των επιλογών του χρήστη και οι οποίες περιγράφονται στους πίνακες \ref{table:3-6-use-case-sign-up-alternate-flow-1}, \ref{table:3-6-use-case-sign-up-alternate-flow-2} και \ref{table:3-6-use-case-sign-up-alternate-flow-3}. |
||||
|
|
||||
|
\useCaseAlternateFlowTable |
||||
|
{1} |
||||
|
{Τα στοιχεία χρήστη είναι λανθασμένα.} |
||||
|
{Εφόσον ο χρήστης στη γραμμή 2 δεν συμπληρώσει το πεδίο ονόματος χρήστη ή συμπληρώσει ένα όνομα χρήστη το οποίο είναι ήδη σε χρήση στο σύστημα, το σύστημα πρέπει να επιστρέψει σχετικό μήνυμα σφάλματος.} |
||||
|
{ |
||||
|
1 & - & Το σύστημα εμφανίζει μήνυμα σφάλματος. |
||||
|
} |
||||
|
{Το σύστημα επιστρέφει στη γραμμή 1 της βασικής ροής.} |
||||
|
{Σενάριο χρήσης 1 - Εναλλακτική ροή 1} |
||||
|
{\label{table:3-6-use-case-sign-up-alternate-flow-1}} |
||||
|
|
||||
|
\useCaseAlternateFlowTable |
||||
|
{2} |
||||
|
{Ο χρήστης πατάει το κουμπί ``Άκυρο''.} |
||||
|
{Εφόσον ο χρήστης στη γραμμή 2 της Βασικής Ροής επιλέξει ``Άκυρο'' το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής.} |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει το κουμπί ``Άκυρο'' & Το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής. |
||||
|
} |
||||
|
{Το σενάριο χρήσης τερματίζεται.} |
||||
|
{Σενάριο χρήσης 1 - Εναλλακτική ροή 2} |
||||
|
{\label{table:3-6-use-case-sign-up-alternate-flow-2}} |
||||
|
|
||||
|
\useCaseAlternateFlowTable |
||||
|
{3} |
||||
|
{Ο χρήστης πατάει το κουμπί ``Παράληψη''.} |
||||
|
{Εφόσον ο χρήστης στη γραμμή 5 της Βασικής Ροής επιλέξει ``Παράληψη'' το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής.} |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει το κουμπί ``Παράληψη'' & Το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής. |
||||
|
} |
||||
|
{Το σενάριο χρήσης τερματίζεται.} |
||||
|
{Σενάριο χρήσης 1 - Εναλλακτική ροή 3} |
||||
|
{\label{table:3-6-use-case-sign-up-alternate-flow-3}} |
||||
@ -0,0 +1,35 @@ |
|||||
|
% ===== ===== |
||||
|
% Use case 1 |
||||
|
% ===== ===== |
||||
|
\subsection{Σενάριο χρήσης 2: Σύνδεση χρήστη} \label{subsection:3-6-use-case-signin} |
||||
|
|
||||
|
Το σενάριο χρήσης 2, <ΣΧ-2>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την σύνδεση ενός χρήστη στο σύστημα. Στους πίνακες \ref{table:3-6-use-case-sign-in} και \ref{table:3-6-use-case-sign-in-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-2> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-sign-in-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
||||
|
|
||||
|
\useCaseTable |
||||
|
{Συνδέομαι στο σύστημα} |
||||
|
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να συνδέεται αυτόματα στο σύστημα.} |
||||
|
{\ref{srs:functional-srs-sign-in}} |
||||
|
{-} |
||||
|
{-} |
||||
|
{Ο χρήστης πρέπει να έχει ανοίξει την σελίδα της εφαρμογής.} |
||||
|
{Σενάριο χρήσης 2, σύνδεση χρήστη στο σύστημα.} |
||||
|
{\label{table:3-6-use-case-sign-in}} |
||||
|
|
||||
|
% ===== Base flow ===== |
||||
|
|
||||
|
\useCaseBaseFlowTable |
||||
|
{ |
||||
|
1 & - & Το σύστημα ανακτά τις πληροφορίες του χρήστη από το blockchain. \\ [0.5ex] |
||||
|
\midrule |
||||
|
2 & - & Το σύστημα δημιουργεί τις προσωπικές βάσεις βάσεις δεδομένων OrbitDb του χρήστη. \\ [0.5ex] |
||||
|
} |
||||
|
{Το σύστημα παραμένει στην αρχική σελίδα της εφαρμογής.} |
||||
|
{Σενάριο χρήσης 2 - Βασική ροή} |
||||
|
{\label{table:3-6-use-case-sign-in-base-flow}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-sign-in-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 2 - Διάγραμμα βασικής ροής} |
||||
|
\label{figure:3-6-use-case-sign-in-base-flow-sequence-diagram} |
||||
|
\end{figure} |
||||
@ -0,0 +1,74 @@ |
|||||
|
% ===== ===== |
||||
|
% Use case 3 |
||||
|
% ===== ===== |
||||
|
\subsection{Σενάριο χρήσης 3: Δημιουργία νέου θέματος} \label{subsection:3-6-use-case-create-topic} |
||||
|
|
||||
|
Το σενάριο χρήσης 3, <ΣΧ-3>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την δημιουργία ενός θέματος. Στους πίνακες \ref{table:3-6-use-case-create-topic} και \ref{table:3-6-use-case-create-topic-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-3> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-create-topic-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
||||
|
|
||||
|
\useCaseTable |
||||
|
{Δημιουργώ νέο θέμα} |
||||
|
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να μπορεί να δημιουργήσει νέο θέμα.} |
||||
|
{\ref{srs:functional-srs-create-topic}, \ref{srs:functional-srs-create-polls}} |
||||
|
{\ref{srs:non-functional-srs-minimize-fees}} |
||||
|
{Ο χρήστης πατάει το κουμπί δημιουργίας νέου θέματος.} |
||||
|
{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην αρχική σελίδα.} |
||||
|
{Σενάριο χρήσης 3, δημιουργία νέου θέματος.} |
||||
|
{\label{table:3-6-use-case-create-topic}} |
||||
|
|
||||
|
% ===== Base flow ===== |
||||
|
|
||||
|
\useCaseBaseFlowTable |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει το κουμπί δημιουργίας νέου θέματος. & Το σύστημα εμφανίζει την φόρμα ``Δημιουργία Θέματος''. \\ [0.5ex] |
||||
|
\midrule |
||||
|
2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί ``Υποβολή''. & Το σύστημα εισάγει νέο θέμα στο blockchain. \\ [0.5ex] |
||||
|
\midrule |
||||
|
3 & - & Το σύστημα εισάγει τις πληροφορίες του θέματος στην προσωπική βάση OrbitDb του χρήστη. \\ [0.5ex] |
||||
|
} |
||||
|
{Το σύστημα μεταβαίνει στην σελίδα του νέου θέματος.} |
||||
|
{Σενάριο χρήσης 3 - Βασική ροή} |
||||
|
{\label{table:3-6-use-case-create-topic-base-flow}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-create-topic-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 3 - Διάγραμμα βασικής ροής} |
||||
|
\label{figure:3-6-use-case-create-topic-base-flow-sequence-diagram} |
||||
|
\end{figure} |
||||
|
|
||||
|
% ===== Alternate flow ===== |
||||
|
|
||||
|
Το <ΣΧ-3> περιέχει επίσης δύο εναλλακτικές ροές που μπορεί να προκύψουν βάσει των επιλογών του χρήστη και οι οποίες περιγράφονται στους πίνακες \ref{table:3-6-use-case-create-topic-alternate-flow-1} και \ref{table:3-6-use-case-create-topic-alternate-flow-2}. Η εναλλακτική ροή 1 φαίνεται επίσης στο σχήμα \ref{figure:3-6-use-case-create-topic-alternate-flow-1-sequence-diagram} όπου παρουσιάζεται το διάγραμμα ροής της. |
||||
|
|
||||
|
\useCaseAlternateFlowTable |
||||
|
{1} |
||||
|
{Ο χρήστης δημιουργεί ψηφοφορία.} |
||||
|
{Εφόσον ο χρήστης στη γραμμή 2 της Βασικής Ροής επιλέξει ``Προσθήκη Ψηφοφορίας'' το σύστημα ανανεώνει την σελίδα προσθέτοντας τα επιπλέον πεδία της φόρμας ``Δημιουργία Ψηφοφορίας''.} |
||||
|
{ |
||||
|
1 & Ο χρήστης, αφού συμπληρώσει τη φόρμα ``Δημιουργία Θέματος'', πατάει το κουμπί ``Προσθήκη ψηφοφορίας'' & Το σύστημα ανανεώνει τη σελίδα με τα πεδία της φόρμας ``Δημιουργία Ψηφοφορίας''. \\ [0.5ex] |
||||
|
\midrule |
||||
|
2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί ``Υποβολή''. & Το σύστημα εισάγει το νέο θέμα καθώς και τη νέα ψηφοφορία στο blockchain. \\ [0.5ex] |
||||
|
\midrule |
||||
|
3 & - & Το σύστημα εισάγει τις πληροφορίες του θέματος και της ψηφοφορίας στις προσωπικές βάσεις OrbitDb του χρήστη. |
||||
|
} |
||||
|
{Το σύστημα μεταβαίνει στην σελίδα του νέου θέματος.} |
||||
|
{Σενάριο χρήσης 3 - Εναλλακτική ροή 1} |
||||
|
{\label{table:3-6-use-case-create-topic-alternate-flow-1}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-create-topic-alternate-flow-1-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 3 - Διάγραμμα εναλλακτικής ροής 1} |
||||
|
\label{figure:3-6-use-case-create-topic-alternate-flow-1-sequence-diagram} |
||||
|
\end{figure} |
||||
|
|
||||
|
\useCaseAlternateFlowTable |
||||
|
{2} |
||||
|
{Ο χρήστης πατάει το κουμπί ``Άκυρο''.} |
||||
|
{Εφόσον ο χρήστης στη γραμμή 2 της Βασικής Ροής ή στη γραμμή 2 της Εναλλακτικής Ροής 1 επιλέξει ``Άκυρο'' το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής.} |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει το κουμπί ``Άκυρο'' & Το σύστημα επιστρέφει στην αρχική σελίδα της εφαρμογής. |
||||
|
} |
||||
|
{Το σενάριο χρήσης τερματίζεται.} |
||||
|
{Σενάριο χρήσης 3 - Εναλλακτική ροή 2} |
||||
|
{\label{table:3-6-use-case-create-topic-alternate-flow-2}} |
||||
@ -0,0 +1,60 @@ |
|||||
|
% ===== ===== |
||||
|
% Use case 4 |
||||
|
% ===== ===== |
||||
|
\subsection{Σενάριο χρήσης 4: Ανάκτηση θέματος} \label{subsection:3-6-use-case-fetch-topic} |
||||
|
|
||||
|
Το σενάριο χρήσης 4, <ΣΧ-4>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την ανάκτηση ενός θέματος. Στους πίνακες \ref{table:3-6-use-case-fetch-topic} και \ref{table:3-6-use-case-fetch-topic-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-4> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-fetch-topic-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
||||
|
|
||||
|
\useCaseTable |
||||
|
{Ανακτώ ένα θέμα} |
||||
|
{Στόχος του σεναρίου χρήσης είναι ο επισκέπτης ή ο χρήστης να μπορεί να ανακτήσει ένα θέμα.} |
||||
|
{\ref{srs:functional-srs-browse-topics}} |
||||
|
{-} |
||||
|
{Ο επισκέπτης ή χρήστης πατάει σε ένα από τα θέματα.} |
||||
|
{Ο επισκέπτης ή χρήστης πρέπει να έχει ανοίξει την σελίδα της εφαρμογής.} |
||||
|
{Σενάριο χρήσης 4, ανάκτηση θέματος.} |
||||
|
{\label{table:3-6-use-case-fetch-topic}} |
||||
|
|
||||
|
% ===== Base flow ===== |
||||
|
|
||||
|
\useCaseBaseFlowTable |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει σε ένα από τα θέματα της λίστας. & Το σύστημα ανακτά τις πληροφορίες του θέματος από το blockchain. \\ [0.5ex] |
||||
|
\midrule |
||||
|
2 & - & Το σύστημα ανακτά τα μηνύματα του θέματος αντιγράφοντας τις προσωπικές βάσεις OrbitDb των συγγραφέων. \\ [0.5ex] |
||||
|
} |
||||
|
{Το σύστημα μεταβαίνει στην σελίδα του θέματος.} |
||||
|
{Σενάριο χρήσης 4 - Βασική ροή} |
||||
|
{\label{table:3-6-use-case-fetch-topic-base-flow}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-fetch-topic-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 4 - Διάγραμμα βασικής ροής} |
||||
|
\label{figure:3-6-use-case-fetch-topic-base-flow-sequence-diagram} |
||||
|
\end{figure} |
||||
|
|
||||
|
% ===== Alternate flow ===== |
||||
|
|
||||
|
Το <ΣΧ-4> περιέχει επίσης μία εναλλακτική ροή που μπορεί να προκύψει βάσει των επιλογών του χρήστη και η οποία περιγράφεται στον πίνακα \ref{table:3-6-use-case-fetch-topic-alternate-flow-1}. Η εναλλακτική ροή 1 φαίνεται επίσης στο σχήμα \ref{figure:3-6-use-case-fetch-topic-alternate-flow-1-sequence-diagram} όπου παρουσιάζεται το διάγραμμα ροής της. |
||||
|
|
||||
|
\useCaseAlternateFlowTable |
||||
|
{1} |
||||
|
{Το θέμα περιέχει ψηφοφορία.} |
||||
|
{Εφόσον το θέμα που ανακτήθηκε στη γραμμή 1 της Βασικής Ροής περιέχει ψηφοφορία ανακτώνται οι πληροφορίες της.} |
||||
|
{ |
||||
|
1 & - & Το σύστημα ανακτά τα μηνύματα του θέματος αντιγράφοντας τις προσωπικές βάσεις OrbitDb των συγγραφέων. \\ [0.5ex] |
||||
|
2 & - & Το σύστημα ανακτά την ψηφοφορία από το blockchain. \\ [0.5ex] |
||||
|
3 & - & Το σύστημα ανακτά τις πληροφορίες της ψηφοφορίας αντιγράφοντας την προσωπική βάση OrbitDb του συγγραφέα. \\ [0.5ex] |
||||
|
4 & - & Το σύστημα επιβεβαιώνει τις πληροφορίες της ψηφοφορίας με βάση το hash που έχει ανακτηθεί από το blockchain. \\ [0.5ex] |
||||
|
} |
||||
|
{Το σενάριο χρήσης τερματίζεται.} |
||||
|
{Σενάριο χρήσης 4 - Εναλλακτική ροή 1} |
||||
|
{\label{table:3-6-use-case-fetch-topic-alternate-flow-1}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-fetch-topic-alternate-flow-1-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 4 - Διάγραμμα εναλλακτικής ροής 1} |
||||
|
\label{figure:3-6-use-case-fetch-topic-alternate-flow-1-sequence-diagram} |
||||
|
\end{figure} |
||||
@ -0,0 +1,52 @@ |
|||||
|
% ===== ===== |
||||
|
% Use case 5 |
||||
|
% ===== ===== |
||||
|
\subsection{Σενάριο χρήσης 5: Δημιουργία νέου μηνύματος} \label{subsection:3-6-use-case-create-post} |
||||
|
|
||||
|
Το σενάριο χρήσης 5, <ΣΧ-5>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την δημιουργία ενός μηνύματος. Στους πίνακες \ref{table:3-6-use-case-create-post} και \ref{table:3-6-use-case-create-post-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-5> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-create-post-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
||||
|
|
||||
|
\useCaseTable |
||||
|
{Δημιουργώ νέο μήνυμα} |
||||
|
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να μπορεί να δημιουργήσει νέο μήνυμα.} |
||||
|
{\ref{srs:functional-srs-create-post}} |
||||
|
{\ref{srs:non-functional-srs-minimize-fees}} |
||||
|
{Ο χρήστης πατάει το κουμπί δημιουργίας νέου μηνύματος.} |
||||
|
{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην σελίδα ενός θέματος.} |
||||
|
{Σενάριο χρήσης 5, δημιουργία νέου μηνύματος.} |
||||
|
{\label{table:3-6-use-case-create-post}} |
||||
|
|
||||
|
% ===== Base flow ===== |
||||
|
|
||||
|
\useCaseBaseFlowTable |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει το κουμπί δημιουργίας νέου μηνύματος. & Το σύστημα εμφανίζει την φόρμα ``Δημιουργία Μηνύματος''. \\ [0.5ex] |
||||
|
\midrule |
||||
|
2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί ``Υποβολή''. & Το σύστημα εισάγει νέο μήνυμα στο blockchain. \\ [0.5ex] |
||||
|
\midrule |
||||
|
3 & - & Το σύστημα εισάγει τις πληροφορίες του μηνύματος στην προσωπική βάση OrbitDb του χρήστη. \\ [0.5ex] |
||||
|
} |
||||
|
{Το σύστημα παραμένει στη σελίδα του θέματος εμφανίζοντας το νέο μήνυμα.} |
||||
|
{Σενάριο χρήσης 5 - Βασική ροή} |
||||
|
{\label{table:3-6-use-case-create-post-base-flow}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-create-post-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 5 - Διάγραμμα βασικής ροής} |
||||
|
\label{figure:3-6-use-case-create-post-base-flow-sequence-diagram} |
||||
|
\end{figure} |
||||
|
|
||||
|
% ===== Alternate flow ===== |
||||
|
|
||||
|
Το <ΣΧ-5> περιέχει επίσης μία εναλλακτική ροή που μπορεί να προκύψει βάσει των επιλογών του χρήστη και η οποία περιγράφεται στον πίνακα \ref{table:3-6-use-case-create-post-alternate-flow-1}. |
||||
|
|
||||
|
\useCaseAlternateFlowTable |
||||
|
{1} |
||||
|
{Ο χρήστης πατάει το κουμπί ``Άκυρο''.} |
||||
|
{Εφόσον ο χρήστης στη γραμμή 2 της Βασικής Ροής επιλέξει ``Άκυρο'' το σύστημα επιστρέφει στη σελίδα του θέματος.} |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει το κουμπί ``Άκυρο'' & Το σύστημα επιστρέφει στη σελίδα του θέματος. |
||||
|
} |
||||
|
{Το σενάριο χρήσης τερματίζεται.} |
||||
|
{Σενάριο χρήσης 5 - Εναλλακτική ροή 1} |
||||
|
{\label{table:3-6-use-case-create-post-alternate-flow-1}} |
||||
@ -0,0 +1,50 @@ |
|||||
|
% ===== ===== |
||||
|
% Use case 6 |
||||
|
% ===== ===== |
||||
|
\subsection{Σενάριο χρήσης 6: Τροποποίηση μηνύματος} \label{subsection:3-6-use-case-modify-post} |
||||
|
|
||||
|
Το σενάριο χρήσης 6, <ΣΧ-6>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για τη τροποποίηση ενός μηνύματος. Στους πίνακες \ref{table:3-6-use-case-modify-post} και \ref{table:3-6-use-case-modify-post-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-6> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-modify-post-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
||||
|
|
||||
|
\useCaseTable |
||||
|
{Τροποποιώ ένα μήνυμα} |
||||
|
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να μπορεί να τροποποιήσει τα μηνύματά του.} |
||||
|
{\ref{srs:functional-srs-modify-post}} |
||||
|
{-} |
||||
|
{Ο χρήστης πατάει το κουμπί τροποποίησης του μηνύματος.} |
||||
|
{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην σελίδα του θέματος που περιέχει το μήνυμά του.} |
||||
|
{Σενάριο χρήσης 6, τροποποίηση μηνύματος.} |
||||
|
{\label{table:3-6-use-case-modify-post}} |
||||
|
|
||||
|
% ===== Base flow ===== |
||||
|
|
||||
|
\useCaseBaseFlowTable |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει το κουμπί τροποποίησης του μηνύματος. & Το σύστημα εμφανίζει την φόρμα ``Τροποποίηση Μηνύματος''. \\ [0.5ex] |
||||
|
\midrule |
||||
|
2 & Ο χρήστης συμπληρώνει τα πεδία και πατάει το κουμπί ``Υποβολή''. & Το σύστημα τροποποιεί τις πληροφορίες του μηνύματος στην προσωπική βάση OrbitDb του χρήστη. \\ [0.5ex] |
||||
|
} |
||||
|
{Το σύστημα παραμένει στη σελίδα του θέματος εμφανίζοντας το τροποποιημένο μήνυμα.} |
||||
|
{Σενάριο χρήσης 6 - Βασική ροή} |
||||
|
{\label{table:3-6-use-case-modify-post-base-flow}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-modify-post-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 6 - Διάγραμμα βασικής ροής} |
||||
|
\label{figure:3-6-use-case-modify-post-base-flow-sequence-diagram} |
||||
|
\end{figure} |
||||
|
|
||||
|
% ===== Alternate flow ===== |
||||
|
|
||||
|
Το <ΣΧ-6> περιέχει επίσης μία εναλλακτική ροή που μπορεί να προκύψει βάσει των επιλογών του χρήστη και η οποία περιγράφεται στον πίνακα \ref{table:3-6-use-case-modify-post-alternate-flow-1}. |
||||
|
|
||||
|
\useCaseAlternateFlowTable |
||||
|
{1} |
||||
|
{Ο χρήστης πατάει το κουμπί ``Άκυρο''.} |
||||
|
{Εφόσον ο χρήστης στη γραμμή 2 της Βασικής Ροής επιλέξει ``Άκυρο'' το σύστημα επιστρέφει στη σελίδα του θέματος.} |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει το κουμπί ``Άκυρο'' & Το σύστημα επιστρέφει στη σελίδα του θέματος. |
||||
|
} |
||||
|
{Το σενάριο χρήσης τερματίζεται.} |
||||
|
{Σενάριο χρήσης 6 - Εναλλακτική ροή 1} |
||||
|
{\label{table:3-6-use-case-modify-post-alternate-flow-1}} |
||||
@ -0,0 +1,33 @@ |
|||||
|
% ===== ===== |
||||
|
% Use case 7 |
||||
|
% ===== ===== |
||||
|
\subsection{Σενάριο χρήσης 7: Ψήφιση σε ψηφοφορία} \label{subsection:3-6-use-case-vote-in-poll} |
||||
|
|
||||
|
Το σενάριο χρήσης 7, <ΣΧ-7>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την ψήφιση σε μία ψηφοφορία. Στους πίνακες \ref{table:3-6-use-case-vote-in-poll} και \ref{table:3-6-use-case-vote-in-poll-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-7> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-vote-in-poll-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
||||
|
|
||||
|
\useCaseTable |
||||
|
{Ψηφίζω σε ψηφοφορία} |
||||
|
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να μπορεί να ψηφίσει σε μία ψηφοφορία.} |
||||
|
{\ref{srs:functional-srs-vote-polls}} |
||||
|
{\ref{srs:non-functional-srs-minimize-fees}} |
||||
|
{Ο χρήστης πατάει το κουμπί ψηφοφορίας.} |
||||
|
{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην σελίδα ενός θέματος το οποίο περιλαμβάνει ψηφοφορία.} |
||||
|
{Σενάριο χρήσης 7, ψήφιση σε ψηφοφορία.} |
||||
|
{\label{table:3-6-use-case-vote-in-poll}} |
||||
|
|
||||
|
% ===== Base flow ===== |
||||
|
|
||||
|
\useCaseBaseFlowTable |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει το κουμπί της επιλογής που επιθυμεί να ψηφίσει και πατάει το κουμπί ``Υποβολή''. & Το σύστημα εισάγει νέα ψήφο στο blockchain. \\ [0.5ex] |
||||
|
} |
||||
|
{Το σύστημα ανανεώνει τις πληροφορίες της ψηφοφορίας.} |
||||
|
{Σενάριο χρήσης 7 - Βασική ροή} |
||||
|
{\label{table:3-6-use-case-vote-in-poll-base-flow}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-vote-in-poll-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 7 - Διάγραμμα βασικής ροής} |
||||
|
\label{figure:3-6-use-case-vote-in-poll-base-flow-sequence-diagram} |
||||
|
\end{figure} |
||||
@ -0,0 +1,33 @@ |
|||||
|
% ===== ===== |
||||
|
% Use case 8 |
||||
|
% ===== ===== |
||||
|
\subsection{Σενάριο χρήσης 8: Ψήφιση μηνύματος} \label{subsection:3-6-use-case-vote-post} |
||||
|
|
||||
|
Το σενάριο χρήσης 8, <ΣΧ-8>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για την ψήφιση σε ένα μήνυμα. Στους πίνακες \ref{table:3-6-use-case-vote-post} και \ref{table:3-6-use-case-vote-post-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-8> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-vote-post-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
||||
|
|
||||
|
\useCaseTable |
||||
|
{Ψηφίζω σε μήνυμα} |
||||
|
{Στόχος του σεναρίου χρήσης είναι ο χρήστης να μπορεί να υπερψηφίσει ή καταψηφίσει ένα μήνυμα.} |
||||
|
{\ref{srs:functional-srs-vote-posts}} |
||||
|
{\ref{srs:non-functional-srs-minimize-fees}} |
||||
|
{Ο επισκέπτης πατάει το κουμπί υπερψήφισης ή καταψήφισης.} |
||||
|
{Ο χρήστης να έχει συνδεθεί στην εφαρμογή και να βρίσκεται στην σελίδα ενός θέματος το οποίο περιλαμβάνει τουλάχιστον ένα μήνυμα το οποίο δεν έχει δημιουργήσει ο ίδιος.} |
||||
|
{Σενάριο χρήσης 8, ψήφιση μηνύματος.} |
||||
|
{\label{table:3-6-use-case-vote-post}} |
||||
|
|
||||
|
% ===== Base flow ===== |
||||
|
|
||||
|
\useCaseBaseFlowTable |
||||
|
{ |
||||
|
1 & Ο χρήστης πατάει στο κουμπί υπερψήφισης μηνύματος. & Το σύστημα εισάγει νέα ψήφο μηνύματος στο blockchain. \\ [0.5ex] |
||||
|
} |
||||
|
{Το σύστημα ανανεώνει τις ψήφους του μηνύματος.} |
||||
|
{Σενάριο χρήσης 8 - Βασική ροή} |
||||
|
{\label{table:3-6-use-case-vote-post-base-flow}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-vote-post-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 8 - Διάγραμμα βασικής ροής} |
||||
|
\label{figure:3-6-use-case-vote-post-base-flow-sequence-diagram} |
||||
|
\end{figure} |
||||
@ -0,0 +1,35 @@ |
|||||
|
% ===== ===== |
||||
|
% Use case 9 |
||||
|
% ===== ===== |
||||
|
\subsection{Σενάριο χρήσης 9: Διαγραφή τοπικών δεδομένων} \label{subsection:3-6-use-case-delete-local-data} |
||||
|
|
||||
|
Το σενάριο χρήσης 9, <ΣΧ-9>, περιγράφει τις διαδοχικές ενέργειες που εκτελούνται για τη διαγραφή των τοπικών δεδομένων. Στους πίνακες \ref{table:3-6-use-case-delete-local-data} και \ref{table:3-6-use-case-delete-local-data-base-flow} παρατίθενται οι βασικές πληροφορίες του <ΣΧ-9> και οι ενέργειες της βασικής ροής αντίστοιχα, ενώ στο σχήμα \ref{figure:3-6-use-case-delete-local-data-base-flow-sequence-diagram} φαίνεται το διάγραμμα της βασικής ροής. |
||||
|
|
||||
|
\useCaseTable |
||||
|
{Διαγράφω τα τοπικά δεδομένα} |
||||
|
{Στόχος του σεναρίου χρήσης είναι ο επισκέπτης να μπορεί να διαγράψει τα τοπικά δεδομένα που αποθηκεύονται στο σύστημά του από την εφαρμογή.} |
||||
|
{\ref{srs:functional-srs-delete-local-data}} |
||||
|
{-} |
||||
|
{Ο επισκέπτης πατάει το κουμπί διαγραφής των τοπικών δεδομένων.} |
||||
|
{Ο επισκέπτης πρέπει να έχει ανοίξει την σελίδα της εφαρμογής.} |
||||
|
{Σενάριο χρήσης 9, διαγραφή τοπικών δεδομένων.} |
||||
|
{\label{table:3-6-use-case-delete-local-data}} |
||||
|
|
||||
|
% ===== Base flow ===== |
||||
|
|
||||
|
\useCaseBaseFlowTable |
||||
|
{ |
||||
|
1 & Ο επισκέπτης πατάει το κουμπί διαγραφής των τοπικών δεδομένων. & Το σύστημα εμφανίζει την φόρμα ``Επιβεβαίωση Διαγραφής Τοπικών Δεδομένων''. \\ [0.5ex] |
||||
|
\midrule |
||||
|
2 & Ο επισκέπτης συμπληρώνει το πεδίο και πατάει το κουμπί ``Υποβολή''. & Το σύστημα διαγράφει όλες τις τοπικές βάσεις OrbitDb που χρησιμοποιούνται από την εφαρμογή. \\ [0.5ex] |
||||
|
} |
||||
|
{Το σύστημα παραμένει πραγματοποιεί ανανέωση της σελίδας.} |
||||
|
{Σενάριο χρήσης 9 - Βασική ροή} |
||||
|
{\label{table:3-6-use-case-delete-local-data-base-flow}} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\input{tikz/chapter-3/3-6-use-case-delete-local-data-sequence-diagram} |
||||
|
\caption{Σενάριο χρήσης 9 - Διάγραμμα βασικής ροής} |
||||
|
\label{figure:3-6-use-case-delete-local-data-base-flow-sequence-diagram} |
||||
|
\end{figure} |
||||
@ -0,0 +1,21 @@ |
|||||
|
\section{Αρχιτεκτονική σχεδίαση} \label{section:3-7-architecture-design} |
||||
|
|
||||
|
Στο κεφάλαιο αυτό περιγράφεται η αρχιτεκτονική του συστήματος, όπως προέκυψε από την επιλεγμένη τεχνολογική στοίβα και τις προαναφερθείσες απαιτήσεις του. Θα πρέπει να σημειωθεί ότι η παρουσιαζόμενη αρχιτεκτονική είναι πρώιμη και δεν αποτελεί την τελική υλοποίηση της πλατφόρμας, η οποία περιγράφεται στο κεφάλαιο \ref{chapter:4-application-implementation}. |
||||
|
|
||||
|
Συνοπτικά, η αρχιτεκτονική του συστήματος αποτυπώνεται στο παρακάτω διάγραμμα: |
||||
|
|
||||
|
% TODO: Add proper figure |
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.75\textwidth]{assets/figures/chapter-3/3.7.architecture-design} |
||||
|
\caption{Αρχιτεκτονική του συστήματος (στάδιο σχεδίασης)} |
||||
|
\end{figure} |
||||
|
|
||||
|
Αξίζει να σημειωθούν τα εξής: |
||||
|
|
||||
|
\begin{itemize} |
||||
|
\item Ο κώδικας του frontend εκτελείται αποκλειστικά στο σύστημα του χρήστη, χωρίς να απαιτείται κάποιος εξυπηρετητής. Δηλαδή, ο χρήστης αρκεί απλά να έχει τον κώδικα αποθηκευμένο στον υπολογιστή του. |
||||
|
\item Ο χρήστης αλληλεπιδρά άμεσα με το UI και το MetaMask. Το MetaMask αποτελεί browser add-on, το οποίο διαχειρίζεται τα ιδιωτικά κλειδιά Ethereum του χρήστη και πραγματοποιεί τις συναλλαγές του τελευταίου με τα smart contracts. Στην προκειμένη περίπτωση, περιέχει τα κλειδιά που σχετίζονται αφενός με τη διεύθυνση με την οποία ο χρήστης εγγράφεται στην πλατφόρμα, αφετέρου με τις διευθύνσεις που περιέχουν τα NFTs των κοινοτήτων στις οποίες ανήκει και έχει δικαιώματα ψήφου. |
||||
|
\item Στο frontend εκτελείται στο παρασκήνιο ένας κόμβος για το IPFS. Αυτός συνδέεται με άλλους κατάλληλους κόμβους, διαμοιράζοντας τον κύριο όγκο των δεδομένων της εφαρμογής (π.χ. του περιεχομένου των μηνυμάτων). |
||||
|
\item Τέλος, στο Ethereum blockchain υπάρχουν τόσο τα contracts της εφαρμογής, όσο και τα εξωτερικά contracts που παρέχουν τα tokens των κοινοτήτων. Τα μεν λειτουργούν ως το σημείο αναφοράς της εφαρμογής, επί του οποίου εκτελούνται οι ενέργειες και αποθηκεύονται οι μεταβλητές που είναι απολύτως απαραίτητες για τη λειτουργία της πλατφόρμας (π.χ. εγγεγραμμένοι χρήστες, δημιουργημένες κοινότητες). Τα δε, δημιουργούνται από εξωτερικές οντότητες, οι οποίες ορίζουν κατά τη βούλησή τους τον ακριβή τρόπο δημιουργίας και διαμοιρασμού των tokens τους στους χρήστες. |
||||
|
\end{itemize} |
||||
@ -0,0 +1,18 @@ |
|||||
|
\section{Προδιαγραφή μεθόδου υλοποίησης και χρονοπρογραμματισμός} \label{section:3-8-implementation-methodology-specification} |
||||
|
|
||||
|
Κατά τον χρονοπρογραμματισμό ακολουθήθηκαν οι τακτικές που ορίζει το Scrum. Το συνολικό προγραμματιστικό έργο χωρίστηκε σε επιμέρους, διακριτούς στόχους και κάθε στόχος αντιστοιχήθηκε σε ένα Sprint. Τα Sprints αποτελούνται από επιμέρους διαχωρισμό της εργασίας σε epic tasks. Σε αυτό το στάδιο χρονοπρογραμματισμού δεν έγινε αναλυτικότερη περιγραφή των επιμέρους tasks, κάθε epic χωρίστηκε σε tasks κατά το αρχικό στάδιο της υλοποίησης του. |
||||
|
|
||||
|
Ως σημαντικότερος στόχος της ανάπτυξης ορίζεται η δημιουργία ενός ελάχιστου βιώσιμου προϊόντος (Minumum Viable Product - MVP). Σε αυτό τον στόχο περιλαμβάνονται πιο στοιχειώδεις λειτουργίες μίας πλατφόρμας επικοινωνίας οι οποίες την κάνουν χρήσιμη, η δυνατότητα εγγραφής, δημιουργίας θεμάτων και μηνυμάτων και ανάγνωσης του υπάρχοντος περιεχομένου. Επειδή ο στόχος αυτός περιέχει από μόνος του σημαντική περιπλοκότητα και δυσκολία κρίθηκε αναγκαίος ο περαιτέρω διαχωρισμός του σε τρία Sprints. |
||||
|
|
||||
|
Στο πρώτο Sprint ορίστηκε ο στόχος της δημιουργίας μίας βάσης κώδικα (codebase), της εξοικείωσης με τα προγραμματιστικά εργαλεία του οικοσυστήματος των DApps και της επιτυχής δημιουργίας του πρώτου contract. Στο δεύτερο Sprint ο στόχος ορίστηκε ως η δημιουργία των τεχνικών χαρακτηριστικών που αφορούν τους χρήστες της πλατφόρμας και που οι ίδιοι (οι χρήστες) έχουν συνηθίσει να περιμένουν από μία τέτοια πλατφόρμα. Στο τρίτο Sprint συμπεριλήφθηκαν τα τεχνικά χαρακτηριστικά που απομένουν ώστε να δημιουργηθεί το MVP. |
||||
|
|
||||
|
Τα επόμενα τρία Sprints χτίζουν διαδοχικά πάνω στην υπάρχουσα δουλειά και υποδομή. Στο τέταρτο μέρος εργασίας ως στόχος ορίστηκε η προσθήκη των χαρακτηριστικών ψηφοφορίας πάνω στα μηνύματα και δημιουργίας ψηφοφοριών θεμάτων (polls). Το επόμενο Sprint περιλαμβάνει εργασίες δημιουργίας υποδομής και την πρώτη ημι-δημόσια εγκατάσταση της εφαρμογής σε περιβάλλον δοκιμής. Το τελευταίο Sprint αποτελεί το τελικό προϊόν και περιέχει tasks σχετικά με την δημιουργία κοινοτήτων και την beta εγκατάσταση της εφαρμογής. |
||||
|
|
||||
|
Εποπτικά, η διαδικασία της υλοποίησης περιγράφεται στο παρακάτω σχήμα (σχήμα \ref{figure:3.8.implementation-methodology-specification-sprints}). |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.8\textwidth]{assets/figures/chapter-3/3.8.implementation-methodology-specification-sprints.png} |
||||
|
\caption{Διαχωρισμός σε sprints} |
||||
|
\label{figure:3.8.implementation-methodology-specification-sprints} |
||||
|
\end{figure} |
||||
@ -1,6 +1,8 @@ |
|||||
\chapter{Υλοποίηση εφαρμογής} |
\chapter{Υλοποίηση εφαρμογής}\label{chapter:4-application-implementation} |
||||
|
|
||||
\input{chapters/4.application-implementation/4.1.implemented-parts} |
\input{chapters/4.application-implementation/4.1.implemented-parts} |
||||
\input{chapters/4.application-implementation/4.2.implementation-methodology} |
\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.3.implementation-technology-stack} |
||||
\input{chapters/4.application-implementation/4.4.implementation-architecture} |
\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} |
||||
|
|||||
@ -1 +1,6 @@ |
|||||
\section{Χαρακτηριστικά που υλοποιήθηκαν} |
\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 |
||||
|
|||||
@ -1 +1,60 @@ |
|||||
\section{Μεθοδολογία υλοποίησης} |
\section{Μεθοδολογία υλοποίησης} \label{subsection:4-2-implementation-methodology} |
||||
|
|
||||
|
Για την επίτευξη των στόχων που ορίστηκαν και την οργάνωση της εργασίας που απαιτείται σε διαχειρίσιμα μέρη, σχεδιάστηκε η χρήση διάφορων εργαλείων και μεθόδων ανάπτυξης λογισμικού, όπως το σύστημα ελέγχου εκδόσεων (version control system) Git, η μέθοδος οργάνωσης Scrum και οι διαδικασίες ανάπτυξης DevOps. Τα εργαλεία αυτά είναι δοκιμασμένα και έχουν εδραιωθεί στη σύγχρονη ανάπτυξη λογισμικού. |
||||
|
|
||||
|
Μέσα από την χρήση των παραπάνω εργαλείων επιτυγχάνεται η ομαλή συνεργασία στην ανάπτυξη του λογισμικού. Κάθε μέλος της ομάδας δύναται να εργαστεί ανεξάρτητα και χωρίς την ανάγκη διαρκούς επικοινωνίας με τα υπόλοιπα μέλη. Οι στόχοι είναι ορισμένοι, σαφείς και χωρισμένοι σε διαχειρίσιμα μέρη τα οποία δεν καταβάλουν τα μέλη. Ταυτόχρονα, έχοντας ως έδρα καθιερωμένα πρότυπα ανάπτυξης, παρέχεται φορμαλισμός και έτοιμες μέθοδοι επίλυσης προβλημάτων, γεγονός που λειτουργεί καταλυτικά και βοηθά στην αποφυγή τελμάτων κατά τη συγγραφή του κώδικα. |
||||
|
|
||||
|
Το 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). |
||||
|
|
||||
|
Το Scrum είναι μία μέθοδος οργάνωσης στην οποία ο επιμελητής του Scrum (Scrum master) διαχωρίζει τα ανεξάρτητα μέρη εργασίας (tasks) που πρέπει να υλοποιηθούν για την ολοκλήρωση των στόχων ενός project. Τα μέρη αυτά περιγράφονται αναλυτικά μαζί με τις απαιτήσεις τους και κατατίθενται σε μία λίστα εργασιών (backlog). Έπειτα, μέσα από συσκέψεις (meetings), επιλέγεται ένας αριθμός από tasks τα οποία ορίζουν το επόμενο προγραμματιστικό κύκλο (sprint). Κάθε task ανατίθεται σε κάποιο μέλος για υλοποίηση. Για το Sprint ορίζεται μία χρονική διάρκεια, στόχος της οποίας είναι η περάτωση όλων των tasks πριν τη λήξη της. Στο τέλος της προθεσμίας που ορίστηκε για το Sprint τα μέλη της ομάδας αποτιμούν τα αποτελέσματα και ορίζουν το επόμενο Sprint. Η διαδικασία επαναλαμβάνεται έως ότου το έργο ολοκληρωθεί. |
||||
|
|
||||
|
Λόγω του πολύ μικρού μεγέθους της ομάδας, το Scrum ακολουθήθηκε ελαστικά. Συγκεκριμένα, δεν ορίστηκε ένας συγκεκριμένος επιμελητής του board αλλά κάθε μέλος της ομάδας φρόντιζε για τον ορισμό και την περιγραφή ενός μέρους των tasks. Τα sprints δεν ήταν συνεχόμενα και δεν είχαν πάντα τον ίδιο χρόνο εκτέλεσης αλλά προσαρμόζονταν ανάλογα με τις εκάστοτε ανάγκες και τον χρόνο των μελών. Κατά βάση, χρησιμοποιήθηκε η μέθοδος Kanban (που χρησιμοποιείται από το ίδιο το Scrum), για την οπτικοποίηση των tasks. Τα tasks χωρίστηκαν σε λίστες οι οποίες περιλαμβάνουν: |
||||
|
|
||||
|
\begin{itemize} |
||||
|
\item σε αναμονή (backlog), περιλαμβάνει tasks τα οποία δεν έχουν ακόμα εισαχθεί σε κάποιο sprint |
||||
|
\item ενεργό sprint (sprint/todo), περιλαμβάνει tasks τα οποία συμμετέχουν στο ενεργό (τωρινό) sprint |
||||
|
\item εκτέλεση (in progress/doing), περιλαμβάνει tasks για τα οποία έχει ξεκινήσει η ανάπτυξη από κάποιο μέλος της ομάδας |
||||
|
\item έλεγχος και αξιολόγησης (testing/code review), περιλαμβάνει tasks των οποίων η ανάπτυξη έχει ολοκληρωθεί και βρίσκονται στο στάδιο ελέγχου (testing) ή αναμονής σε pull request |
||||
|
\item ολοκλήρωση (done), περιλαμβάνει tasks τα οποία έχουν τελειώσει, δηλαδή των οποίων η ανάπτυξη έχει ολοκληρωθεί και το pull request έχει γίνει merge |
||||
|
\end{itemize} |
||||
|
|
||||
|
Τέλος, ορίστηκαν στις λίστες οι μέγιστοι αριθμοί tasks που μπορούν τα υπάρχουν σε κάθε χρονική στιγμή. Για παράδειγμα, μέχρι τέσσερα tasks στην λίστα εκτέλεσης. Αυτό έγινε για ενθάρρυνση της ολοκλήρωσης των tasks από τα μέλη, σε αντίθεση με την εγκατάλειψή τους σε ημιτελή κατάσταση της ανάπτυξης για την ανάληψη κάποιου νέου task. |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.8\textwidth]{assets/figures/chapter-4/4.2.implementation-methodology-kanban.png} |
||||
|
\caption{Στιγμιότυπο οθόνης της διαδικτυακής υπηρεσίας Trello που χρησιμοποιήθηκε για την υλοποίηση του Scrum} |
||||
|
\label{figure:4.2.implementation-methodology-kanban} |
||||
|
\end{figure} |
||||
|
|
||||
|
Κατά την διαδικασία της ανάπτυξης του κώδικα, εφαρμόστηκαν επίσης οι τακτικές που ορίζονται από το DevOps σε ό,τι αφορά το deployment των υπηρεσιών. Το DevOps ορίζει διάφορα εργαλεία που αποσκοπούν στην απρόσκοπτη, αυτοματοποιημένη και γρήγορα ενσωμάτωση του κώδικα από το στάδιο της συγγραφής μέχρι την ολοκλήρωση και εγκατάσταση. Τα εργαλεία που χρησιμοποιήθηκαν εδώ είναι: |
||||
|
|
||||
|
\begin{itemize} |
||||
|
\item συνεχής έλεγχος (continuous testing) |
||||
|
\item συνεχής ολοκλήρωση (continuous integration) |
||||
|
\item συνεχής παράδοση (continuous delivery) |
||||
|
\item συνεχής εγκατάσταση (continuous deployment) |
||||
|
\end{itemize} |
||||
|
|
||||
|
Για την υλοποίηση των τακτικών αυτών επιλέχθηκε μετά από εκτενή έρευνα η πλατφόρμα Jenkins. Το Jenkins συνδυάστηκε με την πλατφόρμα εικονοποίησης Docker ώστε να ακολουθηθούν οι τελευταίες ενδεδειγμένες πρακτικές της βιομηχανίας. Έγινε συγγραφή του αρχείου Jenkinsfile το οποίο περιγράφει με κώδικα την ροή εργασιών (pipeline) που πρέπει να ακολουθηθεί μετά από κάθε αλλαγή στον κώδικα. Η εκτέλεση του pipeline πραγματοποιείται αυτόματα από το Jenkins. |
||||
|
|
||||
|
Το pipeline αποτελείται από στάδια και βήματα τα οποία φαίνονται στο σχήμα \ref{figure:4.2.implementation-methodology-jenkins-pipeline}: |
||||
|
|
||||
|
\begin{enumerate} |
||||
|
\item Αρχικά εκτελείται το βήμα "Version", το οποίο συλλέγει στοιχεία σχετικά με την εκτέλεση του pipeline όπως το κλαδί του κώδικα που πυροδότησε τη ροή και ποια από τα πακέτα λογισμικού που περιλαμβάνονται στο git repository περιέχουν αλλαγές. |
||||
|
\item Έπειτα εκτελείται το στάδιο "TEST" το οποίο περιέχει δύο βήματα που εκτελούνται παράλληλα και πραγματοποιούν έλεγχο του κώδικα των πακέτων. |
||||
|
\item Αν το κλαδί πυροδότησης είναι ένα feature branch η ροή σταματά εδώ, ενώ αν πρόκειται για ένα από τα βασικά κλαδιά (master ή develop) τότε η ροή συνεχίζει με το στάδιο "BUILD" στο οποίο εκτελούνται παράλληλα τα βήματα που χτίζουν τα docker images των πακέτων εκείνων τα οποία περιέχουν αλλαγές. |
||||
|
\item Στο στάδιο "PUBLISH", αν το κλαδί πυροδότησης είναι το κύριο κλαδί παραγωγής (master), τότε εκτελούνται παράλληλα βήματα τα οποία δημοσιεύουν τα docker images που δημιουργήθηκαν στο αποθετήριο Dockerhub. |
||||
|
\item Τέλος, εκτελείται το στάδιο "DEPLOY", κατά το οποίο πραγματοποιείται η εγκατάσταση των υπηρεσιών στο ανάλογο περιβάλλον, staging για το κλαδί develop και production για το κλαδί master. |
||||
|
\end{enumerate} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.8\textwidth]{assets/figures/chapter-4/4-2-implementation-methodology-jenkins-pipeline.png} |
||||
|
\caption{Διάγραμμα ροής εργασιών Jenkins} |
||||
|
\label{figure:4.2.implementation-methodology-jenkins-pipeline} |
||||
|
\end{figure} |
||||
|
|
||||
|
Με την χρήση του Jenkins αυτοματοποιείται με μεγάλη ευκολία ένα σημαντικό μέρος των διαδικασιών ανάπτυξης και δημοσίευσης του κώδικα. Με την χρήση του συγκεκριμένου pipeline γίνεται σίγουρο ό,τι σε κάθε αλλαγή, ασχέτως του κλαδιού ανάπτυξης ο κώδικας ελέγχεται και τα αποτελέσματα των tests είναι αποθηκευμένα και διαθέσιμα για ανάλυση. Ακόμα, για το κλαδί develop, αυτοματοποιείται η ολοκλήρωση των πακέτων και η εγκατάστασή τους σε περιβάλλον δοκιμής (staging), γεγονός που διευκολύνει σημαντικά τις συλλογικές δοκιμές από την ομάδα σε διαφορετικά περιβάλλοντα χρήσης (browsers). Τέλος, για το κλαδί master, αυτοματοποιείται η διαδικασία δημοσίευσης των docker images, μηδενίζοντας έτσι τον χρόνο που πρέπει να καταβάλουν τα μέλη της ομάδας σε αυτό. |
||||
|
|||||
@ -1 +1,8 @@ |
|||||
\section{Τεχνολογίες υλοποίησης} |
\section{Τεχνολογίες υλοποίησης} \label{subsection:4-3-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} |
||||
|
|||||
@ -0,0 +1,9 @@ |
|||||
|
\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} |
||||
@ -0,0 +1,9 @@ |
|||||
|
\subsubsection{Node.js} \label{subsection:4-3-1-1-node.js} |
||||
|
|
||||
|
\logo{chapter-4/4.3.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 είναι ο ενσωματωμένος διαχειριστής πακέτων του, ο οποίος ονομάζεται npm. Με τον npm γίνεται εφικτή η εγκατάσταση πακέτων (βιβλιοθηκών) από το μητρώο npm (npm registry\footnote{\url{https://www.npmjs.com/}}), καθώς και η οργάνωση και η διαχείρισή τους στα πλαίσια της ανάπτυξης μίας εφαρμογής που εξαρτάται από αυτά. |
||||
|
|
||||
|
Το Node.js έχει το αποθετήριό του στο GitHub (\url{https://github.com/nodejs/node}). |
||||
@ -0,0 +1,15 @@ |
|||||
|
\subsubsection{Docker} \label{subsection:4-3-1-2-docker} |
||||
|
|
||||
|
\logo{chapter-4/4.3.docker-logo}{Docker logo} |
||||
|
|
||||
|
Το Docker αποτελεί μία πλατφόρμα η οποία παρέχει λογισμικό εικονοποίησης (virtualization) στο επίπεδο του λειτουργικού συστήματος καθώς και ολοκληρωμένα συστήματα διαμοιρασμού και εκτέλεσης των παραγόμενων εικόνων. |
||||
|
|
||||
|
Δίνει την δυνατότητα σύνθεσης εικονικών περιβαλλόντων λειτουργικού συστήματος τα οποία ονομάζονται εικόνες (images). Μέσα στις εικόνες είναι δυνατή η εκτέλεση προγραμμάτων σε ασφαλή, απομονωμένα και προβλέψιμα περιβάλλοντα τα οποία εγγυούνται τις ίδιες συνθήκες εκτέλεσης παντού. Έτσι, οι προγραμματιστές δεν χρειάζεται να ανησυχούν για το περιβάλλον εκτέλεσης του κώδικα και την ρύθμιση των παραμέτρων σε κάθε ξεχωριστή εγκατάσταση. |
||||
|
|
||||
|
Ταυτόχρονα, η πλατφόρμα του Docker παρέχει συστήματα και τυποποιημένες μεθόδους για το πακετάρισμα των εικόνων, την μεταφόρτωση και την εκτέλεσή τους σε απομακρυσμένα συστήματα. Με αυτό τον τρόπο αποτελεί πολύτιμο εργαλείο το οποίο έχει γίνει το στάνταρ στη βιομηχανία λογισμικού για τον διαμοιρασμό και την εγκατάσταση ολοκληρωμένων εφαρμογών σε περιβάλλοντα δοκιμής (staging environments) και παραγωγής (production environment). |
||||
|
|
||||
|
Τέλος, η δυνατότητα τοπικής εκτέλεσης των εικόνων στο σύστημα ανάπτυξης του κώδικα δίνει την ευκαιρία ελέγχου (testing) και αποσφαλμάτωσης (debug) τοπικά σε ένα περιβάλλον ίδιο με αυτό της εκτέλεσης. Αυτό είναι εξαιρετικά σημαντικό επειδή αποκλείει τυχών μεταβολές στην πορεία εκτέλεσης του προγράμματος που μπορεί να έρχονταν από την εκτέλεση σε ένα διαφορετικό περιβάλλον. |
||||
|
|
||||
|
% example citations |
||||
|
% Merkel, Dirk. “Docker: Lightweight Linux Containers for Consistent Development and Deployment.” Linux Journal, vol. 2014, no. 239, 2014, p. 2. |
||||
|
% Anderson, Charles. “Docker [Software Engineering].” IEEE Software, vol. 32, no. 3, 2015. |
||||
@ -0,0 +1,14 @@ |
|||||
|
\subsubsection{Jenkins} \label{subsection:4-3-1-3-jenkins} |
||||
|
|
||||
|
\logo{chapter-4/4.3.jenkins-logo}{Jenkins logo} |
||||
|
|
||||
|
Το Jenkins είναι ένας πλήρως παραμετροποιήσιμος και επεκτάσιμος διακομιστής αυτοματοποίησης (automation server). Ο διακομιστής μπορεί να αυτοματοποιήσει τις διαδικασίες ελέγχου, ολοκλήρωσης, παράδοσης και εγκατάστασης του κώδικα, υλοποιώντας έτσι βασικές διαδικασίες που ορίζει το DevOps, συνεχή έλεγχο (continuous testing), συνεχή ολοκλήρωση (continuous integration), συνεχή παράδοση (continuous delivery) και συνεχή εγκατάσταση (continuous deployment). Επίσης, το Jenkins μπορεί να παραμετροποιηθεί μέσω των ρυθμίσεων που προσφέρει και των επεκτάσεων (plugins) που υπάρχουν ώστε να παρέχει τις δυνατότητες αυτές για οποιαδήποτε πλατφόρμα, γλώσσα και περιβάλλον ανάπτυξης. |
||||
|
|
||||
|
Στο Jenkins είναι δυνατός ο ορισμός με χρήση κώδικα (σε Groovy και στο DSL που παρέχεται από το Jenkins) πολλαπλών γραμμών εργασιών (pipeline). Οι γραμμές εργασιών συντίθενται από πολλαπλά βήματα τα οποία επιτελούν ξεχωριστούς στόχους προς το τελικό αποτέλεσμα της γραμμής. Τα βήματα μπορούν να τρέχουν σειριακά ή παράλληλα. Ενώ δίνεται η δυνατότητα εκτέλεσης σε πολλαπλά, διανεμημένα συστήματα καθώς και άλλες προχωρημένες λειτουργικότητες. |
||||
|
|
||||
|
Το Jenkins συνδυάζεται αποτελεσματικά με την πλατφόρμα του Docker που περιγράφηκε προηγουμένως. Μέσω του συνδυασμού δίνεται η ευκαιρία της αυτοματοποίησης του μεγαλύτερου μέρους του DevOps σε ένα απολύτως προβλέψιμο περιβάλλον το οποίο παραμένει σταθερό από την ανάπτυξη του κώδικα μέχρι την τελική εγκατάσταση. Με αυτή την μέθοδο βελτιώνεται σημαντικά η αποτελεσματικότητα των ομάδων ανάπτυξης κώδικα. |
||||
|
|
||||
|
% example citations |
||||
|
% Shahin, Mojtaba, et al. “Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices.” IEEE Access, vol. 5, 2017, pp. 3909–3943. |
||||
|
% Meyer, Mathias. “Continuous Integration and Its Tools.” IEEE Software, vol. 31, no. 3, 2014, pp. 14–16. |
||||
|
% Virmani, Manish. “Understanding DevOps & Bridging the Gap from Continuous Integration to Continuous Delivery.” Fifth International Conference on the Innovative Computing Technology (INTECH 2015), 2015, pp. 78–82. |
||||
@ -0,0 +1,9 @@ |
|||||
|
\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} |
||||
@ -0,0 +1,11 @@ |
|||||
|
\subsubsection{React} \label{subsection:4-3-2-1-react} |
||||
|
|
||||
|
\logo{chapter-4/4.3.react-logo}{React logo} |
||||
|
|
||||
|
Η React\footnote{\url{https://reactjs.org/}} αποτελεί βιβλιοθήκη Javascript, η οποία χρησιμοποιείται για την κατασκευή διεπαφών χρήστη. Είναι δηλωτική (declarative) και βασίζεται σε components, τα οποία διαχειρίζονται την κατάστασή τους (state) και συντίθενται για να δημιουργήσουν πολύπλοκα διαδραστικά UIs. |
||||
|
|
||||
|
%TODO: When https://2021.stateofjs.com/en-US/ is available, add to the paragraph above that is the most popular js front-end framework (by usage), according to https://2020.stateofjs.com/en-US/technologies/front-end-frameworks/ and also add this beautiful chart. |
||||
|
|
||||
|
Ένα σημαντικό εργαλείο για την ταχεία ανάπτυξη web εφαρμογών σε React είναι το Create React App\footnote{\url{https://create-react-app.dev/}}. Με τη χρήση μίας και μόνο εντολής (\texttt{npx create-react-app my-app}), εγκαθίσταται αυτόματα ένας development server σε περιβάλλον Node.js (ως μία μοναδική βιβλιοθήκη). Αυτός εμπεριέχει μία πληθώρα από build tools (π.χ. Webpack, Babel, ESLint), τα οποία προσφέρουν ισχυρές δυνατότητες, όπως άμεσα reloads και παραγωγή βελτιστοποιημένων bundles. Έτσι, η διαδικασία της υλοποίησης αποκτά ποικίλες διευκολύνσεις, χωρίς να απαιτεί την εκμάθηση, την χειροκίνητη εγκατάσταση και την προηγμένη διαμόρφωση των τεχνολογιών στο εσωτερικό. |
||||
|
|
||||
|
Η React έχει το αποθετήριό της στο GitHub (\url{https://github.com/facebook/react/}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/react}). |
||||
@ -0,0 +1,27 @@ |
|||||
|
\subsubsection{Redux} \label{subsection:4-3-2-1-redux} |
||||
|
|
||||
|
\logo{chapter-4/4.3.redux-logo}{Redux logo} |
||||
|
|
||||
|
Το Redux\footnote{\url{https://redux.js.org/}} αποτελεί μία βιβλιοθήκη Javascript, η χρήση της οποίας προσφέρει στην εφαρμογή ένα πλήρως διαχειρίσιμο global state. |
||||
|
|
||||
|
%TODO: When https://2021.stateofjs.com/en-US/ is available, add to the paragraph above that is the most popular data layer technology (by usage), according to https://2020.stateofjs.com/en-US/technologies/datalayer/ and also add this beautiful chart. |
||||
|
|
||||
|
|
||||
|
Τα δομικά στοιχεία του Redux είναι τα εξής: |
||||
|
\begin{itemize} |
||||
|
\item \textbf{Actions}: Αντικείμενα τα οποία περιέχουν νέα πληροφορία για την τροποποίηση του state της εφαρμογής. |
||||
|
\item \textbf{Reducers}: Συναρτήσεις οι οποίες λαμβάνοντας ένα action και διαβάζοντας το τρέχον state, εφαρμόζουν κάποια λογική για την παραγωγή ενός νέου state. |
||||
|
\item \textbf{Store}: Το αντικείμενο στο οποίο βρίσκεται αποθηκευμένο το state της εφαρμογής. Η βασική ιδιότητα του state είναι ότι παραμένει αμετάβλητο και, για την ανανέωσή του, παράγεται πάντα ένα νέο state object μέσω των reducer. |
||||
|
\item \textbf{Middleware}: Προαιρετικά κομμάτια κώδικα που λαμβάνουν actions πριν εκείνα φτάσουν στους reducers και εκτελούν κάποιο side effect. Συνήθως χρησιμοποιούνται για ενέργειες όπως logging και error reporting ή για να ενώσουν το Redux με εξωτερικά APIs. |
||||
|
\end{itemize} |
||||
|
|
||||
|
Αν και το ίδιο το Redux είναι μικροσκοπικό σε μέγεθος, ο τρόπος υλοποίησής του έχει επιτρέψει τη δημιουργία ενός τεράστιου οικοσυστήματος εργαλείων και επεκτάσεων, τα οποία συνδέονται μαζί του ή βασίζονται σε αυτό. Για παράδειγμα, μία από τις κύριες χρήσεις του είναι η κατασκευή διεπαφών χρήστη σε συνδύασμό με άλλες βιβλιοθήκες, όπως με την React. Σε αυτήν την περίπτωση, συνδέεται μαζί της με το npm πακέτο \texttt{react-redux} και η λειτουργία του υπό ανάπτυξη UI προκύπτει ως εξής: |
||||
|
|
||||
|
%TODO: Add proper diagram |
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.75\textwidth]{assets/figures/chapter-4/4.3.react-redux} |
||||
|
\caption{Λειτουργία του Redux σε συνδυασμό με React} |
||||
|
\end{figure} |
||||
|
|
||||
|
Το Redux έχει το αποθετήριό του στο GitHub (\url{https://github.com/reduxjs/redux}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/redux}). |
||||
@ -0,0 +1,7 @@ |
|||||
|
\subsubsection{Redux-Saga} \label{subsection:4-3-2-3-redux-saga} |
||||
|
|
||||
|
\logo{chapter-4/4.3.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 της εφαρμογής. |
||||
|
|
||||
|
Το Redux-Saga έχει το αποθετήριό του στο GitHub (\url{https://github.com/redux-saga/redux-saga}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/redux-saga}). |
||||
@ -0,0 +1,6 @@ |
|||||
|
\subsection{Τεχνολογίες σχετικές με το Ethereum} \label{subsection:4-3-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} |
||||
@ -0,0 +1,11 @@ |
|||||
|
\subsubsection{Truffle} \label{subsection:4-3-3-1-truffle} |
||||
|
|
||||
|
\logo{chapter-4/4.3.truffle-logo}{Truffle logo} |
||||
|
|
||||
|
Το Truffle\footnote{\url{https://trufflesuite.com/truffle/}} είναι ένα από τα δημοφιλέστερα Ethereum development frameworks και αποτελεί τμήμα της σουίτας Truffle. |
||||
|
|
||||
|
Μέσω του Truffle πραγματοποιείται η διαχείριση των έξυπνων συμβολαίων. Αυτή περιλαμβάνει τη δοκιμή, τη σύνδεση και τη μεταγλώττισή τους, καθώς και την ανάπτυξη τους στο blockchain. |
||||
|
|
||||
|
Επίσης, το Truffle περιέχει πρόσθετα σχετικά εργαλεία, όπως διαδραστική κονσόλα για άμεση αλληλεπίδραση με τα contracts και εκτελεστής εξωτερικών σεναρίων (external script runner). |
||||
|
|
||||
|
Έχει το αποθετήριό του στο GitHub (\url{https://github.com/trufflesuite/truffle}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/truffle}). |
||||
@ -0,0 +1,21 @@ |
|||||
|
\subsubsection{Ganache} \label{subsection:4-3-3-2-ganache} |
||||
|
|
||||
|
\logo{chapter-4/4.3.ganache-logo}{Ganache logo} |
||||
|
|
||||
|
Το Ganache\footnote{\url{https://trufflesuite.com/ganache/}} είναι ένα λογισμικό που παρέχει ένα βοηθητικό προσωπικό Ethereum blockchain για ταχεία ανάπτυξη αποκεντρωμένων εφαρμογών και αποτελεί επίσης τμήμα της σουίτας Truffle. Διατίθεται τόσο ως desktop εφαρμογή με UI, όσο και ως CLI (command-line interface). |
||||
|
|
||||
|
To Ganache παρέχει ισχυρά εργαλεία για την ανάπτυξη έξυπνων συμβολαίων, όπως: |
||||
|
\begin{itemize} |
||||
|
\item Block explorer, μέσω του οποίου μπορούν να εξεταστούν λεπτομερώς όλα τα blocks και οι συναλλαγές που έλαβαν χώρα. |
||||
|
\item Εξρεύνηση των εσωτερικών των contracts και των πυροδοτημένων event τους. |
||||
|
\item Ενδελεχές αρχείο καταγραφής της εξόδου του blockchain, το οποίο περιλαμβάνει σημαντικές πληροφορίες για τον εντοπισμό σφαλμάτων. |
||||
|
\item Δυνατότητα διαμόρφωσης του χρόνου εξόρυξης των block, έτσι ώστε να αρμόζει με τις εκάστοτε ανάγκες (αυτόματη εξόρυξη ή εξόρυξη σε προσαρμοσμένο χρονικό διάστημα). |
||||
|
\end{itemize} |
||||
|
|
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.95\textwidth]{assets/figures/chapter-4/4.3.ganache-gui} |
||||
|
\caption{Ganache (desktop εφαρμογή)} |
||||
|
\end{figure} |
||||
|
|
||||
|
Το Ganache έχει το αποθετήριό του στο GitHub (\url{https://github.com/trufflesuite/ganache}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/ganache}). |
||||
@ -0,0 +1,7 @@ |
|||||
|
\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,0 +1,7 @@ |
|||||
|
\subsubsection{js-ipfs} \label{subsection:4-3-4-1-js-ipfs} |
||||
|
|
||||
|
\logo{chapter-4/4.3.js-ipfs-logo}{js-ipfs logo} |
||||
|
|
||||
|
H υλοποίηση του IPFS που χρησιμοποείται στην εφαρμογή Concordia είναι αυτή σε Javascript και ονομάζεται js-ipfs. Μέσω αυτής της βιβλιοθήκης, παρέχεται η δυνατότητα δημιουργίας ενός IPFS κόμβου, τόσο σε έναν Node.js server, όσο και σε ένα περιβάλλον browser. |
||||
|
|
||||
|
Το js-ipfs έχει το αποθετήριό του στο GitHub (\url{https://github.com/ipfs/js-ipfs}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/ipfs}). |
||||
@ -0,0 +1,9 @@ |
|||||
|
\subsubsection{Libp2p} \label{subsection:4-3-4-3-libp2p} |
||||
|
|
||||
|
\logo{chapter-4/4.3.libp2p-logo}{Libp2p logo} |
||||
|
|
||||
|
Η libp2p είναι ένα αρθρωτό σύστημα πρωτοκόλλων, προδιαγραφών και βιβλιοθηκών που επιτρέπουν την ανάπτυξη p2p εφαρμογών. Αποτελεί το υποκείμενο επίπεδο δικτύου του IPFS.\ref{2.7-ipfs-docs} |
||||
|
|
||||
|
Ένα από τα υλοποιημένα πρωτόκολλα μεταφοράς δεδομένων της libp2p είναι το libp2p-webrtc-star\footnote{\url{https://github.com/libp2p/js-libp2p-webrtc-star}}. Αποτελεί το πρωτόκολλο μεταφοράς δεδομένων της εφαρμογής, καθώς υποστηρίζεται τόσο από Node.js servers, όσο και από browsers. Περιλαμβάνει, επίσης, έναν signalling server, που επιτρέπει τη γρήγορη διασύνδεση των peers. |
||||
|
|
||||
|
Το libp2p-webrtc-star έχει το αποθετήριό του στο GitHub (\url{https://github.com/libp2p/js-libp2p-webrtc-star}) και διατίθεται μέσω του μητρώου npm (\url{https://www.npmjs.com/package/libp2p-webrtc-star}). |
||||
@ -1 +1 @@ |
|||||
\section{Διαφορές σχεδιασμού-υλοποίησης} |
\section{Διαφορές σχεδιασμού-υλοποίησης} \label{section:4-5-design-implementation-differen} |
||||
@ -1,6 +1,4 @@ |
|||||
\chapter{Συμπεράσματα} |
\chapter{Συμπεράσματα}\label{chapter:5-conclusions} |
||||
|
|
||||
\input{chapters/5.conclusions/5.1.problems-faced} |
\input{chapters/5.conclusions/5.1.open-areas} |
||||
\input{chapters/5.conclusions/5.2.design-implementation-differences} |
\input{chapters/5.conclusions/5.2.conclusion} |
||||
\input{chapters/5.conclusions/5.3.open-areas} |
|
||||
\input{chapters/5.conclusions/5.4.conclusion} |
|
||||
|
|||||
@ -0,0 +1,8 @@ |
|||||
|
\section{Ανοιχτά θέματα} |
||||
|
|
||||
|
TODO: add |
||||
|
1. feeless |
||||
|
2. reputation system |
||||
|
3. voting types |
||||
|
4. token distribution |
||||
|
5. ethereum, ipfs, move to proof of stake, remove of rendezvous server |
||||
@ -1 +0,0 @@ |
|||||
\section{Ανοιχτά θέματα} |
|
||||
@ -0,0 +1,7 @@ |
|||||
|
\newcommand{\logo}[2]{ |
||||
|
\begin{figure}[H] |
||||
|
\centering |
||||
|
\includegraphics[width=.12\textwidth]{assets/figures/#1} |
||||
|
\caption{#2} |
||||
|
\end{figure} |
||||
|
} |
||||
@ -0,0 +1,6 @@ |
|||||
|
% Command taken from this stackexchange answer |
||||
|
% https://tex.stackexchange.com/a/96913 |
||||
|
\newcommand{\spheading}[3]{\rotatebox{#1}{\parbox{#2}{\raggedright #3}}} |
||||
|
|
||||
|
% Usage: |
||||
|
% \spheading[<degrees_rotation>][<width>]{<stuff>} |
||||
@ -0,0 +1,9 @@ |
|||||
|
\newcommand{\sysReqItem}[7] { |
||||
|
\item #1 \ #2 |
||||
|
\begin{itemize}[label={}, leftmargin=0pt] |
||||
|
\item \textbf{Περιγραφή}: #3 |
||||
|
\item \textbf{User Priority (#4/5)}: #5 |
||||
|
\item \textbf{Technical Priority (#6/5)}: #7 |
||||
|
\end{itemize} |
||||
|
\medskip |
||||
|
} |
||||
@ -0,0 +1,61 @@ |
|||||
|
\newcommand{\useCaseTable}[8] {{ |
||||
|
\begin{table}[H] |
||||
|
\begin{center} |
||||
|
\begin{tabularx}{\textwidth}{l X} |
||||
|
\toprule |
||||
|
\multicolumn{2}{c}{\textbf{#1}} \\ [0.5ex] |
||||
|
\midrule |
||||
|
Σύντομη περιγραφή & #2 \\ [0.5ex] |
||||
|
Αναφορά ΛΑ & #3 \\ [0.5ex] |
||||
|
Αναφορά ΜΛΑ & #4 \\ [0.5ex] |
||||
|
Πυροδότηση δραστηριότητας & #5 \\ [0.5ex] |
||||
|
Προϋπόθεση & #6 \\ [0.5ex] |
||||
|
\bottomrule |
||||
|
\end{tabularx} |
||||
|
\end{center} |
||||
|
\caption{#7} |
||||
|
#8 |
||||
|
\end{table} |
||||
|
}} |
||||
|
|
||||
|
\newcommand{\useCaseBaseFlowTable}[4] {{ |
||||
|
\begin{table}[H] |
||||
|
\begin{center} |
||||
|
\begin{tabularx}{\textwidth}{p{2.25cm} X X} |
||||
|
\toprule |
||||
|
\multicolumn{3}{c}{\textbf{Βασική ροή}} \\ [0.5ex] |
||||
|
\midrule |
||||
|
\textbf{Γραμμή} & \textbf{Ενέργεια χρήστη συστήματος} & \textbf{Απάντηση Συστήματος} \\ [0.5ex] |
||||
|
\midrule |
||||
|
#1 |
||||
|
\midrule |
||||
|
\textbf{Μετέπειτα κατάσταση:} & \multicolumn{2}{p{\dimexpr\textwidth-2\tabcolsep-0.8pt-2.25cm}}{#2} \\ [0.5ex] |
||||
|
\bottomrule |
||||
|
\end{tabularx} |
||||
|
\end{center} |
||||
|
\caption{#3} |
||||
|
#4 |
||||
|
\end{table} |
||||
|
}} |
||||
|
|
||||
|
\newcommand{\useCaseAlternateFlowTable}[7] {{ |
||||
|
\begin{table}[H] |
||||
|
\begin{center} |
||||
|
\begin{tabularx}{\textwidth}{l X X} |
||||
|
\toprule |
||||
|
\multicolumn{3}{l}{\textbf{Εναλλακτική ροή {#1}:} {#2}} \\ [0.5ex] |
||||
|
\midrule |
||||
|
\multicolumn{3}{p{\dimexpr\textwidth-2\tabcolsep-0.8pt}}{{#3}} \\ [0.5ex] |
||||
|
\midrule |
||||
|
\textbf{Γραμμή} & \textbf{Ενέργεια χρήστη συστήματος} & \textbf{Απάντηση Συστήματος} \\ [0.5ex] |
||||
|
\midrule |
||||
|
#4 \\ [0.5ex] |
||||
|
\midrule |
||||
|
\multicolumn{3}{p{\dimexpr\textwidth-2\tabcolsep-0.8pt}}{{#5}} \\ [0.5ex] |
||||
|
\bottomrule |
||||
|
\end{tabularx} |
||||
|
\end{center} |
||||
|
\caption{#6} |
||||
|
#7 |
||||
|
\end{table} |
||||
|
}} |
||||
@ -1,2 +0,0 @@ |
|||||
Contents |
|
||||
- *carbon-config.json*: A configuration file for https://carbon.now.sh/ |
|
||||
@ -1 +0,0 @@ |
|||||
{"paddingVertical":"0px","paddingHorizontal":"0px","backgroundImage":null,"backgroundImageSelection":null,"backgroundMode":"color","backgroundColor":"rgba(0,0,0,0)","dropShadow":true,"dropShadowOffsetY":"20px","dropShadowBlurRadius":"68px","theme":"material","windowTheme":"none","language":"javascript","fontFamily":"Hack","fontSize":"14px","lineHeight":"133%","windowControls":false,"widthAdjustment":false,"lineNumbers":false,"firstLineNumber":1,"exportSize":"2x","watermark":false,"squaredImage":false,"hiddenCharacters":false,"name":"","width":915} |
|
||||
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue