Edit chapters 3 and 4

thesis.tex

@@ -336,7 +336,7 @@ ContestWebServer. Εκεί βλέπουν για κάθε πρόβλημα τη
 \begin{figure}
   \centering
   \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/cmscontestant.png}
-  \caption[Οθόνη προβλήματος CMS]{Η οθόνη ενός προβλήματος, όπως τη βλέπει ένας
+  \caption[Σελίδα προβλήματος CMS]{Η σελίδα ενός προβλήματος, όπως τη βλέπει ένας
   διαγωνιζόμενος. Διακρίνονται τα στοιχεία του προβλήματος και όλα τα
   επισυναπτόμενα. Πηγή: https://cms-dev.github.io/screenshots.html}
 \end{figure}
@@ -344,15 +344,15 @@ ContestWebServer. Εκεί βλέπουν για κάθε πρόβλημα τη
 \begin{figure}
   \centering
   \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/cmsranking.png}
-  \caption[Οθόνη βαθμολογιών CMS]{Η οθόνη της βαθμολογίας, με τη συνολική κατάταξη
+  \caption[Σελίδα βαθμολογιών CMS]{Η σελίδα της βαθμολογίας, με τη συνολική κατάταξη
   και ανά διαγωνιζόμενο σε όλα τα προβλήματα. Πηγή: https://cms-dev.github.io/screenshots.html}
 \end{figure}
 
 \begin{figure}
   \centering
   \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/cmsadmin.png}
-  \caption[Οθόνη διαχείρισης διαγωνισμού CMS]{Η οθόνη της διαχείρισης ενός
-  διαγωνισμού.  Διακρίνονται συνολικά στατιστικά για τις υποβολές, η κατάσταση
+  \caption[Σελίδα διαχείρισης διαγωνισμού CMS]{Η σελίδα της διαχείρισης ενός
+  διαγωνισμού. Διακρίνονται συνολικά στατιστικά για τις υποβολές, η κατάσταση
   της ουράς και των Workers. Πηγή: https://cms-dev.github.io/screenshots.html}
 \end{figure}
 
@@ -420,7 +420,7 @@ code golf, δηλαδή επίτευξης της λύσης με το λιγό
 χρειάζεται μόνο το περιβάλλον της Java και το λογισμικό του εξυπηρετητή. Μόλις
 γίνει αυτό, μπορούν να στηθούν επίσης επιπλέον κόμβοι εάν είναι επιθυμητό,
 τοπικά ή απομακρυσμένα. Η δημιουργία των διαγωνισμών και των προβλημάτων
-γίνεται μέσω της δικτυακής διεπαφής του Διαχειριστή.
+γίνεται μέσω της διαδικτυακής διεπαφής του Διαχειριστή.
 
 \bigskip
 
@@ -441,14 +441,14 @@ code golf, δηλαδή επίτευξης της λύσης με το λιγό
 \begin{figure}
   \centering
   \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/mooshakproblem.png}
-  \caption[Οθόνη προβλήματος Mooshak]{Η οθόνη παρουσίασης ενός προβλήματος για τους
+  \caption[Σελίδα προβλήματος Mooshak]{Η σελίδα παρουσίασης ενός προβλήματος για τους
   διαγωνιζόμενους στο σύστημα Mooshak.}
 \end{figure}
 
 \begin{figure}
   \centering
   \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/mooshakrankings.png}
-  \caption[Οθόνη βαθμολογίας Mooshak]{Η οθόνη βαθμολογίας όλων των διαγωνιζόμενων
+  \caption[Σελίδα βαθμολογίας Mooshak]{Η σελίδα βαθμολογίας όλων των διαγωνιζόμενων
   ομάδων σε ένα διαγωνισμό.}
 \end{figure}
 
@@ -499,7 +499,7 @@ University (\cite{Rozhkov}). Χρησιμοποιείται τόσο για με
 περιγραφή και τα απαραίτητα αρχεία ελέγχου.
 
 \lstinputlisting[language=XML,frame=single,captionpos=b,caption=Παράδειγμα xml προβλήματος
-CATS. Το CATS δημιουργεί την οθόνη του προβλήματος και τα χαρακτηριστικά του
+CATS. Το CATS δημιουργεί τη σελίδα του προβλήματος και τα χαρακτηριστικά του
 σύμφωνα με το συγκεκριμένο αρχείο ενώ διαθέτει δυνατότητα παρουσίασης LaTeX
 τύπων\, όπως αυτός στο ProblemConstraints.]{Listings/catsexample.xml}
 
@@ -528,8 +528,8 @@ C\#, Perl, Python, Ruby, PHP, Erlang, Javascript και SQL.
 \begin{figure}
   \centering
   \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/catsproblem.png}
-  \caption[Διατύπωση προβλήματος CATS]{Η οθόνη του προβλήματος στο CATS. Δεν
-  περιέχει τίποτα παραπάνω από τη διατύπωση, αφού η υποβολή γίνεται από την οθόνη
+  \caption[Διατύπωση προβλήματος CATS]{Η σελίδα του προβλήματος στο CATS. Δεν
+  περιέχει τίποτα παραπάνω από τη διατύπωση, αφού η υποβολή γίνεται από τη σελίδα
   του διαγωνισμού. Το σύστημα του CATS επιτρέπει και τη χρήση LaTeX όπως
   φαίνεται στο Restrictions.}
 \end{figure}
@@ -537,28 +537,29 @@ C\#, Perl, Python, Ruby, PHP, Erlang, Javascript και SQL.
 \begin{figure}
   \centering
   \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/catssubmission.png}
-  \caption[Οθόνη διαγωνισμού και υποβολής CATS]{Η οθόνη του διαγωνισμού που
+  \caption[Σελίδα διαγωνισμού και υποβολής CATS]{Η σελίδα του διαγωνισμού που
   περιέχει όλα τα προβλήματα του. Επιλέγοντας ένα πρόβλημα μπορούμε να υποβάλουμε
-  τη λύση στο κάτω μέρος της οθόνης.}
+  τη λύση στο κάτω μέρος της σελίδας.}
 \end{figure}
 
-\FloatBarrier
 
 \chapter{Περιγραφή Grader - Kewii}
 
 Το σύστημα αποτελείται από το το σύστημα αξιολόγησης Kewii, το backend της
-εφαρμογής μας που λειτουργεί ως δαίμονας στον εξυπηρετητή με σκοπό την
-μεταγλώττιση και αξιολόγηση των υποβολών που λαμβάνει, και από τη διαδικτυακή
-εφαρμογή Grader, η οποία αναλαμβάνει την αλληλεπίδραση με χρήστες και
-διαχειριστές, την (έμμεση) επικοινωνία με τον Kewii και τη συνολική υλοποίηση
-της λογικής του συστήματος όσον αφορά στον τρόπο λειτουργίας των επιμέρους
-στοιχείων του και τον τρόπο αξιολόγησης.
+εφαρμογής μας που λειτουργεί ως δαίμονας (πρόγραμμα που τρέχει συνεχώς) στον
+εξυπηρετητή με σκοπό την μεταγλώττιση και αξιολόγηση των υποβολών που λαμβάνει,
+και από τη διαδικτυακή εφαρμογή Grader, η οποία αναλαμβάνει την αλληλεπίδραση
+με χρήστες και διαχειριστές, την (έμμεση) επικοινωνία με τον Kewii και τη
+συνολική υλοποίηση της λογικής του συστήματος όσον αφορά στον τρόπο λειτουργίας
+των επιμέρους στοιχείων του και τον τρόπο αξιολόγησης. Ακολουθεί μια πρώτη
+ανάλυση των δομικών στοιχείων και των αλληλεπιδράσεων τους, πριν αναλυθούν Kewii
+και Grader.
 
 \section{Στοιχεία και έννοιες του συστήματος}
 
-Στην ενότητα αυτή θα περιγραφούν συνοπτικά τα συστατικά στοιχεία του συστήματος
-μας. Η γνώση τους είναι απαραίτητη για να γίνει αντιληπτός ο διαχωρισμός μεταξύ
-Kewii και Grader, δηλαδή backend και frontend.
+Στην ενότητα αυτή θα περιγραφούν συνοπτικά τα επιμέρους στοιχεία του συστήματος
+μας. Η έννοια και η λειτουργία τους είναι απαραίτητη για να γίνει αντιληπτός ο
+διαχωρισμός μεταξύ Kewii και Grader, δηλαδή backend και frontend.
 
 \subsection{Προβλήματα}
 
@@ -571,10 +572,9 @@ Kewii και Grader, δηλαδή backend και frontend.
 
 \bigskip
 
-Τα προβλήματα έχουν νόημα μόνο μέσα σε διαγωνισμούς, καθώς ο διαγωνιζόμενος
-παίρνει μέρος σε διαγωνισμούς που περιέχουν προβλήματα και η τελική βαθμολογία
-του είναι το άθροισμα των επιδόσεων του στα προβλήματα του διαγωνισμού. Η
-αρχική σχεδίαση του συστήματος είχε ως στόχο τη χρήση αυτού σε διαγωνισμούς
+Τα προβλήματα έχουν νόημα αποκλειστικά μέσα σε διαγωνισμούς, καθώς η τελική
+αξιολόγηση αφορά τους διαγωνισμούς και το σύνολο των προβλημάτων που περιέχουν.
+Η αρχική σχεδίαση του συστήματος είχε ως στόχο τη χρήση του σε διαγωνισμούς
 πληροφορικής, οπότε τα προβλήματα είναι συνδεδεμένα στενά τόσο με τον
 διαγωνισμό που ανήκουν όσο και με τις υποβολές που έχουν γίνει σε αυτά. Κάθε
 πρόβλημα μπορεί να ανήκει μόνο σε ένα διαγωνισμό.
@@ -582,27 +582,28 @@ Kewii και Grader, δηλαδή backend και frontend.
 \bigskip
 
 Σε επόμενο κεφάλαιο θα διερευνηθεί και θα περιγραφεί η υλοποίηση ενός εναλλακτικού
-σχεδιασμού που επιτρέπει την χρήση των προβλημάτων σε διάφορους διαγωνισμούς και
+σχεδιασμού που επιτρέπει την χρήση των προβλημάτων σε πολλαπλούς διαγωνισμούς και
 την αλλαγή της σύνδεσης των υποβολών από το πρόβλημα προς τους διαγωνισμούς.
 
 \subsection{Διαγωνισμοί}
 
-Οι διαγωνισμοί αντιστοιχούν σε πραγματικούς διαγωνισμούς, εξετάσεις ή σειρές
+Οι διαγωνισμοί αντιστοιχούν σε διοργανώσεις πληροφορικής, εξετάσεις ή σειρές
 ασκήσεων. Εμπεριέχουν προβλήματα και είναι ενεργοί/ορατοί σε ένα χρονικό
 διάστημα όπου οι διαγωνιζόμενοι μπορούν να υποβάλλουν τις λύσεις τους. Μόλις
 ολοκληρωθεί η διεξαγωγή τους, ο διαχειριστής μπορεί να εκκινήσει την τελική
 αξιολόγηση, κατά την οποία βαθμολογούνται οι ενεργές υποβολές των
 διαγωνιζόμενων σε όλα τα προβλήματα του διαγωνισμού. Οι διαγωνισμοί μπορούν να
-είναι ορατοί μόνο από επιλεγμένους χρήστες ή από όλους.
+είναι ορατοί σε όλους ή μόνο σε επιλεγμένους χρήστες.
 
 \subsection{Αρχεία Ελέγχου}
 
 Τα αρχεία ελέγχου είναι ζευγάρια αρχείων εισόδου και εξόδου και ανήκουν σε
-προβλήματα. Μια σωστή υποβολή/λύση θα πρέπει για κάθε αρχείο εισόδου
-που δέχεται, να παράγει έξοδο ίδια με αυτή του αντίστοιχου αρχείο εξόδου.
-Κάθε αρχείο ελέγχου χαρακτηρίζεται από τον τύπο του, αναφορικά με το πότε
-εκτελείται και αν είναι ορατό στους χρήστες. Οι τύποι εκτέλεσης αντιστοιχούν
-σε χρώματα (tags) και παρουσιάζονται στον Πίνακα 3.1.
+προβλήματα. Μια σωστή υποβολή/λύση θα πρέπει για κάθε αρχείο εισόδου που
+δέχεται, να παράγει έξοδο ίδια με αυτή του αντίστοιχου αρχείου εξόδου.  Κάθε
+αρχείο ελέγχου χαρακτηρίζεται από τους πόντους που αξίζει και από τον τύπο
+εκτέλεσης του, που σχετίζεται με το πότε εκτελείται και αν είναι ορατό στους
+χρήστες. Οι τύποι εκτέλεσης αντιστοιχούν σε χρώματα (tags) και παρουσιάζονται
+στον Πίνακα 3.1.
 
   \begin{table}
     \begin{tabular}{ | l | p{10cm} |}
@@ -624,9 +625,9 @@ Kewii και Grader, δηλαδή backend και frontend.
 
 \bigskip
 
-Σε επόμενο κεφάλαιο θα δημιουργηθεί άλλος ένας τύπος εκτέλεσης. Επιπλέον, θα
+Σε επόμενο κεφάλαιο θα δημιουργηθεί ένας νέος τύπος εκτέλεσης. Επιπλέον, θα
 αλλάξει ριζικά ο τρόπος αξιολόγησης καθώς θα εισαχθεί η έννοια των ομάδων
-αρχείων ελέγχου και τα αρχεία θα έχουν νόημα μόνο μέσα σε αυτές.
+αρχείων ελέγχου και τα αρχεία θα αξιολογούνται μόνο μέσα σε αυτές.
 
 \subsection{Χρήστες/Διαγωνιζόμενοι}
 
@@ -640,7 +641,7 @@ Kewii και Grader, δηλαδή backend και frontend.
 
 \subsection{Υποβολές}
 
-Η υποβολή μιας λύσης εμπεριέχει το "ανέβασμα" του κώδικα του διαγωνιζόμενου για
+Η υποβολή μιας λύσης προϋποθέτει το "ανέβασμα" του κώδικα του διαγωνιζόμενου για
 να γίνει η μεταγλώττιση του στον εξυπηρετητή, να εκτελεστεί από τον Kewii για
 κάθε αρχείο ελέγχου που αντιστοιχεί στο είδος της υποβολής και να αξιολογηθεί η
 ορθότητα της εξόδου. Οι υποβολές χωρίζονται σε δύο κύριες κατηγορίες, την
@@ -648,29 +649,29 @@ Kewii και Grader, δηλαδή backend και frontend.
 κανονικές και εφόσον υπάρχει, για έναν διαγωνιζόμενο, τουλάχιστον μία υποβολή
 που περνάει όλα τα αρχεία ελέγχου στα οποία αξιολογήθηκε, αυτή θεωρείται ενεργή
 για αυτόν. Όταν ολοκληρωθεί η περίοδος ανοιχτών υποβολών ενός διαγωνισμού, όλες
-οι ενεργές υποβολές για κάθε πρόβλημα του διαγωνισμού επαναυποβάλλονται για την
-τελική αξιολόγηση τους.
+οι ενεργές υποβολές για κάθε πρόβλημα του διαγωνισμού επαναυποβάλλονται στον
+Kewii για την τελική αξιολόγηση τους.
 
 \subsection{Προγράμματα Αξιολόγησης}
 
-Οι υποβολές σε κάθε πρόβλημα αξιολογούνται με σύγκριση της εξόδου του υποβληθέντος
-προγράμματος με αυτήν του αρχείου ελέγχου για την αντίστοιχη είσοδο. Εξαίρεση σε
-αυτό τον τρόπο αξιολόγησης, αποτελούν τα προβλήματα που διαθέτουν το δικό τους
-πρόγραμμα αξιολόγησης το οποίο αναλαμβάνει να συγκρίνει την αναμενόμενη έξοδο
-με αυτήν που παρήγαγε το υποβληθέν πρόγραμμα και να βαθμολογήσει αυτή την έξοδο
-στην κλίμακα [0, 1]. Το πρόγραμμα αξιολόγησης είναι και αυτό αποθηκευμένο στον
-εξυπηρετητή και μεταγλωττίζεται και εκτελείται από τον Kewii.
-
+Οι υποβολές σε κάθε πρόβλημα αξιολογούνται συνήθως με σύγκριση της εξόδου του
+υποβληθέντος προγράμματος με αυτήν του αρχείου ελέγχου για την αντίστοιχη
+είσοδο. Εξαίρεση σε αυτό αποτελεί η δυνατότητα που παρέχει ο Kewii για ορισμό
+ενός ειδικού προγράμματος αξιολόγησης στο πρόβλημα το οποίο αναλαμβάνει να
+συγκρίνει την αναμενόμενη έξοδο με αυτήν που παρήγαγε το υποβληθέν πρόγραμμα
+και να βαθμολογεί στην κλίμακα [0, 1]. Το πρόγραμμα αξιολόγησης είναι και αυτό
+αποθηκευμένο στον εξυπηρετητή και μεταγλωττίζεται και εκτελείται κατά τη
+διαδικασία αξιολόγησης.
 
 \section{Σύστημα αξιολόγησης Kewii}
 
-Ο Kewii είναι μια εφαρμογή γραμμένη σε γλώσσα C και τρέχει στον εξυπηρετητή
-ελέγχοντας διαρκώς για νέες υποβολές. Για κάθε νέα υποβολή που εντοπίζει,
+Ο Kewii είναι μια εφαρμογή γραμμένη στη γλώσσα C και τρέχει στον εξυπηρετητή
+ελέγχοντας διαρκώς για την ύπαρξη νέων υποβολών. Για κάθε νέα υποβολή που εντοπίζει,
 βρίσκει τον πηγαίο κώδικα που έχει αποθηκευτεί από τον Grader μαζί με συγκεκριμένα
 μεταδεδομένα, μεταγλωττίζει τον κώδικα δημιουργώντας το εκτελέσιμο αρχείο και το
 εκτελεί χρησιμοποιώντας τα απαραίτητα μέτρα ασφαλείας ώστε να συγκρίνει την έξοδο
 για κάθε αρχείο ελέγχου με την σωστή. Μόλις τελειώσει η εκτέλεση ή ξεπεραστούν τα
-όρια της, ενημερώνει τη βάση δεδομένων, με χρήση ενός PHP script, με την έκβαση της
+όρια της, ενημερώνει τη βάση δεδομένων, με χρήση ενός PHP script, για την έκβαση της
 εκτέλεσης και ειδοποιεί το Grader καλώντας ένα μοναδικό για κάθε υποβολή σύνδεσμο
 (callback) ώστε αυτός να αναλάβει την ανάλυση των αποτελεσμάτων.
 
@@ -700,19 +701,17 @@ Kewii και Grader, δηλαδή backend και frontend.
 κοινό κορμό που έχει τεθεί για το συγκεκριμένο πρόβλημα. Ο τρόπος αξιολόγησης
 μπορεί να είναι κανονικός ή ειδικός. Στον κανονικό ελέγχεται η ομοιότητα της
 εξόδου του προγράμματος της υποβολής με την ορθή απάντηση, ενώ στον ειδική
-αξιολόγηση γίνεται χρήση ενός προγράμματος, που θα έχει τεθεί για το
-συγκεκριμένο πρόβλημα, ώστε να βαθμολογηθεί η λύση, επιτρέποντας έτσι την
-ύπαρξη προβλημάτων βελτιστοποίησης.
+αξιολόγηση γίνεται χρήση ειδικού προγράμματος αξιολόγησης για την βαθμολόγηση
+της λύσης επιτρέποντας έτσι την ύπαρξη προβλημάτων βελτιστοποίησης.
 
 \bigskip
 
 Οι υποβολές που στέλνονται στον Kewii αποθηκεύονται σε μια ουρά σύμφωνα με τον
 αύξοντα αριθμό που παίρνουν και ο Kewii γνωρίζει κάθε στιγμή ποιος θα είναι ο
-επόμενος αριθμός υποβολής που θα αξιολογήσει. Το πρόγραμμα κοιμάται έως ότου
+επόμενος αριθμός υποβολής που θα αξιολογήσει. Το πρόγραμμα "κοιμάται" έως ότου
 βρει μια νέα υποβολή ελέγχοντας για αρχεία με τον συγκεκριμένο αριθμό. Επίσης,
 αν η διαδικασία της αξιολόγησης διακοπεί ενδιάμεσα, μπορεί να συνεχίσει από το
-σημείο που σταμάτησε. Μια ακριβέστερη περιγραφή της ροής φαίνεται στο παρακάτω
-σχήμα:
+σημείο που σταμάτησε. Η ροή λειτουργίας του παρουσιάζεται στο σχήμα 3.1.
 
 \begin{figure}
   \centering
@@ -723,16 +722,17 @@ Kewii και Grader, δηλαδή backend και frontend.
 
 \bigskip
 
-Γενικά, ο Kewii περιορίζεται στο να δέχεται υποβολές για συγκεκριμένα προβλήματα
-με συγκεκριμένα αρχεία ελέγχου (και σε μερικές περιπτώσεις συγκεκριμένο πρόγραμμα
-αξιολόγησης). Αξιολογεί την κάθε υποβολή με 0 - λάθος και 1 - σωστό για κάθε αρχείο
-ή αναθέτει την αξιολόγηση στο αρμόδιο πρόγραμμα που θα επιστρέψει μια τιμή ανάμεσα
-στα 0 και 1. Τότε οι "ευθύνες" του τελειώνουν, δηλαδή δεν ασχολείται με την συνολική
-αξιολόγηση των διαγωνισμών και των προβλημάτων και ποια υποβολή θεωρείται ενεργή,
-ούτε με το ποια αρχεία ελέγχου θα επιλεγούν κατά την υποβολή. Τα παραπάνω κρίνονται
-σημαντικά γιατί θα μας επιτρέψουν να επανασχεδιάσουμε τον αλγόριθμο της υποβολής,
-δημιουργώντας ομάδες αρχείων ελέγχου, όπως και άλλα κομμάτια του Grader χωρίς να
-χρειαστεί να τροποποιήσουμε τον Kewii.
+Γενικά, η λειτουργία του Kewii περιορίζεται στο να δέχεται υποβολές για
+προβλήματα με συγκεκριμένα αρχεία ελέγχου. Αξιολογεί κάθε υποβολή με 0 - λάθος
+και 1 - σωστό για κάθε αρχείο ή αναθέτει την αξιολόγηση στο ειδικό πρόγραμμα
+που θα επιστρέψει μια τιμή ανάμεσα στα 0 και 1. Τότε, η "ευθύνη" του τελειώνει,
+δηλαδή δεν εμπλέκεται στη συνολική αξιολόγηση των διαγωνισμών και των
+προβλημάτων, τον ορισμό υποβολών ως ενεργών, ή με το ποια αρχεία ελέγχου θα
+επιλεγούν για κάθε υποβολή. Η αποστασιοποίηση του από τα παραπάνω, το γεγονός
+δηλαδή ότι δρα ως ένα μαύρο κουτί για την εκτέλεση των υποβολών, είναι πολύ
+σημαντικό διότι θα μας επιτρέψουν να επανασχεδιάσουμε τον αλγόριθμο της
+υποβολής, δημιουργώντας ομάδες αρχείων ελέγχου, όπως και άλλα κομμάτια του
+Grader χωρίς να χρειαστεί να τροποποιήσουμε τον Kewii.
 
 \section{Διαδικτυακή εφαρμογή Grader}
 
@@ -745,7 +745,7 @@ Kewii και Grader, δηλαδή backend και frontend.
 
 \bigskip
 
-\noindent Τα συνήθη σενάρια χρήσης της εφαρμογής αναφέρονται παρακάτω.
+Τα συνήθη σενάρια χρήσης της εφαρμογής αναφέρονται παρακάτω.
 
 \subsection{Εμφάνιση διαθέσιμων διαγωνισμών και προβλημάτων}
 
@@ -761,18 +761,19 @@ Kewii και Grader, δηλαδή backend και frontend.
 για καθένα από τα προβλήματα του. Σε αυτή τη σελίδα υπάρχουν όλες οι υποβολές
 που έχει κάνει για αυτό το πρόβλημα, ενώ υπάρχει χρωματική διάκριση ανάμεσα σε
 σωστές και λανθασμένες υποβολές, καθώς και για την ενεργή υποβολή. Ως ενεργή
-υποβολή τίθεται η τελευταία σωστή, αν και υπάρχει η δυνατότητα, στην ίδια
-οθόνη, να επιλεχθεί μια διαφορετική σωστή υποβολή ως ενεργή. Επιλέγοντας μια
-υποβολή, ο χρήστης μεταφέρεται στην οθόνη λεπτομερειών της υποβολής του, όπου
+υποβολή τίθεται η τελευταία σωστή, αν και υπάρχει η δυνατότητα στην ίδια
+σελίδα να επιλεχθεί μια διαφορετική σωστή υποβολή ως ενεργή. Επιλέγοντας μια
+υποβολή, ο χρήστης μεταφέρεται στη σελίδα λεπτομερειών της υποβολής του, όπου
 εμφανίζονται και τα ακριβή αποτελέσματα της λύσης του για κάθε αρχείο ελέγχου.
-Για τα αρχεία ελέγχου που το επιτρέπουν, υπάρχει η οθόνη προεπισκόπησης.
+Για τα αρχεία ελέγχου που το επιτρέπουν, υπάρχει η σελίδα προεπισκόπησης.
 Παρόμοια δυνατότητα δίνεται και για τον πηγαίο κώδικα της υποβολής, αν ο
 χρήστης θέλει να τον δει στην εφαρμογή.
 
-TODO: μιλαμε για σεναρια οχι για οθονες, μηπως θελουν αλλαγη οι περιγραφες;
+(% todo search for οθόν)
 \subsection{Δημιουργία και διαχείριση προβλημάτων και διαγωνισμών}
 
-Στη συγκεκριμένη οθόνη, που δεν είναι προσβάσιμη στους κανονικούς χρήστες, ο
+Η δημιουργία και η διαχείριση διαγωνισμών γίνεται από τη σελίδα της διαχείρισης
+που δεν είναι προσβάσιμη στους κανονικούς χρήστες. Σε αυτή τη σελίδα, ο
 διαχειριστής μπορεί να δει όλους τους διαγωνισμούς και τα προβλήματα που έχουν
 δημιουργηθεί. Οι διαγωνισμοί παρουσιάζονται ταξινομημένοι κατά χρονολογική
 σειρά δημιουργίας μαζί με τα προβλήματα που περιέχονται στον καθένα. Δίνονται
@@ -784,72 +785,72 @@ TODO: μιλαμε για σεναρια οχι για οθονες, μηπως
 
 \bigskip
 
-Εξαιτίας της άμεσης σύνδεσης προβλημάτων και υποβολών σε αυτά, κατά τη
-μετακίνηση ενός προβλήματος μεταξύ διαγωνισμών, αυτό διατηρεί τις υποβολές που
-είχε αν και είναι πλέον σε διαφορετικό διαγωνισμό. Επιπροσθέτως, όπως είναι
-προφανές, ο διαγωνισμός που ήταν αρχικά το πρόβλημα φαίνεται κενός και
-ουσιαστικά χάνει και την ιστορικότητα του. Ο συγκεκριμένος τρόπος λειτουργίας
-αποτελεί απόρροια της αρχικής σχεδίασης του Grader για διοργανώσεις και όχι για
-ακαδημαϊκούς σκοπούς, με αποτέλεσμα να μην έχει προβλεφθεί η δημιουργία
-διαγωνισμών-σειρών ασκήσεων με επαναχρησιμοποίηση προβλημάτων.
+Εξαιτίας της άμεσης σύνδεσης προβλημάτων και υποβολών, τα προβλήματα διατηρούν
+τις υποβολές που έχουν γίνει σε αυτά κατά τους σε νέους διαγωνισμούς.
+Επιπροσθέτως, όπως είναι προφανές, ο διαγωνισμός στον οποίο άνηκε αρχικά το
+πρόβλημα φαίνεται κενός και ουσιαστικά χάνει και την ιστορικότητα του. Ο
+συγκεκριμένος τρόπος λειτουργίας αποτελεί απόρροια της αρχικής σχεδίασης του
+Grader για διοργανώσεις και όχι για ακαδημαϊκούς σκοπούς, με αποτέλεσμα να μην
+έχει προβλεφθεί η δημιουργία διαγωνισμών-σειρών ασκήσεων με επαναχρησιμοποίηση
+προβλημάτων.
 
 \bigskip
 
-Μια ακόμα οθόνη που είναι προσβάσιμη από την κεντρική της διαχείρισης προβλημάτων
+Μια ακόμα σελίδα που είναι προσβάσιμη από την κεντρική της διαχείρισης προβλημάτων
 και διαγωνισμών είναι αυτή των αρχείων ελέγχου του προβλήματος. Σε αυτήν μπορεί
 ο διαχειριστής να ανεβάσει καινούρια αρχεία ελέγχου, καθώς και να αλλάξει τον τύπο
-εκτέλεσης και την βαθμολογία τους. Η συγκεκριμένη οθόνη θα μας απασχολήσει αρκετά
-στα επόμενα κεφάλαια.
+εκτέλεσης και την βαθμολογία τους. Η συγκεκριμένη σελίδα θα μας απασχολήσει αρκετά
+στα επόμενα κεφάλαια, δεδομένου ότι θα τροποποιηθεί τόσο για τις ομάδες αρχείων
+ελέγχου όσο και για την προσθήκη μαζικής δημιουργίας αρχείων και ομάδων.
 
 \subsection{Ενεργοποίηση διαγωνισμού και τελική αξιολόγηση}
 
 Ένα πολύ συνηθισμένο σενάριο χρήσης για έναν διαχειριστή είναι αυτό κατά το
 οποίο, αφού έχει δημιουργήσει ένα νέο διαγωνισμό και τα προβλήματα του, πρέπει
-να το δημοσιοποιήσει στους χρήστες. Μέσα από την οθόνη διαχείρισης των
-διαγωνισμών, έχει τη δυνατότητα, αρχικά, να επιλέξει τους χρήστες που
-επιτρέπεται να συμμετέχουν (ή όλους) στο διαγωνισμό. Έπειτα, έχοντας επιλέξει
-και τη σωστή ημερομηνία έναρξης και λήξης του διαγωνισμού κατά τη δημιουργία
-του, μπορεί να επιλέξει την ενεργοποίηση αυτού με το αντίστοιχο πλήκτρο στην
-οθόνη διαχείρισης. Τότε το πρόβλημα γίνεται ορατό στους επιλεγμένους χρήστες
-και οι τελευταίοι μπορούν να ξεκινήσουν να κάνουν υποβολές.
+να το δημοσιοποιήσει στους χρήστες. Μέσα από τη σελίδα διαχείρισης των
+διαγωνισμών, έχει τη δυνατότητα αρχικά να επιλέξει τους χρήστες που επιτρέπεται
+να συμμετέχουν στο διαγωνισμό. Έπειτα, έχοντας επιλέξει την επιθυμητή
+ημερομηνία έναρξης και λήξης του διαγωνισμού κατά τη δημιουργία του, μπορεί να
+επιλέξει την ενεργοποίηση αυτού με το αντίστοιχο πλήκτρο στη σελίδα
+διαχείρισης. Τότε ο διαγωνισμός και τα προβλήματα του γίνονται ορατά στους
+επιλεγμένους χρήστες και οι τελευταίοι μπορούν να ξεκινήσουν να κάνουν
+υποβολές.
 
 \bigskip
 
 Όταν λήξει ή απενεργοποιηθεί ο διαγωνισμός, ο διαχειριστής μπορεί να εκκινήσει
 την τελική αξιολόγηση, κατά την οποία επιλέγονται όλες οι ενεργές υποβολές για
-κάθε πρόβλημα του διαγωνισμού (μία ανά διαγωνιζόμενο με τουλάχιστον μία σωστή
-υποβολή) και αυτές αποστέλλονται ξανά στον Kewii για να αξιολογηθούν εκ νέου
-συμπεριλαμβάνοντας αυτή τη φορά τα αρχεία ελέγχου που είναι αποκλειστικά για
-την τελική αξιολόγηση. Μόλις ολοκληρωθεί η διαδικασία, εμφανίζονται στην οθόνη
-τα τελικά αποτελέσματα, τα οποία μπορούν να δημοσιοποιηθούν σαν νέα στην αρχική
-σελίδα του Grader. Η βαθμολογία υπολογίζεται από το άθροισμα των ενεργών
-υποβολών του κάθε διαγωνιζόμενου στα προβλήματα που περιέχει ο διαγωνισμός. Η
-βαθμολογία του προβλήματος είναι το άθροισμα των αρχείων ελέγχου της τελικής
-αξιολόγησης (αποκλειστικά και μη).
-
-TODO: Καλύτερη περιγραφή της λειτουργίας της υποβολης; + ισως μια συμπερασματική παράγραφο
+κάθε πρόβλημα του διαγωνισμού και αυτές αποστέλλονται στον Kewii για να
+αξιολογηθούν εκ νέου συμπεριλαμβάνοντας αυτή τη φορά τα αρχεία ελέγχου που
+είναι αποκλειστικά για την τελική αξιολόγηση (πράσινα). Μόλις ολοκληρωθεί η
+διαδικασία, εμφανίζονται στη σελίδα τα τελικά αποτελέσματα, τα οποία μπορούν να
+δημοσιοποιηθούν σαν δημοσιεύσεις στην αρχική σελίδα του Grader. Η βαθμολογία
+υπολογίζεται από το άθροισμα των ενεργών υποβολών του κάθε διαγωνιζόμενου στα
+προβλήματα που περιέχει ο διαγωνισμός. Η βαθμολογία του προβλήματος είναι το
+άθροισμα των πόντων των αρχείων ελέγχου της τελικής αξιολόγησης.
+
 
 \chapter{Προσθήκη Ομάδων Αρχείων Ελέγχου}
 
 Η μεγαλύτερη σε πολυπλοκότητα αλλαγή λειτουργικότητας του Grader ήταν η
 τροποποίηση του τρόπου αξιολόγησης των υποβολών με την εισαγωγή ομάδων αρχείων
-ελέγχου (testcase groups) για ομαδοποίηση των τελευταίων, καθώς και ενός νέου
-τύπου εκτέλεσης των αρχείων ελέγχου. Η υλοποίηση του νέου τύπου εκτέλεσης, που
-θα αντιστοιχεί στο μπλε χρώμα (blue tag), κατά την αντιστοίχιση που
-παρουσιάστηκε στο κεφάλαιο 3.1.3, ήταν μια χρήσιμη εισαγωγή στη
-λειτουργία και στο codebase του Grader αλλά και στη βάση και τους σχετικούς
-πίνακες. Στο παρόν κεφάλαιο θα περιγραφεί πρώτα η μικρή αυτή προσθήκη και
-έπειτα η λογική και η υλοποίηση της προσθήκης των testcase groups.
-
+ελέγχου (testcase groups) για ομαδοποίηση των τελευταίων, καθώς και η
+δημιουργία ενός νέου τύπου εκτέλεσης των αρχείων. Η υλοποίηση του νέου τύπου
+εκτέλεσης, που θα αντιστοιχεί στο μπλε χρώμα (blue tag
+\includegraphics[scale=0.8]{Figures/tag_blue.png}) κατά την αντιστοίχιση που
+παρουσιάστηκε στον πίνακα 3.1, ήταν μια χρήσιμη εισαγωγή στη λειτουργία και
+στον κώδικα του Grader αλλά και τη βάση δεδομένων. Στο παρόν κεφάλαιο θα
+περιγραφεί πρώτα η μικρή αυτή προσθήκη και έπειτα η λογική και η υλοποίηση της
+προσθήκης των testcase groups.
 
 \section{Προσθήκη blue tag για μη απαραίτητα αρχεία ελέγχου}
 
 \subsection{Κίνητρο}
 
-Ένα αρχείο ελέγχου χαρακτηρισμένο με blue tag, ελέγχεται κανονικά σε κάθε
-αξιολόγηση, αλλά το αποτέλεσμα της εκτέλεσης του δεν επηρεάζει την ορθότητα της
-υποβολής. Όπως τα "κίτρινα" αρχεία ελέγχου, τα "μπλε", δεν διαθέτουν την είσοδο
-τους προς προβολή στους διαγωνιζόμενους. Ο συγκεκριμένος τύπος εκτέλεσης είχε
+Ένα αρχείο ελέγχου χαρακτηρισμένο με blue tag ελέγχεται κανονικά σε κάθε
+αξιολόγηση αλλά το αποτέλεσμα της εκτέλεσης του δεν επηρεάζει την ορθότητα της
+υποβολής. Όπως τα "κίτρινα" αρχεία ελέγχου, τα "μπλε" διατηρούν κρυφή την είσοδο
+τους από τους διαγωνιζόμενους. Ο συγκεκριμένος τύπος εκτέλεσης είχε
 υλοποιηθεί πρώτα (πριν την παρούσα εργασία), στο branch του Grader που
 χρησιμοποιεί το hellenico.gr, το οποίο όμως διαφέρει αρκετά από αυτό του softlab,
 γεγονός που δεν επέτρεπε το απλό merge του σχετικού κώδικά.
@@ -868,24 +869,24 @@ TODO: Καλύτερη περιγραφή της λειτουργίας της
 
 \bigskip
 
-Αυτό δημιουργεί το πρόβλημα ότι αρχεία ελέγχου με μη-φανερές δυσκολίες του
-αλγόριθμου (corner/edge cases) ή αρχεία ελέγχου που φέρνουν τις υποβληθείσες
-λύσεις κοντά στα εκτελεστικά τους όρια, αποτελούν ρίσκο όσον αφορά τον
-χαρακτηρισμό τους ως "κίτρινα" ή "πορτοκαλί", δηλαδή αρχεία ελέγχου που τρέχουν
-σε κανονικές και τελικές υποβολές. Όσοι διαγωνιζόμενοι δεν καταφέρουν να
-υποβάλουν λύση που να τις "περάσει" δε θα καταφέρει να βαθμολογηθεί καθόλου,
-πιθανόν άδικα. Ως φυσικό επακόλουθο, τέτοιου τύπου αρχεία ελέγχου μπορούν να
-χαρακτηριστούν μόνο ως πράσινα, δηλαδή να τρέχουν μόνο στην τελική αξιολόγηση.
+Αυτό δημιουργεί το πρόβλημα ότι αρχεία ελέγχου με μη εμφανείς δυσκολίες του
+αλγόριθμου (corner/edge cases) ή αρχεία με μεγάλο μέγεθος εισόδου, αποτελούν
+ρίσκο όσον αφορά τον χαρακτηρισμό τους ως "κίτρινα" ή "πορτοκαλί", δηλαδή
+αρχεία ελέγχου που τρέχουν σε κανονικές και τελικές υποβολές.  Όσοι
+διαγωνιζόμενοι δεν καταφέρουν να υποβάλουν λύση που να αξιολογηθεί σωστά σε όλα
+τα αρχεία ελέγχου δεν καταφέρνουν να βαθμολογηθούν καθόλου, πιθανόν άδικα. Ως
+φυσικό επακόλουθο, τέτοιου τύπου αρχεία ελέγχου μπορούν να χαρακτηριστούν μόνο
+ως πράσινα, δηλαδή να χρησιμοποιούνται αποκλειστικά στην τελική αξιολόγηση.
 
 \bigskip
 
-Τα μπλε αρχεία ελέγχου προσφέρουν μια λύση στο πρόβλημα, καθώς επιτρέπουν,
-ουσιαστικά, μια υποβολή να χαρακτηριστεί ορθή/ενεργή χωρίς να έχει "περάσει"
-όλα τα αρχεία ελέγχου. Ακόμα κι αν ο διαγωνιζόμενος δεν καταφέρει να βελτιώσει
-την υλοποίηση του, έτσι ώστε να ικανοποιεί όλα τα αρχεία ελέγχου, θα διαθέτει
-μια ενεργή υποβολή και συνεπώς θα βαθμολογηθεί. Παράλληλα, θα γνωρίζει ότι
-έχει αποτύχει σε τουλάχιστον μία περίπτωση και θα έχει κίνητρο να συνεχίσει τις
-υποβολές ώστε να μη χάσει την πιθανότητα να πάρει πλήρη βαθμολογία.
+Τα μπλε αρχεία ελέγχου προσφέρουν μια λύση στο πρόβλημα, καθώς επιτρέπουν
+ουσιαστικά μια υποβολή να χαρακτηριστεί ορθή/ενεργή χωρίς να έχει "περάσει" όλα
+τα αρχεία ελέγχου. Ακόμα κι αν ο διαγωνιζόμενος δεν καταφέρει να βελτιώσει την
+υλοποίηση του έτσι ώστε να ικανοποιεί όλα τα αρχεία ελέγχου, θα διαθέτει μια
+ενεργή υποβολή και συνεπώς θα βαθμολογηθεί. Παράλληλα, θα γνωρίζει ότι έχει
+αποτύχει σε τουλάχιστον μία περίπτωση και θα έχει κίνητρο να συνεχίσει τις
+υποβολές ώστε να μη χάσει τη δυνατότητα να πάρει πλήρη βαθμολογία.
 
 \subsection{Υλοποίηση}
 
@@ -895,38 +896,39 @@ TODO: Καλύτερη περιγραφή της λειτουργίας της
 που τρέχει μόλις ολοκληρωθεί η αξιολόγηση μιας υποβολής. Ο Kewii δε χρειάστηκε
 τροποποιήσεις, διότι όπως έχει περιγραφεί σε προηγούμενο κεφάλαιο, σε κάθε
 υποβολή λαμβάνει απλά τη λίστα με τα αρχεία ελέγχου που πρέπει να
-χρησιμοποιήσει και επιστρέφει την έκβαση τους. Η βάση δεδομένων, επίσης δεν
+χρησιμοποιήσει και επιστρέφει την έκβαση τους. Η βάση δεδομένων επίσης δεν
 υποβλήθηκε σε αλλαγές, καθώς η μόνη αλλαγή που την επηρεάζει είναι η προσθήκη
 μιας πιθανής τιμής στο πεδίο του τύπου εκτέλεσης του πίνακα των αρχείων
 ελέγχου.
 
 \bigskip
 
-Οι αλλαγές που αφορούν το frontend κομμάτι έγιναν κυρίως στη σελίδα της διαχείρισης
-αρχείων ελέγχων. Όπως φαίνεται στην εικόνα 4.1, δίπλα σε κάθε αρχείο ελέγχου είναι
-τα χρωματικά tags και χάρη στη CSS διακρίνεται το επιλεγμένο. Για την προσθήκη
-του blue tag, δανειστήκαμε την εικόνα από το hellenico, και αυτή προστέθηκε μετά
-το κίτρινο και πορτοκαλί. Αντίστοιχα, προστέθηκε η περιγραφή του συγκεκριμένου
-tag και ο κώδικας που διαχειριζόταν το πάτημα του tag και την αλλαγή στη βάση.
+Οι αλλαγές που αφορούν στο frontend κομμάτι έγιναν κυρίως στη σελίδα της
+διαχείρισης αρχείων ελέγχων. Όπως φαίνεται στην εικόνα 4.1, δίπλα σε κάθε
+αρχείο ελέγχου είναι τα χρωματικά tags και χάρη στη CSS διακρίνεται το
+επιλεγμένο. Για την προσθήκη του blue tag, χρησιμοποιήθηκε η εικόνα από το
+hellenico, και αυτή προστέθηκε μετά το κίτρινο tag. Αντίστοιχα, προστέθηκε η
+περιγραφή του συγκεκριμένου tag και τροποποιήθηκε ο κώδικας που διαχειρίζεται
+το πάτημα του tag και τροποποιεί τη βάση.
 
 \bigskip
 
 Στον κώδικα που τρέχει κατά την υποβολή, επιλέγονται τα αρχεία ελέγχου που θα
 εκτελεστούν και γράφονται σε ένα αρχείο στον εξυπηρετητή ώστε να μπουν στην
-ουρά του Kewii. Εκεί προστέθηκε ο νέος τύπος εκτέλεσης σε αυτά που στέλνονται
-σε όλες τις υποβολές. Αντίστοιχα στο callback script, το κομμάτι του Grader που
-τρέχει με πρωτοβουλία του Kewii, μόλις αυτός έχει τελειώσει την αξιολόγηση μιας
-υποβολής, υλοποιήθηκε η λογική των "μπλε" αρχείων ελέγχου, που ακόμα και να
-έχουν έρθει ως λανθασμένα, δεν επηρεάζουν την έκβαση.
+ουρά του Kewii. Εκεί προστέθηκε ο νέος τύπος εκτέλεσης σε αυτούς που στέλνονται
+σε όλες τις υποβολές. Αντίστοιχα, στο callback script, το κομμάτι του Grader
+που τρέχει μόλις έχει ολοκληρωθεί η βασική αξιολόγηση μιας υποβολής από τον
+Kewii, υλοποιήθηκε η λογική των "μπλε" αρχείων ελέγχου, που ακόμα και να έχουν
+χαρακτηριστεί ως λανθασμένα, δεν επηρεάζουν την έκβαση.
 
 \begin{figure}
   \centering
   \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/bluetag.png}
-  \caption[Προσθήκη blue tag]{Η οθόνη διαχείρισης αρχείων ελέγχου μετά την
+  \caption[Προσθήκη blue tag]{Η σελίδα διαχείρισης αρχείων ελέγχου μετά την
   προσθήκη του blue tag.}
 \end{figure}
 
-\section{Testcase Groups}
+\section{Ομάδες αρχείων ελέγχου (testcase groups)}
 
 Έχοντας προσθέσει το blue tag, τροποποιώντας πολλαπλά σημεία του Grader τόσο
 για την υποβολή όσο και για την αξιολόγηση, μπορούσαμε να προχωρήσουμε στην
@@ -934,120 +936,139 @@ tag και ο κώδικας που διαχειριζόταν το πάτημα
 
 \subsection{Κίνητρο}
 
-Πριν τις αλλαγές μας, ο διαχειριστής, κατά την δημιουργία του προβλήματος,
+Πριν τις αλλαγές μας ο διαχειριστής, κατά την δημιουργία του προβλήματος,
 έπρεπε να δημιουργήσει αρχεία ελέγχου και να επιλέξει στο καθένα βαθμολογία και
-τύπο εκτέλεσης. Από κείνο το σημείο και έπειτα, τα αρχεία ελέγχου δεν είχαν
-κάποια κατηγοριοποίηση ή διαχωρισμό. Ο διαχειριστής, σε κάθε σημείο, όφειλε να
+τύπο εκτέλεσης. Τα αρχεία ελέγχου δεν είχαν δυνατότητα για οποιαδήποτε
+κατηγοριοποίηση ή διαχωρισμό. Ο διαχειριστής, σε κάθε σημείο, όφειλε να
 διατηρεί την ισορροπία όσον αφορά στις βαθμολογίες των αρχείων ελέγχου και να
-θυμάται την αναλογία εύκολων και δύσκολων αρχείων ή οποιαδήποτε άλλης
-κατηγορίας.
+θυμάται την αναλογία εύκολων και δύσκολων αρχείων.
 
 \bigskip
 
 Άλλο ένα πρόβλημα που υπήρχε ήταν η δυνατότητα για δημιουργία ειδικών λύσεων σε
 συγκεκριμένα προβλήματα έτσι ώστε να λαμβάνουν αξιοπρεπή βαθμολογία έχοντας
-υλοποιήσει μέρος μόνο του αλγορίθμου, αρκεί να περνούσαν τα αναγκαία αρχεία της
-κανονικής υποβολής. Κάθε αρχείο ελέγχου είχε δικιά του βαθμολογία οπότε θα
-μπορούσε κανείς να επιτύχει στα μισά παραδείγματος χάρη σε ένα true/false
-πρόβλημα.
+υλοποιήσει περιορισμένο μέρος του αλγόριθμου που να αρκεί για την ορθότητα της
+υποβολής. Κάθε αρχείο ελέγχου που αξιολογείται ως σωστό αθροίζεται στην
+βαθμολογία της τελικής αξιολόγησης και μια τέτοια υποβολή μπορεί να επιτύχει
+καλύτερη βαθμολογία από ότι θα έπρεπε.
 
 \bigskip
 
 Η προσθήκη testcase groups θα επιτρέψει την ομαδοποίηση των αρχείων ελέγχου σε
-ομάδες ανεξάρτητες στην αξιολόγηση με δική τους βαθμολογία με την ορθότητα τους
-να κρίνεται από την ορθότητα όλων των αρχείων ελέγχουν που περιέχουν. Έτσι, θα
+groups ανεξάρτητα στην αξιολόγηση, με δική τους βαθμολογία και με την ορθότητα
+τους να κρίνεται στην ορθότητα όλων των επιμέρους αρχείων ελέγχου. Έτσι, θα
 δοθεί μεγάλη ευελιξία στη δημιουργία διαφορετικών κατηγοριών αρχείων. Ένας
 χρήσιμος διαχωρισμός θα μπορεί να είναι ανάλογα με το μέγεθος της εισόδου,
 δηλαδή σε μικρά, μεσαία και μεγάλα. Με αυτό τον τρόπο ο διαχειριστής γλιτώνει
-πολύ κόπο πετυχαίνοντας την επιθυμητή αναλογία βαθμολογίας στις διάφορες
-υλοποιήσεις βάζοντας απλά τους βαθμούς που θέλει ανεξάρτητα με το πόσα αρχεία
-ελέγχου εμπεριέχει κάθε group.
+πολύ κόπο πετυχαίνοντας την επιθυμητή αναλογία βαθμολογίας στις διάφορες λύσεις
+βάζοντας απλά τους βαθμούς που επιθυμεί στο group, ανεξάρτητα με το πόσα αρχεία
+ελέγχου ανήκουν σε κάθε group.
 
 \bigskip
 
 Επιπροσθέτως, λύνεται το πρόβλημα των προσαρμοσμένων λύσεων, αφού αν τα
-υπάρχοντα groups εμπεριέχουν αρχεία πολλαπλών περιπτώσεων, οι συγκεκριμένες
-λύσεις δε θα καταφέρνουν να ικανοποιήσουν ταυτόχρονα τα αρχεία και δε θα
+υπάρχοντα groups αποτελούνται από αρχεία πολλαπλών περιπτώσεων, οι λύσεις αυτού
+του τύπου δε θα καταφέρνουν να ικανοποιήσουν ταυτόχρονα τα αρχεία και δε θα
 βαθμολογούνται σε αυτά τα groups.
 
 \subsection{Προδιαγραφές}
 
 Για την καθοδήγηση της υλοποίησης τέθηκαν συγκεκριμένες προδιαγραφές όσον
-αφορά τις ομάδες αρχείων ελέγχου και τη λειτουργία τους.
+αφορά στις ομάδες αρχείων ελέγχου και τη λειτουργία τους.
 
 \begin{itemize}
 
     \item Οι ομάδες αρχείων ελέγχου, όπως περιγράφηκαν και παραπάνω, θα μπορούν
       να περιέχουν οποιοδήποτε υποσύνολο των διαθέσιμων αρχείων. Επιθυμούμε,
       για μεγαλύτερη ευελιξία, τα αρχεία ελέγχου να μπορούν να ανήκουν σε
-      πολλαπλές ομάδες και με διαφορετικό τύπο εκτέλεσης.
+      πολλαπλές ομάδες, με επιλογή για διαφορετικό τύπο εκτέλεσης σε κάθε ομάδα.
 
     \item Η αξιολόγηση θα γίνεται με βάση μόνο τις ομάδες, ανεξάρτητα με το
       πόσα αρχεία ελέγχου υπάρχουν. Μια υποβολή θα θεωρείται ορθή και θα μπορεί
       να τεθεί ως ενεργή αν ικανοποιεί τουλάχιστον μια ομάδα.
 
     \item Οι ομάδες θα μπορούν να αποκτήσουν τίτλο από το διαχειριστή και θα
-      διαθέτουν βαθμολογία. Τα παραπάνω καθιστούν τις βαθμολογίες και τύπους
-      εκτέλεσης των αρχείων ελέγχου ανούσιες.
+      διαθέτουν πόντους. Τα παραπάνω καθιστούν πόντους και τύπους
+      εκτέλεσης των αρχείων ελέγχου ανούσιους.
 
-    \item Οι ομάδες που περιέχουν τουλάχιστον ένα αρχείο ελέγχο με τύπο εκτέλεσης
-      μη-τελικής αξιολόγησης, δηλαδή κίτρινο, πορτοκαλί ή μπλε, θα αξιολογούνται
+    \item Οι ομάδες που περιέχουν τουλάχιστον ένα αρχείο ελέγχου με τύπο εκτέλεσης
+      μη τελικής αξιολόγησης, δηλαδή κίτρινο, πορτοκαλί ή μπλε, θα αξιολογούνται
       κατά τις κανονικές υποβολές και θα είναι εμφανείς στους διαγωνιζόμενους
-      μαζί με τα αρχεία ελέγχου που διαθέτουν.
+      μαζί με τα αρχεία ελέγχου που αξιολογήθηκαν.
 
 \end{itemize}
 
 \subsection{Υλοποίηση}
 
-Με βάση τις προδιαγραφές που περιγράφηκαν παραπάνω σχηματίζεται η εικόνα της
-υλοποίησης και των κρίσιμων κομματιών της. Ως προς τη βάση δεδομένων, θα
-χρειαστεί ένας νέος πίνακας για τα testcase groups και τα χαρακτηριστικά τους
-(όνομα, βαθμολογία).
+Με βάση τις προδιαγραφές που περιγράφηκαν παραπάνω διαμορφώνεται η εικόνα της
+υλοποίησης και των κρίσιμων μερών της.
 
 \bigskip
 
-Δεδομένου ότι η σχέση αρχείων ελέγχου και ομάδων είναι N-to-N, δηλαδή τόσο οι
-ομάδες περιέχουν πολλαπλά αρχεία και τα αρχεία ανήκουν σε πολλαπλές ομάδες, θα
-χρειαστεί και δεύτερος πίνακας αντιστοίχισης ομάδων με τα αρχεία που περιέχουν.
-Ο συγκεκριμένος πίνακας θα έχει και πεδίο για τον τύπο εκτέλεσης του αρχείου
-ελέγχου στη συγκεκριμένη ομάδα, επιτρέποντας ένα αρχείο να ανήκει ως φανερό
-(κίτρινο) σε μία ομάδα και ως τελικό (πράσινο) σε μία άλλη. Οι σχετικοί πίνακες
-παρουσιάζονται στις εικόνες 38 και 39.
+Αρχικά, όσον αφορά στη βάση δεδομένων, θα χρειαστεί ένας νέος πίνακας για τα
+testcase groups και τα χαρακτηριστικά τους (όνομα, βαθμολογία). Δεδομένου ότι η
+σχέση αρχείων ελέγχου και groups είναι N-to-N, δηλαδή τόσο τα groups περιέχουν
+πολλαπλά αρχεία και τα αρχεία ανήκουν σε πολλαπλά groups, θα χρειαστεί και
+δεύτερος πίνακας, για την καταχώρηση όλων των αρχείων ελέγχου κάθε group.
+
+\bigskip
+
+Ο δεύτερος αυτός πίνακας θα ονομαστεί GroupDetails και θα περιέχει, εκτός από
+τα πεδία testcaseID και groupID, πεδίο για τον τύπο εκτέλεσης του αρχείου
+ελέγχου στη συγκεκριμένο group, επιτρέποντας ένα αρχείο π.χ. να ανήκει ως
+φανερό (κίτρινο) σε ένα group και ως τελικό (πράσινο) σε ένα άλλο. Οι σχετικοί
+πίνακες παρουσιάζονται στις εικόνες 4.2 και 4.3.
+
+
+\begin{figure}
+  \centering
+  \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/groupsbefore.png}
+  \caption[Βάση πριν τα testcase groups]{Οι πίνακες και οι σχέσεις της βάσης πριν
+  τις αλλαγές μας.}
+\end{figure}
+
+\begin{figure}
+  \centering
+  \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/groupsafter.png}
+  \caption[Βάση μετά τα testcase groups]{Δημιουργήθηκε ο νέος πίνακας GroupDetails,
+  που είναι απαραίτητος για την αντιστοίχιση testcase groups με αρχεία ελέγχου.
+  Επίσης, προστέθηκε το πεδίο resultsjson για την αποθήκευση των υπολογισμένων
+  αποτελεσμάτων της υποβολής.}
+\end{figure}
 
 \bigskip
 
-Από τη στιγμή που υπάρχει η πιθανότητα δύο ομάδες να έχουν κοινά αρχεία ελέγχου
-σε πρόβλημα, δημιουργείται το θέμα της πιθανής αχρείαστης αξιολόγησης των ίδιων
-αρχείων ελέγχου πολλές φορές. Στην υλοποίηση μας αυτό θα αποφευχθεί διατηρώντας
-την αρχιτεκτονική της εφαρμογής όσον αφορά στις αρμοδιότητες Kewii και Grader
+Από τη στιγμή που υπάρχει η πιθανότητα δύο groups να έχουν κοινά αρχεία ελέγχου
+, δημιουργείται το θέμα της πιθανής αχρείαστης αξιολόγησης των ίδιων αρχείων
+ελέγχου πολλές φορές. Στην υλοποίηση μας αυτό θα αποφευχθεί διατηρώντας την
+αρχιτεκτονική της εφαρμογής όσον αφορά στις αρμοδιότητες Kewii και Grader
 απαράλλαχτη. Αυτό σημαίνει ότι ο Kewii θα συνεχίσει να παίρνει απλά μια λίστα
 με τα αρχεία ελέγχου που πρέπει να εκτελέσει και θα επιστρέφει το αποτέλεσμα
-τους. Πρακτικά, δε θα "αντιληφθεί" την αλλαγή, καθώς ο Grader θα είναι
-υπεύθυνος κατά την υποβολή μιας λύσης να φιλτράρει τα μοναδικά αρχεία ελέγχου
-που του χρειάζονται για τις ομάδες που συμμετέχουν στην αξιολόγηση, και κατά το
-callback για την χρησιμοποίηση αυτών των αποτελεσμάτων για να λάβει την τελική
-έκβαση των testcase groups.
+τους. Πρακτικά, δε θα "αντιληφθεί" την αλλαγή, καθώς ο Grader θα παραμείνει
+υπεύθυνος, κατά την υποβολή μιας λύσης, να φιλτράρει τα μοναδικά αρχεία ελέγχου
+που του χρειάζονται και κατά το callback να συνθέτει τα αποτελέσματα που θα
+λάβει κατάλληλα ώστε να αποφανθεί για την ορθότητα κάθε group.
 
 \bigskip
 
-Για τη διαχείριση των testcase groups κρίθηκε αναγκαίο να δημιουργηθεί μια νέα
-οθόνη για την διαχείριση και τη δημιουργία testcase groups, η οποία εισάχθηκε
-στην ήδη υπάρχουσα διαχείριση αρχείων ελέγχου. Η τελευταία χρειάστηκε
-σημαντικές τροποποιήσεις, καθώς πλέον τα αρχεία ελέγχου δεν μπορούν να έχουν
-βαθμολογίες και τύπους εκτέλεσης (χρώματα) εκτός των ομάδων που ανήκουν. Τα
-χρωματικά tags παρέμειναν, δίνοντας τη δυνατότητα στο διαχειριστή να αλλάξει
-μαζικά τον τύπο ενός αρχείου ελέγχου σε όλες τις ομάδες που ανήκει. Κρίθηκε
-σημαντικό η πληροφορία για τις ομάδες, τις βαθμολογίες τους και το ποια αρχεία
-εμπεριέχει η κάθε μια, να εμφανίζεται στη συγκεκριμένη οθόνη χωρίς να είναι
-απαραίτητη η μετάβαση στη οθόνη της διαχείρισης ομάδας αρχείων ελέγχου. Οι δύο
-προαναφερθείσες οθόνες εμφανίζονται στις εικόνες 4.3 και 4.4.
+Για τη διαχείριση και τη δημιουργία των testcase groups κρίθηκε αναγκαίο να
+δημιουργηθεί μια νέα σελίδα, η οποία εισάχθηκε στην ήδη υπάρχουσα διαχείριση
+αρχείων ελέγχου. Η τελευταία χρειάστηκε σημαντικές τροποποιήσεις, καθώς πλέον
+τα αρχεία ελέγχου δεν μπορούν να έχουν βαθμολογίες και τύπους εκτέλεσης (tags)
+έξω των ομάδων που ανήκουν. Τα χρωματικά tags παρέμειναν, δίνοντας τη
+δυνατότητα στο διαχειριστή να αλλάξει μαζικά τον τύπο ενός αρχείου ελέγχου σε
+όλες τις ομάδες που ανήκει. Κρίθηκε σημαντικό η πληροφορία για τις ομάδες, τις
+βαθμολογίες τους και το ποια αρχεία εμπεριέχει η κάθε μια, να εμφανίζεται στη
+συγκεκριμένη σελίδα χωρίς να είναι απαραίτητη η μετάβαση στη σελίδα της
+διαχείρισης ομάδας αρχείων ελέγχου. Οι δύο προαναφερθείσες σελίδες εμφανίζονται
+στις εικόνες 4.4 και 4.5.
 
 \bigskip
 
 \begin{figure}
   \centering
   \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/groupoverview.png}
-  \caption[Επισκόπηση ομάδων αρχείων ελέγχου]{Η οθόνη διαχείρισης των αρχείων
+  \caption[Επισκόπηση ομάδων αρχείων ελέγχου]{Η σελίδα διαχείρισης των αρχείων
   ελέγχου μετά την προσθήκη των testcase groups. Διακρίνεται η επισκόπηση τους,
   μαζί με τα αρχεία ελέγχου που περιέχουν και τους βαθμούς τους.}
 \end{figure}
@@ -1055,31 +1076,31 @@ callback για την χρησιμοποίηση αυτών των αποτελ
 \begin{figure}
   \centering
   \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/groupedit.png}
-  \caption[Διαχείριση ομάδας αρχείων ελέγχου]{Εδώ φαίνεται η νέα οθόνη που
+  \caption[Διαχείριση ομάδας αρχείων ελέγχου]{Εδώ φαίνεται η νέα σελίδα που
   δημιουργήθηκε για την δημιουργία και τροποποίηση μιας ομάδας αρχείων ελέγχου.}
 \end{figure}
 
 \bigskip
 
-Η εισαγωγή των testcase groups στο Grader επηρέασε, ακόμα, μεγάλο πλήθος οθονών
+Η εισαγωγή των testcase groups στο Grader επηρέασε, ακόμα, μεγάλο πλήθος σελίδων
 και λειτουργιών συμπεριλαμβανομένων των παρακάτω:
 
 \begin{itemize}
-    \item Αλλαγές στην οθόνη των λεπτομερειών υποβολής. Στη συγκεκριμένη
-      οθόνη πλέον εμφανίζονται ομάδες αντί για αρχεία, οι οποίες περιέχουν
+    \item Αλλαγές στη σελίδα των λεπτομερειών υποβολής. Στη συγκεκριμένη
+      σελίδα πλέον εμφανίζονται ομάδες αντί για αρχεία, οι οποίες περιέχουν
       τα αρχεία που αντιστοιχούν σε αυτές μέσα σε πλαίσια. Οι χρωματικές ενδείξεις
-      επιτυχίας (πράσινο φόντο) και αποτυχίας (κόκκινο) έχουν παραμείνει, με την
-      προσθήκη αλλαγής του φόντου του τίτλου της ομάδας ανάλογα με τη συνολική
-      έκβαση.
-
-    \item Αλλαγές στην οθόνη παρουσίασης όλων των υποβολών και επιλογής της ενεργής.
-      Εδώ έπρεπε να προστεθεί μία ένδειξη ορθότητας κάθε υποβολής πέρα από τις
-      υπάρχουσες, δηλαδή πράσινο/κόκκινο. Μια ορθή υποβολή θα είναι πράσινη αλλά
-      μπορεί π.χ. να έχει περάσει μόνο το ένα από τα τρία testcase groups, κάτι
-      που δεν είναι εμφανές μέχρι να μεταβεί ο διαγωνιζόμενος στις λεπτομέρειες
-      υποβολής. Στο συγκεκριμένο παράδειγμα θα αναγράφεται 1/3.
-
-    \item Στην οθόνη διαχείρισης προβλημάτων και διαγωνισμών άλλαξαν τα στατιστικά
+      επιτυχίας (πράσινο φόντο) και αποτυχίας (κόκκινο) έχουν παραμείνει. Το φόντο
+      του τίτλου του group χρωματίζεται και αυτό ανάλογα με την ορθότητα του.
+
+    \item Αλλαγές στη σελίδα παρουσίασης όλων των υποβολών και επιλογής της
+      ενεργής.  Εδώ έπρεπε να προστεθεί μία ένδειξη ορθότητας κάθε υποβολής σε
+      σχέση με το πόσα σωστά groups έχει. Πρόκειται απλά για ένα κλάσμα των
+      σωστών groups προς όλα όσα ελέγχθηκε. Μια ορθή υποβολή θα είναι πράσινη
+      αλλά μπορεί π.χ. να έχει περάσει μόνο το ένα από τα τρία testcase groups,
+      κάτι που δεν είναι εμφανές μέχρι να μεταβεί ο διαγωνιζόμενος στις
+      λεπτομέρειες υποβολής. Σε αυτή την περίπτωση θα αναγράφεται 1/3.
+
+    \item Στη σελίδα διαχείρισης προβλημάτων και διαγωνισμών άλλαξαν τα στατιστικά
       δίπλα σε κάθε πρόβλημα που έως τώρα παρουσίαζαν την αναλογία αρχείων ελέγχου
       ανά τύπο εκτέλεσης. Πλέον, εμφανίζονται μόνο δύο αριθμοί, ο συνολικός αριθμός
       αρχείων ελέγχου και ομάδων.
@@ -1089,7 +1110,7 @@ callback για την χρησιμοποίηση αυτών των αποτελ
 \begin{figure}
   \centering
   \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/allsubmissions.png}
-  \caption[Νέα οθόνη εμφάνισης υποβολών]{Η τροποποιημένη παρουσίαση όλων των
+  \caption[Νέα σελίδα εμφάνισης υποβολών]{Η τροποποιημένη παρουσίαση όλων των
   υποβολών ενός διαγωνιζόμενου, όπου διακρίνεται ο βαθμός επιτυχίας της υποβολής
   ως προς τα testcase groups που είχε σωστά.}
 \end{figure}
@@ -1097,8 +1118,8 @@ callback για την χρησιμοποίηση αυτών των αποτελ
 \begin{figure}
   \centering
   \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/cursubmission.png}
-  \caption[Νέα οθόνη λεπτομέρειων υποβολής]{Η οθόνη τροποποιήθηκε σύμφωνα με τον
-  νέο τρόπο αξιολόγησης, παρουσιάζοντας για κάθε ομάδα την αξιολόγηση της υποβολής
+  \caption[Νέα σελίδα λεπτομέρειων υποβολής]{Η σελίδα τροποποιήθηκε σύμφωνα με τον
+  νέο τρόπο αξιολόγησης, παρουσιάζοντας για κάθε group την αξιολόγηση της υποβολής
   για κάθε αρχείο ελέγχου που περιέχει.}
 \end{figure}
 
@@ -1116,19 +1137,19 @@ callback για την χρησιμοποίηση αυτών των αποτελ
 
 Ο τρόπος να επιτευχθεί η ισοδυναμία προηγούμενης και νέας κατάστασης είναι η
 δημιουργία ενός group που να περιέχει μόνο τα αρχεία ελέγχου κανονικών
-υποβολών, δηλαδή μπλε, κίτρινα και πορτοκαλί, με βαθμολογία 0. Αυτή η ομάδα,
-ουσιαστικά, πετυχαίνει την προσομοίωση της προηγούμενης κατάστασης όπου οι
+υποβολών, δηλαδή μπλε, κίτρινα και πορτοκαλί, με βαθμολογία 0. Αυτό το group,
+πετυχαίνει ουσιαστικά, την προσομοίωση της προηγούμενης κατάστασης όπου οι
 υποβολές ελέγχονταν στα συγκεκριμένα αρχεία ελέγχου και εφόσον τα περνούσαν
-όλα, η λύση ήταν σωστή και γινόταν ενεργή. Αυτή η ομάδα όμως δεν αρκεί, καθώς
-χρειάζονται και ομάδες για την τελική αξιολόγηση. Αντίστοιχα, θα πρέπει να
-δημιουργηθούν ακόμα ίσος αριθμός ομάδων με τα ενεργά αρχεία ελέγχου (όλα εκτός
-των μωβ), και πιο συγκεκριμένα, κάθε ομάδα θα περιέχει ένα αρχείο ελέγχου με
+όλα, η λύση ήταν σωστή και γινόταν ενεργή. Αυτό το group όμως δεν αρκεί, καθώς
+χρειάζονται και άλλα για την τελική αξιολόγηση. Αντίστοιχα, θα πρέπει να
+δημιουργηθούν ακόμα ίσος αριθμός groups με τα ενεργά αρχεία ελέγχου (όλα εκτός
+των μωβ), και πιο συγκεκριμένα, κάθε group θα περιέχει ένα αρχείο ελέγχου με
 χρώμα πράσινο και η βαθμολογία της θα είναι ίση με τη βαθμολογία του αρχείου
 ελέγχου. Έτσι, πετυχαίνουμε την προσομοίωση και της τελικής αξιολόγησης, καθώς
-όλες αυτές οι ομάδες δε θα ελέγχονται στην κανονική υποβολή αφού περιέχουν μόνο
-πράσινα αρχεία ελέγχου (και συγκεκριμένα ένα η κάθε μία). Για τη διαδικασία
-αυτή, υλοποιήθηκε script, το οποίο εισάχθηκε στην οθόνη διαχείρισης αρχείων
-ελέγχου του προβλήματος.
+όλα αυτά τα groups δε θα ελέγχονται στην κανονική υποβολή διότι περιέχουν μόνο
+πράσινα αρχεία ελέγχου (από ένα κάθε group). Για την αυτοματοποίηση της
+διαδικασίας μετατροπής που περιγράφηκε υλοποιήθηκε script, το οποίο εισάχθηκε
+στη σελίδα διαχείρισης αρχείων ελέγχου του προβλήματος.
 
 \bigskip
 
@@ -1136,31 +1157,16 @@ callback για την χρησιμοποίηση αυτών των αποτελ
 μερικό refactoring των κλάσεων και των συναρτήσεων, χρησιμοποιώντας πολλές από
 τις αρχές που περιγράφονται στο Clean Code του Robert Martin
 \cite{martin2009clean}. Μέρος των αλλαγών ήταν και η προσθήκη ενός πεδίου στον
-πίνακα των υποβολών, με τίτλο resultsjson, το οποίο περιέχει τα αναλυτικά
-αποτελέσματα μιας υποβολής, κωδικοποιημένα σε μορφή JSON, έτσι ώστε να μην
-υπολογίζονται κάθε φορά που απαιτούνται. Επιπλέον, αλλαγές έγιναν ώστε να
-αφαιρεθούν κομμάτια επαναλαμβανόμενου κώδικα με την αντίστοιχη δημιουργία νέων
-δομών και κλάσεων, αποσύνδεση της λογικής διαφορετικών αντικειμένων και μείωση
-της πολυπλοκότητας μεγάλων κομματιών κώδικα με δημιουργία μικρότερων
+πίνακα των υποβολών, με τίτλο resultsjson (εικόνα 4.3), το οποίο περιέχει τα
+αναλυτικά αποτελέσματα μιας υποβολής, κωδικοποιημένα σε μορφή JSON, έτσι ώστε
+να μην υπολογίζονται κάθε φορά που απαιτούνται. Επιπλέον, αλλαγές έγιναν ώστε
+να αφαιρεθούν κομμάτια επαναλαμβανόμενου κώδικα με την αντίστοιχη δημιουργία
+νέων δομών και κλάσεων, αποσύνδεση της λογικής διαφορετικών αντικειμένων και
+μείωση της πολυπλοκότητας μεγάλων κομματιών κώδικα με δημιουργία μικρότερων
 συναρτήσεων με περιγραφικά ονόματα.
 
 \bigskip
 
-\begin{figure}
-  \centering
-  \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/groupsbefore.png}
-  \caption[Βάση πριν τα testcase groups]{Οι πίνακες και οι σχέσεις της βάσης πριν
-  τις αλλαγές μας.}
-\end{figure}
-
-\begin{figure}
-  \centering
-  \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/groupsafter.png}
-  \caption[Βάση μετά τα testcase groups]{Δημιουργήθηκε ο νέος πίνακας GroupDetails,
-  που είναι απαραίτητος για την αντιστοίχιση testcase groups με αρχεία ελέγχου.
-  Επίσης, προστέθηκε το πεδίο resultsjson για την αποθήκευση των υπολογισμένων
-  αποτελεσμάτων της υποβολής.}
-\end{figure}
 
 \chapter{Σχεδίαση για διαχωρισμό Προβλημάτων - Διαγωνισμών}
 
@@ -1182,7 +1188,7 @@ callback για την χρησιμοποίηση αυτών των αποτελ
 \bigskip
 
 Τα προβλήματα, έπειτα από τη δημιουργία τους, παραμένουν ανένταχτα, στην κατηγορία
-"Προβλήματα εκτός διαγωνισμών" της οθόνης διαχείρισης
+"Προβλήματα εκτός διαγωνισμών" της σελίδας διαχείρισης
 όπως φαίνεται και στο σχήμα 5.1. Το επόμενο βήμα είναι η μετακίνηση τους
 σε κάποιον διαγωνισμό με χρήση του μενού στα δεξιά του προβλήματος. Η μετακίνηση
 αυτού του τύπου είναι ο μόνος τρόπος να επαναχρησιμοποιηθεί το πρόβλημα και σε
@@ -1307,10 +1313,10 @@ callback για την χρησιμοποίηση αυτών των αποτελ
 (TODO: ισως subsection) Έχοντας αλλάξει τη βάση, αυτό που μένει είναι η
 υλοποίηση των αλλαγών στο Grader ώστε να δίνεται η δυνατότητα της αντιγραφής
 των προβλημάτων και να αξιοποιούνται τα νέα πεδία και πίνακες. Η πλειοψηφία των
-αλλαγών αφορούν την οθόνη διαχείρισης, καθώς εκεί πρέπει να αλλάξει ο τρόπος
+αλλαγών αφορούν τη σελίδα διαχείρισης, καθώς εκεί πρέπει να αλλάξει ο τρόπος
 που αντιστοιχίζονται τα προβλήματα με τους διαγωνισμούς, όπως και οι υποβολές
 αυτών. Ακόμα, η λειτουργία του πλήκτρου μετακίνησης αλλάζει σε αντιγραφή, πάλι
-επιλέγοντας διαγωνισμό. Τέλος, στο κάτω μέρος της οθόνης, όπου αναγράφονταν τα
+επιλέγοντας διαγωνισμό. Τέλος, στο κάτω μέρος της σελίδας, όπου αναγράφονταν τα
 ανένταχτα προβλήματα, κρίθηκε προτιμότερο να αναγράφονται όλα τα προβλήματα
 ώστε να είναι ευκολότερο να αναζητηθεί και να αντιγραφεί κάποιο σε ένα νέο
 διαγωνισμό. Η νέα διαχείριση παρουσιάζεται στις φωτογραφίες 5.4 και 5.5.
@@ -1447,7 +1453,7 @@ Overflow \cite{website:pythongrowth} χάρη, κυρίως, στην καθιέ
 
 Κατά τη διαδικασία δημιουργίας ενός προβλήματος, είναι απαραίτητο να προστεθεί
 ένας συχνά μεγάλος αριθμός αρχείων ελέγχου. Ο μόνος τρόπος να γίνει αυτό είναι
-μέσω της οθόνης διαχείρισης των αρχείων ελέγχου, όπως φαίνεται στη
+μέσω της σελίδας διαχείρισης των αρχείων ελέγχου, όπως φαίνεται στη
 φωτογραφία 4.1, και κάθε νέο αρχείο ανεβαίνει ξεχωριστά, δηλαδή δεν υπάρχει
 κάποια μαζική διαδικασία.
 
@@ -1471,9 +1477,9 @@ Overflow \cite{website:pythongrowth} χάρη, κυρίως, στην καθιέ
 
 \subsection{Υλοποίηση}
 
-Το εργαλείο που περιγράφηκε θα προστεθεί στην οθόνη διαχείρισης των αρχείων
+Το εργαλείο που περιγράφηκε θα προστεθεί στη σελίδα διαχείρισης των αρχείων
 ελέγχου κάτω από το ήδη υπάρχον ανέβασμα μεμονωμένου αρχείου. Μετά την προσθήκη
-η οθόνη θα έχει τη μορφή της φωτογραφίας 6.1. Ο διαχειριστής θα ανεβάζει ένα
+η σελίδα θα έχει τη μορφή της εικόνας 6.1. Ο διαχειριστής θα ανεβάζει ένα
 συμπιεσμένο αρχείο (zip) με τα αρχεία εισόδου και εξόδου που θέλει να προσθέσει
 στο πρόγραμμα. Στο αρχείο θα πρέπει, επιπλέον, να υπάρχει και ένα αρχείο με
 όνομα descriptor.json το οποίο θα αναλαμβάνει να περιγράψει στο εργαλείο τις