Finish chapter 4

test.tex

@@ -425,7 +425,7 @@ Kewii και Grader, δηλαδή backend και frontend.
 επόμενος αριθμός υποβολής που θα αξιολογήσει. Το πρόγραμμα κοιμάται έως ότου
 βρει μια νέα υποβολή ελέγχοντας για αρχεία με τον συγκεκριμένο αριθμό. Επίσης,
 αν η διαδικασία της αξιολόγησης διακοπεί ενδιάμεσα, μπορεί να συνεχίσει από το
-σημείο που σταμάτησε.  Μια ακριβέστερη περιγραφή της ροής φαίνεται στο παρακάτω
+σημείο που σταμάτησε. Μια ακριβέστερη περιγραφή της ροής φαίνεται στο παρακάτω
 σχήμα:
 
 (TODO σχημα εδώ)
@@ -484,7 +484,7 @@ TODO: μιλαμε για σεναρια οχι για οθονες, μηπως
 Στη συγκεκριμένη οθόνη, που δεν είναι προσβάσιμη στους κανονικούς χρήστες, ο
 διαχειριστής μπορεί να δει όλους τους διαγωνισμούς και τα προβλήματα που έχουν
 δημιουργηθεί. Οι διαγωνισμοί παρουσιάζονται ταξινομημένοι κατά χρονολογική
-σειρά δημιουργίας μαζί με τα προβλήματα που περιέχονται στον καθένα.  Δίνονται
+σειρά δημιουργίας μαζί με τα προβλήματα που περιέχονται στον καθένα. Δίνονται
 επιλογές για επεξεργασία προβλημάτων και διαγωνισμών, καθώς και δημιουργία
 νέων. Αφού δημιουργηθεί ένα πρόβλημα, αρχικά δεν ανήκει σε κάποιον διαγωνισμό
 έως ότου επιλεχθεί κάποιος από το πλευρικό μενού μετακίνησης του προβλήματος.
@@ -573,7 +573,7 @@ TODO: Καλύτερη περιγραφή της λειτουργίας της
 αξιολόγηση: Κατά τη διεξαγωγή του διαγωνισμού, κάθε πρόβλημα είναι ανοιχτό σε
 υποβολές. Μια υποβολή θεωρείται ορθή μόνο αν όλα τα αρχεία ελέγχου που έτρεξαν
 είναι σωστά. Για να πάρει βαθμολογία για το πρόβλημα, ο διαγωνιζόμενος πρέπει
-να έχει τουλάχιστον μια ορθή υποβολή σε αυτό (την ενεργή). 
+να έχει τουλάχιστον μια ορθή υποβολή σε αυτό (την ενεργή).
 
 \bigskip
 
@@ -583,7 +583,7 @@ TODO: Καλύτερη περιγραφή της λειτουργίας της
 χαρακτηρισμό τους ως "κίτρινα" ή "πορτοκαλί", δηλαδή αρχεία ελέγχου που τρέχουν
 σε κανονικές και τελικές υποβολές. Όσοι διαγωνιζόμενοι δεν καταφέρουν να
 υποβάλουν λύση που να τις "περάσει" δε θα καταφέρει να βαθμολογηθεί καθόλου,
-πιθανόν άδικα.  Ως φυσικό επακόλουθο, τέτοιου τύπου αρχεία ελέγχου μπορούν να
+πιθανόν άδικα. Ως φυσικό επακόλουθο, τέτοιου τύπου αρχεία ελέγχου μπορούν να
 χαρακτηριστούν μόνο ως πράσινα, δηλαδή να τρέχουν μόνο στην τελική αξιολόγηση.
 
 \bigskip
@@ -611,10 +611,10 @@ TODO: Καλύτερη περιγραφή της λειτουργίας της
 
 \bigskip
 
-Οι αλλαγές που αφορούν το frontend κομμάτι έγιναν κυρίως στη σελίδα της διαχείρισης 
+Οι αλλαγές που αφορούν το frontend κομμάτι έγιναν κυρίως στη σελίδα της διαχείρισης
 αρχείων ελέγχων. Όπως φαίνεται στην εικόνα18, δίπλα σε κάθε αρχείο ελέγχου είναι
-τα χρωματικά tags και με χρήση CSS διακρίνεται το επιλεγμένο. Για την προσθήκη 
-του blue tag, δανειστήκαμε την εικόνα από το hellenico, και αυτή προστέθηκε μετά 
+τα χρωματικά tags και με χρήση CSS διακρίνεται το επιλεγμένο. Για την προσθήκη
+του blue tag, δανειστήκαμε την εικόνα από το hellenico, και αυτή προστέθηκε μετά
 το κίτρινο και πορτοκαλί. Αντίστοιχα, προστέθηκε η περιγραφή του συγκεκριμένου
 tag και ο κώδικας που διαχειριζόταν το πάτημα του tag και την αλλαγή στη βάση.
 
@@ -668,7 +668,7 @@ tag και ο κώδικας που διαχειριζόταν το πάτημα
 υλοποιήσεις βάζοντας απλά τους βαθμούς που θέλει ανεξάρτητα με το πόσα αρχεία
 ελέγχου εμπεριέχει κάθε group.
 
-\bigskip 
+\bigskip
 
 Επιπροσθέτως, λύνεται το πρόβλημα των προσαρμοσμένων λύσεων, αφού αν τα
 υπάρχοντα groups εμπεριέχουν αρχεία πολλαπλών περιπτώσεων, οι συγκεκριμένες
@@ -677,7 +677,7 @@ tag και ο κώδικας που διαχειριζόταν το πάτημα
 
 \subsection{Προδιαγραφές}
 
-Για την καθοδήγηση της υλοποίησης τέθηκαν συγκεκριμένες προδιαγραφές όσον 
+Για την καθοδήγηση της υλοποίησης τέθηκαν συγκεκριμένες προδιαγραφές όσον
 αφορά τις ομάδες αρχείων ελέγχου και τη λειτουργία τους.
 
 \begin{itemize}
@@ -685,20 +685,20 @@ tag και ο κώδικας που διαχειριζόταν το πάτημα
     \item Οι ομάδες αρχείων ελέγχου, όπως περιγράφηκαν και παραπάνω, θα μπορούν
       να περιέχουν οποιοδήποτε υποσύνολο των διαθέσιμων αρχείων. Επιθυμούμε,
       για μεγαλύτερη ευελιξία, τα αρχεία ελέγχου να μπορούν να ανήκουν σε
-      πολλαπλές ομάδες και με διαφορετικό τύπο εκτέλεσης. 
+      πολλαπλές ομάδες και με διαφορετικό τύπο εκτέλεσης.
 
     \item Η αξιολόγηση θα γίνεται με βάση μόνο τις ομάδες, ανεξάρτητα με το
       πόσα αρχεία ελέγχου υπάρχουν. Μια υποβολή θα θεωρείται ορθή και θα μπορεί
       να τεθεί ως ενεργή αν ικανοποιεί τουλάχιστον μια ομάδα.
-    
-    \item Οι ομάδες θα μπορούν να αποκτήσουν τίτλο από το διαχειριστή και θα 
+
+    \item Οι ομάδες θα μπορούν να αποκτήσουν τίτλο από το διαχειριστή και θα
       διαθέτουν βαθμολογία. Τα παραπάνω καθιστούν τις βαθμολογίες και τύπους
       εκτέλεσης των αρχείων ελέγχου ανούσιες.
 
     \item Οι ομάδες που περιέχουν τουλάχιστον ένα αρχείο ελέγχο με τύπο εκτέλεσης
       μη-τελικής αξιολόγησης, δηλαδή κίτρινο, πορτοκαλί ή μπλε, θα αξιολογούνται
       κατά τις κανονικές υποβολές και θα είναι εμφανείς στους διαγωνιζόμενους
-      μαζί με τα αρχεία ελέγχου που διαθέτουν. 
+      μαζί με τα αρχεία ελέγχου που διαθέτουν.
 
 \end{itemize}
 
@@ -707,7 +707,7 @@ tag και ο κώδικας που διαχειριζόταν το πάτημα
 Με βάση τις προδιαγραφές που περιγράφηκαν παραπάνω σχηματίζεται η εικόνα της
 υλοποίησης και των κρίσιμων κομματιών της. Ως προς τη βάση δεδομένων, θα
 χρειαστεί ένας νέος πίνακας για τα testcase groups και τα χαρακτηριστικά τους
-(όνομα, βαθμολογία). 
+(όνομα, βαθμολογία).
 
 \bigskip
 
@@ -716,21 +716,113 @@ tag και ο κώδικας που διαχειριζόταν το πάτημα
 χρειαστεί και δεύτερος πίνακας αντιστοίχισης ομάδων με τα αρχεία που περιέχουν.
 Ο συγκεκριμένος πίνακας θα έχει και πεδίο για τον τύπο εκτέλεσης του αρχείου
 ελέγχου στη συγκεκριμένη ομάδα, επιτρέποντας ένα αρχείο να ανήκει ως φανερό
-(κίτρινο) σε μία ομάδα και ως τελικό (πράσινο) σε μία άλλη.  
+(κίτρινο) σε μία ομάδα και ως τελικό (πράσινο) σε μία άλλη. Οι σχετικοί πίνακες
+παρουσιάζονται στις εικόνες 38 και 39.
 
 \bigskip
 
 Από τη στιγμή που υπάρχει η πιθανότητα δύο ομάδες να έχουν κοινά αρχεία ελέγχου
-σε πρόβλημα, δημιουργείται το θέμα της πιθανής αχρείαστης αξιολόγησης
-των ίδιων αρχείων ελέγχου πολλές φορές. Στην υλοποίηση μας αυτό θα αποφευχθεί 
-διατηρώντας την αρχιτεκτονική της εφαρμογής όσον αφορά στις αρμοδιότητες Kewii και
-Grader απαράλλαχτη. Αυτό σημαίνει ότι ο Kewii, θα συνεχίσει να παίρνει απλά μια
-λίστα με τα αρχεία ελέγχου που πρέπει να εκτελέσει και θα επιστρέφει το αποτέλεσμα
-τους. Πρακτικά, δε θα "αντιληφθεί" την αλλαγή, καθώς ο Grader θα είναι υπεύθυνος
-κατά την υποβολή μιας λύσης να φιλτράρει τα μοναδικά αρχεία ελέγχου που του
-χρειάζονται για τις ομάδες που συμμετέχουν στην αξιολόγηση, και κατά το callback
-για την χρησιμοποίηση αυτών των αποτελεσμάτων για να λάβει την τελική έκβαση των
-testcase groups.
+σε πρόβλημα, δημιουργείται το θέμα της πιθανής αχρείαστης αξιολόγησης των ίδιων
+αρχείων ελέγχου πολλές φορές. Στην υλοποίηση μας αυτό θα αποφευχθεί διατηρώντας
+την αρχιτεκτονική της εφαρμογής όσον αφορά στις αρμοδιότητες Kewii και Grader
+απαράλλαχτη. Αυτό σημαίνει ότι ο Kewii θα συνεχίσει να παίρνει απλά μια λίστα
+με τα αρχεία ελέγχου που πρέπει να εκτελέσει και θα επιστρέφει το αποτέλεσμα
+τους. Πρακτικά, δε θα "αντιληφθεί" την αλλαγή, καθώς ο Grader θα είναι
+υπεύθυνος κατά την υποβολή μιας λύσης να φιλτράρει τα μοναδικά αρχεία ελέγχου
+που του χρειάζονται για τις ομάδες που συμμετέχουν στην αξιολόγηση, και κατά το
+callback για την χρησιμοποίηση αυτών των αποτελεσμάτων για να λάβει την τελική
+έκβαση των testcase groups.
+
+\bigskip
+
+Για τη διαχείριση των testcase groups κρίθηκε αναγκαίο να δημιουργηθεί μια νέα
+οθόνη για την διαχείριση και τη δημιουργία testcase groups, η οποία εισάχθηκε
+στην ήδη υπάρχουσα διαχείριση αρχείων ελέγχου. Η τελευταία χρειάστηκε
+σημαντικές τροποποιήσεις, καθώς πλέον τα αρχεία ελέγχου δεν μπορούν να έχουν
+βαθμολογίες και τύπους εκτέλεσης (χρώματα) εκτός των ομάδων που ανήκουν. Τα
+χρωματικά tags παρέμειναν, δίνοντας τη δυνατότητα στο διαχειριστή να αλλάξει
+μαζικά τον τύπο ενός αρχείου ελέγχου σε όλες τις ομάδες που ανήκει. Κρίθηκε
+σημαντικό η πληροφορία για τις ομάδες, τις βαθμολογίες τους και το ποια αρχεία
+εμπεριέχει η κάθε μια, να εμφανίζεται στη συγκεκριμένη οθόνη χωρίς να είναι
+απαραίτητη η μετάβαση στη οθόνη της διαχείρισης ομάδας αρχείων ελέγχου. Οι δύο
+προαναφερθείσες οθόνες εμφανίζονται στις εικόνες 41 και 42.
+
+\bigskip
+
+(TODO: eikones 41 42)
+
+\bigskip 
+
+Η εισαγωγή των testcase groups στο Grader επηρέασε, ακόμα, μεγάλο πλήθος οθονών
+και λειτουργιών συμπεριλαμβανομένων των παρακάτω:
+
+\begin{itemize}
+    \item Αλλαγές στην οθόνη των λεπτομερειών υποβολής. Στη συγκεκριμένη 
+      οθόνη πλέον εμφανίζονται ομάδες αντί για αρχεία, οι οποίες περιέχουν
+      τα αρχεία που αντιστοιχούν σε αυτές μέσα σε πλαίσια. Οι χρωματικές ενδείξεις
+      επιτυχίας (πράσινο φόντο) και αποτυχίας (κόκκινο) έχουν παραμείνει, με την
+      προσθήκη αλλαγής του φόντου του τίτλου της ομάδας ανάλογα με τη συνολική
+      έκβαση.
+
+    \item Αλλαγές στην οθόνη παρουσίασης όλων των υποβολών και επιλογής της ενεργής.
+      Εδώ έπρεπε να προστεθεί μία ένδειξη ορθότητας κάθε υποβολής πέρα από τις
+      υπάρχουσες, δηλαδή πράσινο/κόκκινο. Μια ορθή υποβολή θα είναι πράσινη αλλά
+      μπορεί π.χ. να έχει περάσει μόνο το ένα από τα τρία testcase groups, κάτι
+      που δεν είναι εμφανές μέχρι να μεταβεί ο διαγωνιζόμενος στις λεπτομέρειες
+      υποβολής. Στο συγκεκριμένο παράδειγμα θα αναγράφεται 1/3.
+
+    \item Στην οθόνη διαχείρισης προβλημάτων και διαγωνισμών άλλαξαν τα στατιστικά
+      δίπλα σε κάθε πρόβλημα που έως τώρα παρουσίαζαν την αναλογία αρχείων ελέγχου
+      ανά τύπο εκτέλεσης. Πλέον, εμφανίζονται μόνο δύο αριθμοί, ο συνολικός αριθμός
+      αρχείων ελέγχου και ομάδων.
+
+\end{itemize}
+
+Οι φωτογραφίες 43-45 επιδεικνύουν κάποιες από τις κύριες αλλαγές.
+
+\bigskip
+
+Άλλη μια σημαντική πτυχή της υλοποίησης αποτελεί ο τρόπος που θα γίνει η
+μετάβαση από τον προηγούμενο τρόπο αξιολόγησης στο νέο. Εκτός από τις πολλαπλές
+τροποποιήσεις στον κώδικα και στη βάση, επιβάλλεται να τροποποιηθούν όλα τα 
+προβλήματα, παλιά και τρέχοντα. Ο λόγος είναι ότι στο νέο σύστημα η αξιολόγηση όλων
+των υποβολών βασίζεται στα testcase groups αντί για τα μεμονωμένα αρχεία ελέγχου.
+Ως αποτέλεσμα, κάθε υπάρχων πρόβλημα θα πρέπει να αποκτήσει groups τα οποία,
+ιδανικά, θα είναι ισοδύναμα  με τα υπάρχοντα αρχεία ελέγχου.
+
+\bigskip
+
+Ο τρόπος να επιτευχθεί η ισοδυναμία προηγούμενης και νέας κατάστασης είναι η
+δημιουργία ενός group που να περιέχει μόνο τα αρχεία ελέγχου κανονικών
+υποβολών, δηλαδή μπλε, κίτρινα και πορτοκαλί, με βαθμολογία 0. Αυτή η ομάδα,
+ουσιαστικά, πετυχαίνει την προσομοίωση της προηγούμενης κατάστασης όπου οι
+υποβολές ελέγχονταν στα συγκεκριμένα αρχεία ελέγχου και εφόσον τα περνούσαν
+όλα, η λύση ήταν σωστή και γινόταν ενεργή. Αυτή η ομάδα όμως δεν αρκεί, καθώς
+χρειάζονται και ομάδες για την τελική αξιολόγηση. Αντίστοιχα, θα πρέπει να
+δημιουργηθούν ακόμα ίσος αριθμός ομάδων με τα ενεργά αρχεία ελέγχου (όλα εκτός
+των μωβ), και πιο συγκεκριμένα, κάθε ομάδα θα περιέχει ένα αρχείο ελέγχου με
+χρώμα πράσινο και η βαθμολογία της θα είναι ίση με τη βαθμολογία του αρχείου
+ελέγχου. Έτσι, πετυχαίνουμε την προσομοίωση και της τελικής αξιολόγησης, καθώς
+όλες αυτές οι ομάδες δε θα ελέγχονται στην κανονική υποβολή αφού περιέχουν μόνο
+πράσινα αρχεία ελέγχου (και συγκεκριμένα ένα η κάθε μία). Για τη διαδικασία
+αυτή, υλοποιήθηκε script, το οποίο εισάχθηκε στην οθόνη διαχείρισης αρχείων
+ελέγχου του προβλήματος. 
+
+\bigskip
+
+Η υλοποίηση όσον αφορά στο frontend και τη λογική του Grader, συνδυάστηκε με
+μερικό refactoring των κλάσεων και των συναρτήσεων, χρησιμοποιώντας πολλές
+από τις αρχές που περιγράφονται στο (TODO: να το βγαλω τελειως ή να βάλω πηγή)
+clean code του Robert Martin. Μέρος των αλλαγών ήταν και η προσθήκη ενός πεδίου
+στον πίνακα των υποβολών, με τίτλο resultsjson, το οποίο περιέχει τα αναλυτικά
+αποτελέσματα μιας υποβολής, κωδικοποιημένα σε μορφή JSON, έτσι ώστε να μην 
+υπολογίζονται κάθε φορά που απαιτούνται. Επιπλέον, αλλαγές έγιναν ώστε να
+αφαιρεθούν κομμάτια επαναλαμβανόμενου κώδικα με την αντίστοιχη δημιουργία 
+νέων δομών και κλάσεων, αποσύνδεση της λογικής διαφορετικών αντικειμένων και
+μείωση της πολυπλοκότητας μεγάλων κομματιών κώδικα με δημιουργία μικρότερων
+συναρτήσεων με περιγραφικά ονόματα.
+
+\bigskip
 
 - Εξήγηση σχέσεων πινάκων
 
@@ -738,6 +830,10 @@ testcase groups.
 
 - Φωτογραφίες από ανέβασμα ομάδων αρχείων ελέγχου
 
+\bigskip 
+
+(TODO: εικόνες βάσης 38,39)
+
 
 \chapter{Σχεδίαση για διαχωρισμό Προβλημάτων - Διαγωνισμών}
 
@@ -750,23 +846,23 @@ testcase groups.
 
 \section{Κίνητρο}
 
-Ο πρωταρχικός στόχος που δημιουργήθηκε ο Grader ήταν η χρήση του για διαγωνισμούς 
-πληροφορικής. Κάθε διαγωνισμός θα αποτελούσε ξεχωριστό, one-time γεγονός με 
+Ο πρωταρχικός στόχος που δημιουργήθηκε ο Grader ήταν η χρήση του για διαγωνισμούς
+πληροφορικής. Κάθε διαγωνισμός θα αποτελούσε ξεχωριστό, one-time γεγονός με
 προβλήματα που θα είχαν δημιουργηθεί για αυτόν, διαγωνιζόμενους "μιας χρήσης"
-και υποβολές άρρηκτα συνδεδεμένες τόσο στον διαγωνισμό όσο και στο εκάστοτε 
-πρόβλημα. 
+και υποβολές άρρηκτα συνδεδεμένες τόσο στον διαγωνισμό όσο και στο εκάστοτε
+πρόβλημα.
 
 \bigskip
 
 Τα προβλήματα, έπειτα από τη δημιουργία τους, παραμένουν ανένταχτα, στην κατηγορία
-"Προβλήματα εκτός διαγωνισμών" της οθόνης διαχείρισης 
+"Προβλήματα εκτός διαγωνισμών" της οθόνης διαχείρισης
 όπως φαίνεται και σε screenshot παρακάτω. Το επόμενο βήμα είναι η μετακίνηση τους
 σε κάποιον διαγωνισμό με χρήση του μενού στα δεξιά του προβλήματος. Η μετακίνηση
-αυτού του τύπου είναι ο μόνος τρόπος να επαναχρησιμοποιηθεί το πρόβλημα και σε 
+αυτού του τύπου είναι ο μόνος τρόπος να επαναχρησιμοποιηθεί το πρόβλημα και σε
 άλλους διαγωνισμούς, αφότου τελειώσει αυτός για τον οποίο δημιουργήθηκε
 (ουσιαστικά, ο πρώτος στον οποίο μετακινήθηκε). Το θέμα που δημιουργείται, σε αυτό
-το σημείο, είναι ότι κατά τη μετακίνηση του, το πρόβλημα διατηρεί όλες τις 
-προηγούμενες υποβολές του, οι οποίες πρακτικά αγνοούνται στο νέο διαγωνισμό, ενώ 
+το σημείο, είναι ότι κατά τη μετακίνηση του, το πρόβλημα διατηρεί όλες τις
+προηγούμενες υποβολές του, οι οποίες πρακτικά αγνοούνται στο νέο διαγωνισμό, ενώ
 ο προηγούμενος διαγωνισμός χάνει το πρόβλημα που είχε. Όλα τα παραπάνω οφείλονται
 στον τρόπο που είναι σχεδιασμένη η βάση, ο οποίος παρουσιάζεται παρακάτω.
 
@@ -784,30 +880,30 @@ testcase groups.
 κάθε προβλήματος με το διαγωνισμό γίνεται μέσω του πεδίο compid στον πίνακα
 των προβλημάτων. Ως αποτέλεσμα, το μόνο που κάνει η λειτουργία της μετακίνησης
 προβλήματος σε άλλον διαγωνισμό είναι να αλλάξει αυτό το πεδίο. Επιπροσθέτως,
-όπως βλέπουμε, οι υποβολές συνδέονται άμεσα μόνο με τα προβλήματα και αυτός 
+όπως βλέπουμε, οι υποβολές συνδέονται άμεσα μόνο με τα προβλήματα και αυτός
 είναι ο λόγος που μεταφέρονται μαζί με αυτά κατά τη μετακίνηση τους.
 
 \bigskip
 
-Τέλος, είναι αξιοσημείωτος ο τρόπος που στον πίνακα finalresults, στον 
+Τέλος, είναι αξιοσημείωτος ο τρόπος που στον πίνακα finalresults, στον
 οποίο καταχωρούνται τα αποτελέσματα μετά την τελική αξιολόγηση, αποθηκεύονται
 τα επιμέρους σκορ των προβλημάτων του· χωρισμένα απλά με κόμμα, σύμφωνα με μια
 αύξουσα ταξινόμηση των id των προβλημάτων που περιείχε κατά την τελική αξιολόγηση.
 Παραδείγματος χάρη, αν ο διαγωνισμός 15 περιέχει τα προβλήματα 48 και 51 και ένας
 διαγωνιζόμενος έχει λάβει 7 βαθμούς στο πρώτο και 9 στο δεύτερο, το πεδίο score θα
-έχει την τιμή 16 και το πεδίο scoredetails θα έχει την τιμή 7,9. Όπως γίνεται 
+έχει την τιμή 16 και το πεδίο scoredetails θα έχει την τιμή 7,9. Όπως γίνεται
 αντιληπτό, όταν αλλάξει η σύνθεση ενός διαγωνισμού, χάνεται η ιστορικότητα των
 αποτελεσμάτων αφού δεν είναι δυνατό να ανακτηθεί από τη βάση η σύνδεση των
-βαθμολογιών με τα προβλήματα του διαγωνισμού. 
+βαθμολογιών με τα προβλήματα του διαγωνισμού.
 
 \bigskip
 
 \section{Υλοποίηση}
 
 Η κύρια λειτουργική αλλαγή/δυνατότητα που θα προστεθεί είναι αυτή της προσθήκης
-των προβλημάτων σε νέους διαγωνισμούς χωρίς να επηρεάζονται οι προηγούμενοι. 
-Το κύριο μέρος της υλοποίησης για τη συγκεκριμένη δυνατότητα/βελτίωση αποτελεί 
-η αλλαγή στους πίνακες της βάσης και στις σχέσεις μεταξύ τους. 
+των προβλημάτων σε νέους διαγωνισμούς χωρίς να επηρεάζονται οι προηγούμενοι.
+Το κύριο μέρος της υλοποίησης για τη συγκεκριμένη δυνατότητα/βελτίωση αποτελεί
+η αλλαγή στους πίνακες της βάσης και στις σχέσεις μεταξύ τους.
 
 \bigskip
 
@@ -815,16 +911,16 @@ testcase groups.
 με τα προβλήματα που διαθέτει. Το πεδίο στον πίνακα των προβλημάτων που έως
 τώρα χρησίμευε για αυτή τη σύνδεση, δεν αρκεί αφού πλέον θέλουμε να υπάρχει
 σχέση πολλά προς ένα για προβλήματα και διαγωνισμούς. Ο νέος πίνακας χρειάζεται
-απλά να περιέχει τα πεδία compid και probid. 
+απλά να περιέχει τα πεδία compid και probid.
 
 \bigskip
 
 Όπως αναφέρθηκε και παραπάνω, οι υποβολές θα πρέπει να συνδέονται με το
-διαγωνισμό και όχι με το πρόβλημα.  Αυτό θα επιτευχθεί με την προσθήκη του
-πεδίου compid στον πίνακα των υποβολών.  Με αυτό τον τρόπο, είναι εύκολο να
+διαγωνισμό και όχι με το πρόβλημα. Αυτό θα επιτευχθεί με την προσθήκη του
+πεδίου compid στον πίνακα των υποβολών. Με αυτό τον τρόπο, είναι εύκολο να
 γίνει ο διαχωρισμός των υποβολών ανά διαγωνισμό και πρόβλημα ώστε κάθε πρόβλημα
 να μπορεί να έχει ξεχωριστά δεδομένα υποβολών και αποτελεσμάτων σε κάθε
-διαγωνισμό που ανήκει. 
+διαγωνισμό που ανήκει.
 
 \bigskip
 
@@ -833,12 +929,12 @@ testcase groups.
 θα έχει την ίδια λογική, δηλαδή θα αναγράφει τις επιμέρους βαθμολογίες σε κάθε
 πρόβλημα του διαγωνισμού. Η διαφορά θα είναι ότι δε θα σημειώνεται στη βάση μόνο
 η βαθμολογία αλλά ζευγάρια probid: βαθμολογία. Στο παράδειγμα που χρησιμοποιήθηκε
-προηγουμένως, το πεδίο θα έχει τη μορφή {48: 7, 51: 9}. 
+προηγουμένως, το πεδίο θα έχει τη μορφή {48: 7, 51: 9}.
 
 \bigskip
 
 Χάρη στην προσθήκη του πεδίου scoredetailsjson, ένας διαχειριστής θα μπορεί να δει
-με λεπτομέρεια τα αποτελέσματα ενός διαγωνισμού για κάθε διαγωνιζόμενο ακόμα και 
+με λεπτομέρεια τα αποτελέσματα ενός διαγωνισμού για κάθε διαγωνιζόμενο ακόμα και
 αν έχει αλλάξει η δομή του, κάτι που πριν ήταν αδύνατο. Βεβαίως, από τη στιγμή που
 θα εισαχθεί η δυνατότητα αντιγραφής αντί μετακίνησης των προβλημάτων δε θα τίθεται
 συχνά θέμα αλλαγής της δομής ενός διαγωνισμού μετά τον υπολογισμό αποτελεσμάτων και
@@ -847,12 +943,12 @@ testcase groups.
 \bigskip
 
 Έπειτα από τις αλλαγές που περιγράφηκαν, η νέα μορφή της βάσης φαίνεται στο σχήμα3.
-Ο πίνακας compproblems είναι η νέα προσθήκη που είναι αναγκαία για τη σύνδεση 
+Ο πίνακας compproblems είναι η νέα προσθήκη που είναι αναγκαία για τη σύνδεση
 προβλημάτων με διαγωνισμός διατηρώντας μια κανονικοποιημένη βάση για αποφυγή του
 πλεονασμού δεδομένων. (TODO: ισως αναφορα σε κατι σχετικο). Νέα πεδία προστέθηκαν,
-επίσης και στους πίνακες submissions και finalresults. 
+επίσης και στους πίνακες submissions και finalresults.
 
-\bigskip 
+\bigskip
 
 (TODO: πινακας σχημα3 με νεα βάση)
 
@@ -863,11 +959,11 @@ testcase groups.
 των προβλημάτων και να αξιοποιούνται τα νέα πεδία και πίνακες. Η πλειοψηφία των
 αλλαγών αφορούν την οθόνη διαχείρισης, καθώς εκεί πρέπει να αλλάξει ο τρόπος
 που αντιστοιχίζονται τα προβλήματα με τους διαγωνισμούς, όπως και οι υποβολές
-αυτών.  Ακόμα, η λειτουργία του πλήκτρου μετακίνησης αλλάζει σε αντιγραφή, πάλι
+αυτών. Ακόμα, η λειτουργία του πλήκτρου μετακίνησης αλλάζει σε αντιγραφή, πάλι
 επιλέγοντας διαγωνισμό. Τέλος, στο κάτω μέρος της οθόνης, όπου αναγράφονταν τα
 ανένταχτα προβλήματα, κρίθηκε προτιμότερο να αναγράφονται όλα τα προβλήματα
 ώστε να είναι ευκολότερο να αναζητηθεί και να αντιγραφεί κάποιο σε ένα νέο
-διαγωνισμό.  Η νέα διαχείριση παρουσιάζεται στη φωτογραφία4.
+διαγωνισμό. Η νέα διαχείριση παρουσιάζεται στη φωτογραφία4.
 
 \bigskip
 
@@ -886,7 +982,7 @@ testcase groups.
 Το ενδεχόμενο να χρειαστεί κάποια αλλαγή σε πρόβλημα που ανήκει ήδη σε
 παλαιότερους ή παράλληλους διαγωνισμούς δε μπορεί να αποκλειστεί, και για το
 λόγο αυτό προστέθηκε ένα προειδοποιητικό μήνυμα προς όποιο διαχειριστή
-επιχειρήσει τέτοιες αλλαγές. 
+επιχειρήσει τέτοιες αλλαγές.
 
 \chapter{Λοιπές Προσθήκες}