Commit 7f4eb6ae authored by Antonios Angelakis's avatar Antonios Angelakis

Finish chapter 4

parent e012437b
......@@ -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{Σχεδίαση για διαχωρισμό Προβλημάτων - Διαγωνισμών}
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment