thesis.tex

\documentclass[diploma]{softlab-thesis}
\setlength\parindent{0pt}

\usepackage{listings}
\usepackage[section]{placeins}
\usepackage{hyperref}

%%%
%%%  The document
%%%

\begin{document}

%%%  Title page

\frontmatter

%%% TODO change
\title{Σχεδίαση και Επέκταση ενός Συστήματος Αυτόματης Αξιολόγησης Προγραμματιστικών Ασκήσεων}
\author{Αντώνιος Αγγελάκης}
\date{Μάρτιος 2018}
%%% TODO change
\datedefense{17}{3}{2018}

\supervisor{Νικόλαος Παπασπύρου}
\supervisorpos{Αν. Καθηγητής Ε.Μ.Π.}

\committeeone{Νικόλαος Παπασπύρου}
\committeeonepos{Αν. Καθηγητής Ε.Μ.Π.}
\committeetwo{Αριστείδης Παγουρτζής}
\committeetwopos{Αν. Καθηγητής Ε.Μ.Π.}
\committeethree{Γεώργιος Στάμου}
\committeethreepos{Αν. Καθηγητής Ε.Μ.Π.}

%%% TODO change
\TRnumber{CSD-SW-TR-42-18}  % number-year, ask nickie for the number
\department{Τομέας Τεχνολογίας Πληροφορικής και Υπολογιστών}

\maketitle


%%%  Abstract, in Greek

\begin{abstractgr}%

  Τα συστήματα αυτόματης αξιολόγησης προγραμματιστικών ασκήσεων αποτελούν εδώ
  και αρκετά χρόνια απαραίτητο εργαλείο για τη διεξαγωγή ολυμπιάδων και
  διαγωνισμών πληροφορικής, ενώ παράλληλα διευκολύνουν σε μεγάλο βαθμό την
  διαδικασία αξιολόγησης εργασιών στον ακαδημαϊκό τομέα. Σκοπός της παρούσας
  διπλωματικής εργασίας είναι η μελέτη συστημάτων τέτοιου τύπου καθώς και η
  επέκταση του συστήματος αξιολόγησης Grader που χρησιμοποιείται από το
  Εργαστηρίου Τεχνολογίας Λογισμικού του ΕΜΠ και τον Πανελλήνιο Διαγωνισμό
  Πληροφορικής.

  \bigskip

  Αρχικά, μελετούνται μερικά από τα σημαντικότερα συστήματα αυτόματης
  αξιολόγησης ελεύθερου λογισμικού, τα οποία κατέχουν διαπιστευτήρια από τις
  μεγαλύτερες διοργανώσεις προγραμματισμού. Έπειτα, παρουσιάζεται η σχεδίαση
  του Grader και ο τρόπος λειτουργίας του. Τέλος, αναλύονται οι επεκτάσεις που
  έγιναν στο Grader στο πλαίσιο της παρούσας εργασίας. Οι επεκτάσεις αυτές
  βελτιώνουν τη λειτουργικότητα του Grader, καθιστώντας το ένα πιο ευέλικτο και
  σταθερό σύστημα και αυτοματοποιώντας πολλές χρονοβόρες διαδικασίες.

\begin{keywordsgr}
Συστήματα αξιολόγησης, Συστήματα διαχείρισης διαγωνισμών, CMS, Grader, PHP,
Python, Ανάπτυξη Λογισμικού, Λογισμικό ανοιχτού κώδικα, Ελεύθερο λογισμικό.
\end{keywordsgr}
\end{abstractgr}


%%%  Abstract, in English

\begin{abstracten}%

  For several years now, automatic grading systems for programming exercises
  are considered an indispensable tool for conducting Olympiads in Informatics and
  programming competitions, while greatly facilitating the grading process in
  the academic field. The purpose of this diploma thesis is the study of such
  systems as well as the extension of Grader, the grading system used by the
  NTUA's Software Engineering Laboratory and the Panhellenic Informatics
  Competition.

  \bigskip

  Initially, we investigate some of the most renowned FOSS automatic grading
  systems which have been used from the greatest international competitions.
  Afterwords, we present Grader's design and mode of operation. Finally, we
  analyze the extensions implemented for Grader in the context of this thesis.
  These extensions improve the functionality of Grader, making it a more
  versatile and stable system and automating many time-consuming common tasks.


\begin{keywordsen}
Grading Systems, Contest management systems, CMS, Grader, PHP, Python,
Software development, Free and open source software.
\end{keywordsen}
\end{abstracten}


%%%  Acknowledgements

\begin{acknowledgementsgr}
  Θα ήθελα να ευχαριστήσω θερμά τον επιβλέποντα της διπλωματικής μου εργασίας,
  κ. Νίκο Παπασπύρου για την ευκαιρία που μου έδωσε να συνεργαστώ μαζί του,
  το χρόνο που μου αφιέρωσε και την υποστήριξη του.

  \bigskip

  Επιπλέον, ευχαριστώ πολύ την οικογένεια μου που στάθηκε δίπλα μου όλα αυτά
  τα χρόνια και τους φίλους και συμφοιτητές μου που με στήριξαν σε όλη τη
  διάρκεια των σπουδών μου.
\end{acknowledgementsgr}


%%%  Various tables

\tableofcontents
\listoftables
\listoffigures


%%%  Main part of the book

\mainmatter

\chapter{Εισαγωγή}

\section{Σκοπός}

Ο σκοπός της παρούσας διπλωματικής εργασίας είναι ο σχεδιασμός και η υλοποίηση
νέων δυνατοτήτων σε ένα σύστημα αυτόματης αξιολόγησης προγραμματιστικών
ασκήσεων. Το σύστημα που τροποποιήθηκε χρησιμοποιείται τόσο από το Εργαστήριο
Τεχνολογίας Λογισμικού \footnote{\url{http://grader.softlab.ntua.gr}}, για
προγραμματιστικές ασκήσεις και εξετάσεις, όσο και από την Ελληνική Εταιρεία
Επιστημόνων και Επαγγελματιών Πληροφορικής και Επικοινωνιών (ΕΠΥ)
\footnote{\url{http://hellenico.gr/grader}} για τη διοργάνωση των Πανελλήνιων
Διαγωνισμών Πληροφορικής.

\bigskip

Το σύστημα αυτόματης αξιολόγησης (Grader) δέχεται τις υποβολές των
διαγωνιζομένων σε συγκεκριμένα προβλήματα που ανήκουν σε διαγωνισμούς, ώστε να
τις χαρακτηρίσει ενεργές ή όχι, αξιολογώντας το αποτέλεσμα και την απόδοση τους
σε συγκεκριμένα αρχεία ελέγχου. Έπειτα, αφού κλείσουν οι υποβολές,
επαναξιολογεί όλες τις ενεργές υποβολές αυτόματα, ώστε να παράξει τα τελικά
αποτελέσματα.

\bigskip

Ο Grader, στην πρότερη κατάσταση του, επέτρεπε μόνο τη δημιουργία μεμονωμένων
αρχείων ελέγχου και όχι συνδυαστικών ομάδων περιορίζοντας την ευελιξία των
διαχειριστών και μην επιτρέποντας οποιαδήποτε ομαδοποίηση ή χαρακτηρισμό των
αρχείων. Επιπροσθέτως, ήταν εμφανής η έλλειψη ενός τύπου εκτέλεσης αρχείου ελέγχου
που να μην προκαθορίζει την αξιολόγηση μιας υποβολής ως θετική ή αρνητική ανεξάρτητα
από την έκβαση του.

\bigskip

Η αρχική σχεδίαση του Grader είχε σκοπό τη δημιουργία ενός συστήματος αυτόματης
αξιολόγησης για διαγωνισμούς πληροφορικής, για να χρησιμοποιηθεί κυρίως από την
ΕΠΥ. Ως αποτέλεσμα, κάθε πρόβλημα αντιστοιχίζεται σε έναν μόνο διαγωνισμό και τόσο
οι διαγωνιζόμενοι όσο και οι υποβολές τους συνδέονται με το πρόβλημα. Για τη χρήση
του Grader σε εργασίες προγραμματισμού, θα μας ωφελούσε η ύπαρξη διαχωρισμού
προβλήματος και υποβολών ώστε τα προβλήματα να μπορούν να επαναχρησιμοποιηθούν
ευκολότερα, χωρίς να "κουβαλάνε" τις υποβολές που έχουν γίνει σε αυτά.

\bigskip

Επιπλέον, κρίθηκε σημαντικό να προστεθεί η Python στις διαθέσιμες γλώσσες
υποβολής καθώς πρόκειται για μια από τις πλέον δημοφιλείς γλώσσες και
χρησιμοποιείται ως εισαγωγική γλώσσα προγραμματισμού σε σπουδαία ακαδημαϊκά
ιδρύματα, όπως είναι το MIT και το Stanford \cite{popularpython}.
Τέλος, ήταν απαραίτητο να γίνουν μικρές βελτιστοποιήσεις στη λογική του Grader,
να προστεθούν μικρότερες δυνατότητες που επιδιώκουν τη βελτίωση της ευκολίας
χρήσης για διαγωνιζόμενους και διαχειριστές και να αντικατασταθούν
απαρχαιωμένα, χωρίς ενεργή ανάπτυξη εργαλεία/βιβλιοθήκες για την επίτευξη
καλύτερης απόδοσης και ασφάλειας.

\newpage

\section{Δομή Εργασίας}

Η εργασία ακολουθεί την παρακάτω δομή:

\begin{itemize}
  \item \textbf{Κεφάλαιο 2}: Συστήματα Αυτόματης Αξιολόγησης \\
    Παρουσιάζουμε κάποια γνωστά συστήματα αυτόματης αξιολόγησης με παρόμοια
    λειτουργία και σκοπό με το Grader.
  \item \textbf{Κεφάλαιο 3}: Περιγραφή Grader - Kewii \\
    Περιγράφονται τα βασικά δομικά στοιχεία και έννοιες του συστήματος που
    μελετούμε. Αναλύεται το σύστημα αξιολόγησης Kewii, η διαδικτυακή
    εφαρμογή Grader και η επικοινωνία μεταξύ τους.
  \item \textbf{Κεφάλαιο 4}: Προσθήκη Ομάδων Αρχείων Ελέγχου \\
    Περιγράφεται αρχικά η προσθήκη του blue tag, ενός νέου τύπου εκτέλεσης
    αρχείων ελέγχου. Αναλύεται η σχεδιαστική λογική και η υλοποίηση της νέας
    δυνατότητας του Grader με σκοπό την ομαδοποίηση των αρχείων ελέγχου.
  \item \textbf{Κεφάλαιο 5}: Σχεδίαση για διαχωρισμό Προβλημάτων - Διαγωνισμών \\
    Περιγράφεται η υλοποίηση της τροποποίησης του συστήματος για την βελτίωση
    της λειτουργίας του Grader στο πλαίσιο προγραμματιστικών ασκήσεων.
  \item \textbf{Κεφάλαιο 6}: Λοιπές Προσθήκες \\
    Στο συγκεκριμένο κεφάλαιο παρατίθενται βελτιώσεις και προσθήκες μικρότερου
    μεγέθους: Προσθήκη της Python, μαζικό ανέβασμα αρχείων/ομάδων και αλλαγή
    επέκτασης MySQL.
  \item \textbf{Κεφάλαιο 7}: Συμπεράσματα \\
    Στο τελευταίο κεφάλαιο παρουσιάζονται παρατηρήσεις σχετικά με τη
    διπλωματική και αναφέρονται ιδέες για περαιτέρω ανάπτυξη του συστήματος.
\end{itemize}


\chapter{Συστήματα Αυτόματης Αξιολόγησης}

O Grader έχει σκοπό τη διοργάνωση προγραμματιστικών διαγωνισμών ή εργασιών
με αυτόματο τρόπο υποβολής, εκτέλεσης και αξιολόγησης των λύσεων. Το παρόν
σύστημα είναι κλειστού κώδικα, όμως θα είχε σημασία να μελετήσουμε συστήματα
με παρόμοια λειτουργία ώστε να δούμε ομοιότητες και διαφορές με το δικό μας.

\bigskip

Προτιμήθηκε να ελεγχθούν μόνο συστήματα ελεύθερου λογισμικού και ανοιχτού
κώδικα διότι μας προσφέρουν σημαντικά πλεονεκτήματα. Αρχικά, μας επιτρέπουν να
ερευνήσουμε τον τρόπο που είναι σχεδιασμένα και να πάρουμε ιδέες για τον
Grader. Επιπλέον, πολλές φορές παρέχουν καλύτερη ασφάλεια, καθώς οποιοσδήποτε
μπορεί να ελέγξει τον κώδικα για ευπάθειες. Φυσικά, το τελευταίο ισχύει υπό την
προϋπόθεση ότι υπάρχει πρωτοβουλία για ανεξάρτητο έλεγχο της ασφάλειας (audit),
αφού η απλή δημοσιοποίηση του κώδικα μπορεί να δίνει την ψευδαίσθηση (όπως
αναφέρεται στο \cite{hansen2002open}). Τέλος, η μελέτη των εν λόγω συστημάτων
είναι απαραίτητη αφού, χάρη στην ελευθερία χρήσης που προσφέρουν, μπορούν να
αντικαταστήσουν το Grader χωρίς μεγάλο κόστος (κυρίως αυτό της μετάβασης) σε
περίπτωση που κριθούν ως ανώτερα.

\bigskip

Τα συστήματα που θα μελετηθούν είναι τα παρακάτω:

\begin{itemize}
    \setlength\itemsep{0em}
    \item CMS
    \item Mooshak 2.0
    \item CATS
\end{itemize}

Και τα 3 έχουν σχεδιαστεί με σκοπό τη διεξαγωγή προγραμματιστικών διαγωνισμών,
ολυμπιάδων πληροφορικής, αλλά και χρήση για εργαστηριακές ασκήσεις και
εργασίες.

\section{CMS}

Το πρώτο σύστημα που θα μελετήσουμε είναι το Contest Management System, CMS εν
συντομία \footnote{\url{https://cms-dev.github.io/}}. Πρόκειται για ένα κατανεμημένο σύστημα διαχείρισης και διεξαγωγής
διαγωνισμών το οποίο σχεδιάστηκε αρχικά για την Διεθνή Ολυμπιάδα Πληροφορικής
του 2012. Αποτελείται από ένα πλήθος μικρο-υπηρεσιών που συνθέτουν το συνολικό
σύστημα.

\bigskip

Είναι, πιθανότατα, το πιο ολοκληρωμένο σύστημα για διαγωνισμούς, δεδομένου του
μεγάλου αριθμού διαπιστευτηρίων που κατέχει, συμπεριλαμβανομένης της χρήσης του
σε όλες σχεδόν τις Διεθνείς Ολυμπιάδες από το 2012. Οι δημιουργοί του είχαν ως
στόχο τη δημιουργία ενός συστήματος ασφαλούς, ανθεκτικού σε σφάλματα λογισμικού
και υλικού, ανοιχτού, επεκτάσιμου και εύχρηστου.

\bigskip

Η ανάπτυξη του ξεκίνησε το 2010 και πλέον βασίζεται στην κοινότητα για
συνεισφορά στην ανάπτυξη του, στην προσθήκη μεταφράσεων και στη βελτίωση του
documentation. H άδεια που χρησιμοποιεί είναι η AGPL-3+ (GNU Affero General
Public License), η οποία επιτρέπει εμπορική χρήση, τροποποίηση και διανομή, με
την προϋπόθεση να παραμείνει η ίδια άδεια και να δημοσιευτεί ο πηγαίος κώδικας.

\subsection{Τεχνικά Χαρακτηριστικά}

Το CMS είναι γραμμένο σε Python και αποτελείται από πολλά μικρά κομμάτια που
αναλαμβάνουν μια ξεχωριστή λειτουργία. Αυτά μπορούν να έχουν εγκατασταθεί σε
διαφορετικούς εξυπηρετητές, ακόμα και σε απομακρυσμένα συστήματα. Οι
υπηρεσίες-κομμάτια, από τα οποία αποτελείται είναι τα παρακάτω:

\begin{itemize}
    \setlength\itemsep{0em}
    \item LogService \\
      Συλλέγει σε ένα μέρος όλα τα μηνύματα καταγραφής.
    \item ResourceService \\
      Λαμβάνει δεδομένα για όλες τις υπηρεσίες που τρέχουν και μπορεί να τις
      ξεκινήσει ταυτόχρονα.
    \item Checker \\
      Ελέγχει την κατάσταση των υπηρεσιών.
    \item EvaluationService \\
      Οργανώνει την ουρά υποβολών και διανέμει τις εργασίες στους Workers.
    \item Worker
      Εκτελεί τις εργασίες σε ένα αποκλεισμένο περιβάλλον.
    \item ScoringService \\
      Συλλέγει τα αποτελέσματα των εκτελέσεων και τα αξιολογεί για να παράξει
      τις βαθμολογίες.
    \item ProxyService \\
      Στέλνει τις βαθμολογίες στον εξυπηρετητή Αποτελεσμάτων.
      (\cite{maggiolo2014cms})
    \item PrintingService \\
      Αναλαμβάνει την εκτύπωση των εγγράφων.
    \item ContestWebServer \\
      Ο εξυπηρετητής της ιστοσελίδας του διαγωνισμού, με τον οποίο αλληλεπιδρούν
      οι διαγωνιζόμενοι.
    \item AdminWebServer \\
      Ο εξυπηρετητής της ιστοσελίδας διαχείρισης του διαγωνισμού.
    \item RankingWebServer \\
      Ο εξυπηρετητής της ιστοσελίδας εμφάνισης των αποτελεσμάτων.
\end{itemize}

\bigskip

Όλες οι παραπάνω λειτουργίες αλληλεπιδρούν μεταξύ τους με τον τρόπο που φαίνεται
στο σχήμα 2.1.

\begin{figure}
  \centering
  \includegraphics[scale=0.45,trim=4 4 4 4,clip]{Figures/cmsarchitecture.png}
  \caption[Η αρχιτεκτονική του CMS]{Οι κυριότερες υπηρεσίες του CMS και οι
  σχέσεις μεταξύ τους. Βασισμένο στο σχήμα 1 του
  \cite{maggiolo2012introducing}.}
\end{figure}

\bigskip

Ο κύκλος διεξαγωγής ενός διαγωνισμού είναι γνώριμος. Αφού στηθούν όλες οι
απαραίτητες υπηρεσίες, οι διαχειριστές μπορούν να δημιουργήσουν το διαγωνισμό
μέσω του AdminWebServer, μαζί με τα προβλήματα και τα τεστ που περιέχει.
Έπειτα, κάθε διαγωνιζόμενος αλληλεπιδρά με τη σελίδα υποβάλλοντας τις λύσεις
του. Αυτές αποθηκεύονται στο δίσκο μέχρι να δοθούν σε κάποιο Worker από το
EvaluationService και να εκτελεστούν στο ασφαλές περιβάλλον. Σε εκείνο το
σημείο αναλαμβάνει τα ηνία το ScoringService που αξιολογεί τις εκτελέσεις και
στέλνει τα αποτελέσματα στο RankingWebServer, ώστε να ανανεωθεί με την
τελευταία εικόνα.

\bigskip

Η βάση που χρησιμοποιεί το CMS είναι PostgreSQL και η λειτουργία του βασίζεται
σε αποκλειστικά χαρακτηριστικά της (LO, Large Object), οπότε μόνο αυτή
υποστηρίζεται. Οι γλώσσες προγραμματισμού που υποστηρίζει η ευσταθής έκδοση του
είναι οι: C, C++, PHP, Pascal, Java και Python2. Στην τελευταία έκδοση υπό
ανάπτυξη (development) υποστηρίζονται επίσης C\#, Haskell, Python3 και Rust.
Για την επέκταση του με παραπάνω γλώσσες αρκεί η προσθήκη ενός αρχείου
προδιαγραφών για κάθε νέα γλώσσα.

\subsection{Εγκατάσταση και Χρήση}

Η εγκατάσταση προϋποθέτει την ύπαρξη πλήθους εργαλείων για την υποστήριξη των
γλωσσών και του συστήματος. Όπως έχει αναφερθεί, το CMS αποτελείται από πολλές
διαφορετικές υπηρεσίες, οι οποίες πρέπει να τρέχουν σε ένα ή παραπάνω μηχανήματα
για την πλήρη λειτουργία. Χάρη στην ύπαρξη του ResourceService όλες οι υπηρεσίες
ενός μηχανήματος μπορούν να εκκινήσουν ταυτόχρονα ώστε να μειωθεί η χρονοβόρα
εργασία.

\bigskip

Για να τρέξει, επίσης, το σύστημα θα πρέπει να γίνουν οι απαραίτητες ρυθμίσεις
στην βάση αλλά και στο CMS. Μόλις ολοκληρωθεί κι αυτό το βήμα, οι διαχειριστές
μπορούν να δημιουργήσουν διαγωνισμούς και προβλήματα με τρεις τρόπους: μέσω της
διεπαφής Admin, κατευθείαν από το σύστημα αρχείων τους περιγράφοντας με αρχείο
προδιαγραφών τη μορφή τους ή με απευθείας εισαγωγή προηγούμενου διαγωνισμού που
εξάχθηκε από CMS.

\bigskip

Οι διαγωνιζόμενοι συμμετέχουν στο διαγωνισμό μέσω της σελίδας του
ContestWebServer. Εκεί βλέπουν για κάθε πρόβλημα την περιγραφή του και όλα
τα σχετικά με αυτό στοιχεία και μπορούν να υποβάλλουν τις λύσεις τους. Ένα
ενδιαφέρον χαρακτηριστικό είναι ότι οι διαγωνιζόμενοι μπορούν να δημιουργούν
δικά τους αρχεία ελέγχου, στα οποία θα ελεγχθεί η λύση τους. Επιπλέον, υπάρχει
η δυνατότητα χρήσης tokens, τα οποία μοιράζονται στους διαγωνιζόμενους και
περιορίζουν τις φορές που μπορούν να δουν τα αναλυτικά αποτελέσματα της
υποβολής τους σε φανερά και κρυφά αρχεία ελέγχου.

\bigskip

Ακολουθούν φωτογραφίες από τις διεπαφές του διαγωνισμού, του Admin και της σελίδας
των αποτελεσμάτων.

\bigskip

\begin{figure}
  \centering
  \includegraphics[scale=0.4,trim=4 4 4 4,clip]{Figures/cmscontestant.png}
  \caption[Σελίδα προβλήματος CMS]{Η σελίδα ενός προβλήματος, όπως τη βλέπει ένας
  διαγωνιζόμενος. Διακρίνονται τα στοιχεία του προβλήματος και όλα τα
  επισυναπτόμενα. Πηγή: \url{https://cms-dev.github.io/screenshots.html}}
\end{figure}

\begin{figure}
  \centering
  \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/cmsranking.png}
  \caption[Σελίδα βαθμολογιών CMS]{Η σελίδα της βαθμολογίας, με τη συνολική κατάταξη
  και ανά διαγωνιζόμενο σε όλα τα προβλήματα. Πηγή: \url{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]{Η σελίδα της διαχείρισης ενός
  διαγωνισμού. Διακρίνονται συνολικά στατιστικά για τις υποβολές, η κατάσταση
  της ουράς και των Workers. Πηγή: \url{https://cms-dev.github.io/screenshots.html}}
\end{figure}

\FloatBarrier

\section{Mooshak 2.0}

Το Mooshak 2.0 \footnote{\url{https://mooshak2.dcc.fc.up.pt/}} είναι κι αυτό ένα
σύστημα διαχείρισης διαγωνισμών με αυτόματη αξιολόγηση για τις υποβολές.
Αποτελεί τη νεότερη υλοποίηση του Mooshak, με μεταφορά του κώδικά από C++ και
Tcl σε Java με χρήση της εργαλειοθήκης Google Web Toolkit. H αρχική έκδοση του
Mooshak δημιουργήθηκε το 2000 και βασίζεται σε ένα παλαιότερο διαδικτυακό
σύστημα εκμάθησης, το Ganesh. Ο κώδικας του διατίθεται επίσης ελεύθερα με χρήση
της άδειας Artistic License, η οποία δεν προϋποθέτει την διατήρηση άδειας
ελεύθερου λογισμικού σε μελλοντική τροποποίηση και διανομή.

\bigskip

Οι βασικές του προδιαγραφές βασίζονται στους κανόνες των διαγωνισμών ICPC, αλλά
υποστηρίζει και άλλες μορφές διαγωνισμών, όπως είναι οι Ολυμπιάδες πληροφορικής.
Έχει χρησιμοποιηθεί σε πληθώρα τοπικών και διεθνών διαγωνισμών αλλά και σταθερά
στο πλαίσιο εκμάθησης και αξιολόγησης φοιτητών (\cite{leal2008using}).

\subsection{Τεχνικά Χαρακτηριστικά}

Το Mooshak 2.0 βασίζεται σε μια κοινή αρχιτεκτονική εξυπηρετητή και πελατών με τη
διαφορά ότι υποστηρίζει τη δημιουργία πρόσθετων κόμβων. Οι κόμβοι αυτοί έχουν σκοπό
τη διατήρηση της σταθερότητας και απαιτούν συνεχή συγχρονισμό με τον κεντρικό
εξυπηρετητή ώστε να αναλαμβάνουν μέρος του δικτυακού φόρτου αλλά και να αποτελούν
εφεδρικές λύσεις σε περίπτωση βλάβης των υπολοίπων κόμβων.

\bigskip

\begin{figure}
  \centering
  \includegraphics[scale=0.45,trim=4 4 4 4,clip]{Figures/mooshakarchitecture.png}
  \caption[Η αρχιτεκτονική του Mooshak]{Η αρχιτεκτονική του Mooshak με τρεις
  εξυπηρετητές, όπου οι δύο βρίσκονται στο ίδιο τοπικό δίκτυο και όλοι
  συγχρονίζουν τα δεδομένα τους. Βασισμένο στο σχήμα 4 του
  \cite{leal2003mooshak}.}
\end{figure}

\bigskip

Αντίθετα με άλλα συστήματα, το Mooshak δε χρησιμοποιεί βάση και περιορίζεται
στην αποθήκευση όλων των δεδομένων του στο σύστημα αρχείων. Οι γλώσσες
προγραμματισμού που υποστηρίζει περιλαμβάνουν τις C, C++, Java, Pascal, Perl,
Python, Haskell, Haskell και Prolog, ενώ η επέκταση του ώστε να υποστηρίξει
πρόσθετες γλώσσες δεν αποτελεί δύσκολη διαδικασία (\cite{ribeiro2008early}).

\bigskip

Το σύστημα είναι επίσης παραμετροποιήσιμο ως προς τον τρόπο αξιολόγησης καθώς
έχει σχεδιαστεί για πολλούς διαφορετικούς τύπους διαγωνισμών. Χαρακτηριστικό
είναι ότι στη διαδικασία της υποβολής, πριν από τα στάδια της μεταγλώττισης,
της εκτέλεσης και της αξιολόγησης, δίνεται η δυνατότητα προσθήκης μιας
λειτουργίας στατικής ανάλυσης του πηγαίου κώδικα της υποβολής και αξιολόγησης
του με χρήση κριτηρίων ορισμένων από τους διαχειριστές του διαγωνισμού. Αυτό
επιτρέπει τη χρήση του Mooshak, παραδείγματος χάρη για ένα διαγωνισμό τύπου
code golf, δηλαδή επίτευξης της λύσης με το λιγότερο δυνατό κώδικα.

\subsection{Εγκατάσταση και Χρήση}

Η εγκατάσταση του Mooshak 2 δεν έχει πολλές απαιτήσεις. Συγκεκριμένα,
χρειάζεται μόνο το περιβάλλον της Java και το λογισμικό του εξυπηρετητή. Μόλις
γίνει αυτό, μπορούν να στηθούν επίσης επιπλέον κόμβοι εάν είναι επιθυμητό,
τοπικά ή απομακρυσμένα. Η δημιουργία των διαγωνισμών και των προβλημάτων
γίνεται μέσω της διαδικτυακής διεπαφής του Διαχειριστή.

\bigskip

Οι διαγωνιζόμενοι, μπαίνοντας στην ιστοσελίδα του Mooshak, μπορούν να διαβάσουν
τις περιγραφές των προβλημάτων και να πραγματοποιήσουν τις υποβολές τους είτε
ανεβάζοντας το πρόγραμμα τους, είτε χρησιμοποιώντας τον επεξεργαστή κειμένου της
ιστοσελίδας ώστε να το συντάξουν επιτόπου.

\bigskip

Οι δημιουργοί του Mooshak παραθέτουν στη σελίδα του μόνιμα περιβάλλοντα δοκιμών,
στα οποία μπορεί ο οποιοσδήποτε να χρησιμοποιήσει ένα ζωντανό Mooshak σύστημα είτε
για να πραγματοποιήσει υποβολές, είτε για να δημιουργήσει νέους διαγωνισμούς και
προβλήματα.

\bigskip

\begin{figure}
  \centering
  \includegraphics[scale=0.45,trim=4 4 4 4,clip]{Figures/mooshakproblem.png}
  \caption[Σελίδα προβλήματος Mooshak]{Η σελίδα παρουσίασης ενός προβλήματος για τους
  διαγωνιζόμενους στο σύστημα Mooshak.}
\end{figure}

\begin{figure}
  \centering
  \includegraphics[scale=0.45,trim=4 4 4 4,clip]{Figures/mooshakrankings.png}
  \caption[Σελίδα βαθμολογίας Mooshak]{Η σελίδα βαθμολογίας όλων των διαγωνιζόμενων
  ομάδων σε ένα διαγωνισμό.}
\end{figure}

\FloatBarrier

\section{CATS}

To CATS \footnote{imcs.dvfu.ru/cats?lang=en} είναι το τρίτο σύστημα που θα
αναλυθεί. Αφορά και αυτό τη διεξαγωγή και τον έλεγχο προγραμματιστικών
διαγωνισμών και συντηρείται από τον Alexander Klenin του Far Eastern Federal
University (\cite{Rozhkov}). Χρησιμοποιείται τόσο για μεγάλες διοργανώσεις,
όπως είναι το ICPC Ρωσίας και Άπω Ανατολής, καθώς και για πλήθος ακαδημαϊκών
μαθημάτων και διαγωνισμών. Κατέχει άδεια GPL 2.0 επιτρέποντας την ελεύθερη
χρήση, τροποποίηση και διανομή του.

\bigskip

Έχει αρκετές δυνατότητες που το διακρίνουν ανάμεσα στα υπόλοιπα συστήματα
συμπεριλαμβανομένων των παρακάτω:

\begin{itemize}
    \item Μεγάλος αριθμός προγραμματιστικών γλωσσών και μεταγλωττιστών
    \item Αυτόματος ορισμός διαγωνισμών, προβλημάτων και αρχείων ελέγχου με χρήση
      ενός zip αρχείου με μια περιγραφή σε XML
    \item Έτοιμα πρόσθετα (modules) για την αξιολόγηση των υποβολών, π.χ. για
      αυτόματη δημιουργία αρχείων ελέγχου
    \item Περιορισμός πρόσβασης ανάλογα με τη διεύθυνση IP των χρηστών
    \item Αυτόματος έλεγχος για αντιγραφή κώδικα μεταξύ των διαγωνιζομένων
\end{itemize}

\subsection{Τεχνικά Χαρακτηριστικά}

Το CATS είναι υλοποιημένο σε Perl και χρησιμοποιεί βάση δεδομένων Oracle. Το
σύστημα αποτελείται από τον εξυπηρετητή που "σηκώνει" την ιστοσελίδα του
διαγωνισμού για διαγωνιζόμενους και διαχειριστές και από τον εξυπηρετητή των
αξιολογήσεων, ο οποίος αναλαμβάνει τη δημιουργία των δυνητικά επικίνδυνων
εργασιών που τρέχουν σε ένα περιορισμένο περιβάλλον με τη χρήση ενός πρόσθετου
που λέγεται spawner.

\bigskip

Η εφαρμογή αξιολόγησης εμπεριέχει διεπαφή μέσω της γραμμής εντολών για τη
γρήγορη δημιουργία και αξιολόγηση προβλημάτων από τους διαχειριστές. Αυτή
διατίθεται και ανεξάρτητα από το υπόλοιπο πρόγραμμα προς αντικατάσταση
αντίστοιχων διαδικτυακών εργαλείων όπως είναι το Polygon
\footnote{\url{https://polygon.codeforces.com/}}. Η δημιουργία των προβλημάτων
γίνεται με το ανέβασμα ενός συμπιεσμένου αρχείου το οποίο περιέχει μια XML
περιγραφή και τα απαραίτητα αρχεία ελέγχου.

\lstinputlisting[language=XML,frame=single,captionpos=b,caption=Παράδειγμα xml προβλήματος
CATS. Το CATS δημιουργεί τη σελίδα του προβλήματος και τα χαρακτηριστικά του
σύμφωνα με το συγκεκριμένο αρχείο ενώ διαθέτει δυνατότητα παρουσίασης LaTeX
τύπων\, όπως αυτός στο ProblemConstraints.]{Listings/catsexample.xml}

\bigskip

Οι γλώσσες προγραμματισμού που υποστηρίζονται είναι οι C, C++, delphi, VB, Java,
C\#, Perl, Python, Ruby, PHP, Erlang, Javascript και SQL.

\subsection{Εγκατάσταση και Χρήση}

Η εγκατάσταση του CATS είναι αρκετά εύκολη, καθώς έχει πολύ λίγες εξαρτήσεις
και διαθέτει έτοιμα scripts για το deployment και την αρχική παραμετροποίηση.
Αφού τρέξουν αυτά και ρυθμιστεί η σύνδεση με τη βάση, το σύστημα είναι έτοιμο
να χρησιμοποιηθεί.

\bigskip

Η διαδικασία εμφάνισης των ορισμών των προβλημάτων, υποβολής των λύσεων και
διαχείρισης των διαγωνισμών από τους διαχειριστές είναι παρόμοια με τα προηγούμενα
συστήματα και παρουσιάζεται με φωτογραφίες παρακάτω. Άξια αναφοράς είναι
η δυνατότητα του CATS για διαχείριση διαγωνισμών, αξιολόγηση και παρουσίαση των
αποτελεσμάτων απ᾽ευθείας μέσω της γραμμής εντολών μέσω ενός API που προσφέρεται.

\FloatBarrier

\begin{figure}
  \centering
  \includegraphics[scale=0.45,trim=4 4 4 4,clip]{Figures/catsproblem.png}
  \caption[Διατύπωση προβλήματος CATS]{Η σελίδα του προβλήματος στο CATS. Δεν
  περιέχει τίποτα παραπάνω από τη διατύπωση, αφού η υποβολή γίνεται από τη σελίδα
  του διαγωνισμού. Το σύστημα του CATS επιτρέπει και τη χρήση LaTeX όπως
  φαίνεται στο Restrictions.}
\end{figure}

\begin{figure}
  \centering
  \includegraphics[scale=0.3,trim=4 4 4 4,clip]{Figures/catssubmission.png}
  \caption[Σελίδα διαγωνισμού και υποβολής CATS]{Η σελίδα του διαγωνισμού που
  περιέχει όλα τα προβλήματα του. Επιλέγοντας ένα πρόβλημα μπορούμε να υποβάλουμε
  τη λύση στο κάτω μέρος της σελίδας.}
\end{figure}


\chapter{Περιγραφή Grader - Kewii}

Το σύστημα αποτελείται από το το σύστημα αξιολόγησης Kewii, το backend της
εφαρμογής μας που λειτουργεί ως δαίμονας (πρόγραμμα που τρέχει συνεχώς) στον
εξυπηρετητή με σκοπό την μεταγλώττιση και αξιολόγηση των υποβολών που λαμβάνει,
και από τη διαδικτυακή εφαρμογή Grader, η οποία αναλαμβάνει την αλληλεπίδραση
με χρήστες και διαχειριστές, την (έμμεση) επικοινωνία με τον Kewii και τη
συνολική υλοποίηση της λογικής του συστήματος όσον αφορά στον τρόπο λειτουργίας
των επιμέρους στοιχείων του και τον τρόπο αξιολόγησης. Ακολουθεί μια πρώτη
ανάλυση των δομικών στοιχείων και των αλληλεπιδράσεων τους, πριν αναλυθούν Kewii
και Grader.

\section{Στοιχεία και έννοιες του συστήματος}

Στην ενότητα αυτή θα περιγραφούν συνοπτικά τα επιμέρους στοιχεία του συστήματος
μας. Η έννοια και η λειτουργία τους είναι απαραίτητη για να γίνει αντιληπτός ο
διαχωρισμός μεταξύ Kewii και Grader, δηλαδή backend και frontend.

\subsection{Προβλήματα}

Προβλήματα είναι οι ανεξάρτητες ασκήσεις που τίθενται προς επίλυση στους
διαγωνιζόμενους/χρήστες. Κάθε πρόβλημα έχει χρονικά όρια εκτέλεσης και όρια
μνήμης, όπως και ιδιότητες για τον τρόπο εκτέλεσης και αξιολόγησης. Η
αξιολόγηση του γίνεται πάνω σε συγκεκριμένα αρχεία εισόδου και εξόδου, τα
αρχεία ελέγχου. Προαιρετικά, ένα πρόβλημα μπορεί, επιπλέον, να διαθέτει ένα
πρόγραμμα αξιολόγησης των υποβολών.

\bigskip

Τα προβλήματα έχουν νόημα αποκλειστικά μέσα σε διαγωνισμούς, καθώς η τελική
αξιολόγηση αφορά τους διαγωνισμούς και το σύνολο των προβλημάτων που περιέχουν.
Η αρχική σχεδίαση του συστήματος είχε ως στόχο τη χρήση του σε διαγωνισμούς
πληροφορικής, οπότε τα προβλήματα είναι συνδεδεμένα στενά τόσο με τον
διαγωνισμό που ανήκουν όσο και με τις υποβολές που έχουν γίνει σε αυτά. Κάθε
πρόβλημα μπορεί να ανήκει μόνο σε ένα διαγωνισμό.

\bigskip

Σε επόμενο κεφάλαιο θα διερευνηθεί και θα περιγραφεί η υλοποίηση ενός εναλλακτικού
σχεδιασμού που επιτρέπει την χρήση των προβλημάτων σε πολλαπλούς διαγωνισμούς και
την αλλαγή της σύνδεσης των υποβολών από το πρόβλημα προς τους διαγωνισμούς.

\subsection{Διαγωνισμοί}

Οι διαγωνισμοί αντιστοιχούν σε διοργανώσεις πληροφορικής, εξετάσεις ή σειρές
ασκήσεων. Εμπεριέχουν προβλήματα και είναι ενεργοί/ορατοί σε ένα χρονικό
διάστημα όπου οι διαγωνιζόμενοι μπορούν να υποβάλλουν τις λύσεις τους. Μόλις
ολοκληρωθεί η διεξαγωγή τους, ο διαχειριστής μπορεί να εκκινήσει την τελική
αξιολόγηση, κατά την οποία βαθμολογούνται οι ενεργές υποβολές των
διαγωνιζόμενων σε όλα τα προβλήματα του διαγωνισμού. Οι διαγωνισμοί μπορούν να
είναι ορατοί σε όλους ή μόνο σε επιλεγμένους χρήστες.

\subsection{Αρχεία Ελέγχου}

Τα αρχεία ελέγχου είναι ζευγάρια αρχείων εισόδου και εξόδου και ανήκουν σε
προβλήματα. Μια σωστή υποβολή/λύση θα πρέπει για κάθε αρχείο εισόδου που
δέχεται, να παράγει έξοδο ίδια με αυτή του αντίστοιχου αρχείου εξόδου.  Κάθε
αρχείο ελέγχου χαρακτηρίζεται από τους πόντους που αξίζει και από τον τύπο
εκτέλεσης του, που σχετίζεται με το πότε εκτελείται και αν είναι ορατό στους
χρήστες. Οι τύποι εκτέλεσης αντιστοιχούν σε χρώματα (tags) και παρουσιάζονται
στον Πίνακα 3.1.

  \begin{table}
    \begin{tabular}{ | l | p{10cm} |}
    \hline
    Τύπος εκτέλεσης & Λειτουργία \\ \hline
    Πορτοκαλί \includegraphics[scale=0.8]{Figures/tag_orange.png} &
      Το αρχείο ελέγχου χρησιμοποιείται σε κάθε υποβολή για το συγκεκριμένο πρόβλημα
      αλλά δεν είναι ορατό στους χρήστες. \\ \hline
    Κίτρινο \includegraphics[scale=0.8]{Figures/tag_yellow.png} &
      Το αρχείο ελέγχου χρησιμοποιείται σε κάθε υποβολή για το συγκεκριμένο πρόβλημα
      και είναι ορατό στους χρήστες. \\ \hline
    Πράσινο \includegraphics[scale=0.8]{Figures/tag_green.png} &
      Το αρχείο ελέγχου χρησιμοποιείται μόνο κατά την τελική αξιολόγηση. \\ \hline
    Μωβ \includegraphics[scale=0.8]{Figures/tag_purple.png} &
      Το αρχείο ελέγχου δεν χρησιμοποιείται. \\ \hline
    \end{tabular}
  \caption{Τύποι εκτέλεσης αρχείων ελέγχου}
  \end{table}

\bigskip

Σε επόμενο κεφάλαιο θα δημιουργηθεί ένας νέος τύπος εκτέλεσης. Επιπλέον, θα
αλλάξει ριζικά ο τρόπος αξιολόγησης καθώς θα εισαχθεί η έννοια των ομάδων
αρχείων ελέγχου και τα αρχεία θα αξιολογούνται μόνο μέσα σε αυτές.

\subsection{Χρήστες/Διαγωνιζόμενοι}

Οι χρήστες ή διαγωνιζόμενοι είναι τα άτομα που αλληλεπιδρούν με το σύστημα με
σκοπό την υποβολή λύσεων στους διαγωνισμούς που συμμετέχουν. Οι διαχειριστές
αποτελούν κι αυτοί χρήστες, με τη διαφορά ότι έχουν δικαίωμα πρόσβασης στις
σελίδες διαχείρισης διαγωνισμών και προβλημάτων. Οι τελευταίοι έχουν επίσης
δικαίωμα να εισάγουν νέους χρήστες από ένα αρχείο, να ορίσουν την ορατότητα των
διαγωνισμών για συγκεκριμένους διαγωνιζόμενους και να απαντήσουν σε μηνύματα
αυτών.

\subsection{Υποβολές}

Η υποβολή μιας λύσης προϋποθέτει το "ανέβασμα" του κώδικα του διαγωνιζόμενου για
να γίνει η μεταγλώττιση του στον εξυπηρετητή, να εκτελεστεί από τον Kewii για
κάθε αρχείο ελέγχου που αντιστοιχεί στο είδος της υποβολής και να αξιολογηθεί η
ορθότητα της εξόδου. Οι υποβολές χωρίζονται σε δύο κύριες κατηγορίες, την
κανονική και την τελική. Ουσιαστικά, όλες οι υποβολές των διαγωνιζόμενων είναι
κανονικές και εφόσον υπάρχει, για έναν διαγωνιζόμενο, τουλάχιστον μία υποβολή
που περνάει όλα τα αρχεία ελέγχου στα οποία αξιολογήθηκε, αυτή θεωρείται ενεργή
για αυτόν. Όταν ολοκληρωθεί η περίοδος ανοιχτών υποβολών ενός διαγωνισμού, όλες
οι ενεργές υποβολές για κάθε πρόβλημα του διαγωνισμού επαναυποβάλλονται στον
Kewii για την τελική αξιολόγηση τους.

\subsection{Προγράμματα Αξιολόγησης}

Οι υποβολές σε κάθε πρόβλημα αξιολογούνται συνήθως με σύγκριση της εξόδου του
υποβληθέντος προγράμματος με αυτήν του αρχείου ελέγχου για την αντίστοιχη
είσοδο. Εξαίρεση σε αυτό αποτελεί η δυνατότητα που παρέχει ο Kewii για ορισμό
ενός ειδικού προγράμματος αξιολόγησης στο πρόβλημα το οποίο αναλαμβάνει να
συγκρίνει την αναμενόμενη έξοδο με αυτήν που παρήγαγε το υποβληθέν πρόγραμμα
και να βαθμολογεί στην κλίμακα [0, 1]. Το πρόγραμμα αξιολόγησης είναι και αυτό
αποθηκευμένο στον εξυπηρετητή και μεταγλωττίζεται και εκτελείται κατά τη
διαδικασία αξιολόγησης.

\section{Σύστημα αξιολόγησης Kewii}

Ο Kewii είναι μια εφαρμογή γραμμένη στη γλώσσα C και τρέχει στον εξυπηρετητή
ελέγχοντας διαρκώς για την ύπαρξη νέων υποβολών. Για κάθε νέα υποβολή που εντοπίζει,
βρίσκει τον πηγαίο κώδικα που έχει αποθηκευτεί από τον Grader μαζί με συγκεκριμένα
μεταδεδομένα, μεταγλωττίζει τον κώδικα δημιουργώντας το εκτελέσιμο αρχείο και το
εκτελεί χρησιμοποιώντας τα απαραίτητα μέτρα ασφαλείας ώστε να συγκρίνει την έξοδο
για κάθε αρχείο ελέγχου με την σωστή. Μόλις τελειώσει η εκτέλεση ή ξεπεραστούν τα
όρια της, ενημερώνει τη βάση δεδομένων, με χρήση ενός PHP script, για την έκβαση της
εκτέλεσης και ειδοποιεί το Grader καλώντας ένα μοναδικό για κάθε υποβολή σύνδεσμο
(callback) ώστε αυτός να αναλάβει την ανάλυση των αποτελεσμάτων.

\bigskip

Κάθε υποβολή έχει έναν μοναδικό κωδικό, ο οποίος χρησιμοποιείται για την
αλληλεπίδραση με το Grader κατά το callback, όπως και έναν αύξοντα αριθμό που
χρησιμεύει στον Kewii για την διατήρηση της κατάστασης των εκτελέσεων. Τα
μεταδεδομένα που εμπεριέχονται σε κάθε υποβολή και είναι απαραίτητα για την
αξιολόγηση της είναι τα παρακάτω:

\begin{itemize}
  \item Όνομα του προβλήματος
  \item Γλώσσα υποβολής
  \item Αρχεία ελέγχου που θα χρησιμοποιηθούν
  \item Όριο μνήμης και χρόνου εκτέλεσης
  \item Είδος εκτέλεσης
  \item Τρόπος αξιολόγησης
\end{itemize}

Κάθε πρόβλημα πρέπει να έχει μοναδικό όνομα και είναι απαραίτητο ώστε να
επιλεχθούν τα σωστά αρχεία ελέγχου. Οι γλώσσες υποβολής που υποστηρίζονται
είναι: C, C++, Pascal, Pazcal, F\#, OCaml, SML, Java, Fortran και Haskell. Το
είδος εκτέλεσης μπορεί να είναι batch ή interactive/partial. Στην πρώτη
περίπτωση τα προγράμματα που υποβάλλονται αποτελούν ανεξάρτητες λύσεις ενώ στην
δεύτερη ο κώδικάς αλληλεπιδρά με συγκεκριμένες βιβλιοθήκες ή εντάσσεται σε έναν
κοινό κορμό που έχει τεθεί για το συγκεκριμένο πρόβλημα. Ο τρόπος αξιολόγησης
μπορεί να είναι κανονικός ή ειδικός. Στον κανονικό ελέγχεται η ομοιότητα της
εξόδου του προγράμματος της υποβολής με την ορθή απάντηση, ενώ στον ειδική
αξιολόγηση γίνεται χρήση ειδικού προγράμματος αξιολόγησης για την βαθμολόγηση
της λύσης επιτρέποντας έτσι την ύπαρξη προβλημάτων βελτιστοποίησης.

\bigskip

Οι υποβολές που στέλνονται στον Kewii αποθηκεύονται σε μια ουρά σύμφωνα με τον
αύξοντα αριθμό που παίρνουν και ο Kewii γνωρίζει κάθε στιγμή ποιος θα είναι ο
επόμενος αριθμός υποβολής που θα αξιολογήσει. Το πρόγραμμα "κοιμάται" έως ότου
βρει μια νέα υποβολή ελέγχοντας για αρχεία με τον συγκεκριμένο αριθμό. Επίσης,
αν η διαδικασία της αξιολόγησης διακοπεί ενδιάμεσα, μπορεί να συνεχίσει από το
σημείο που σταμάτησε. Η ροή λειτουργίας του παρουσιάζεται στο σχήμα 3.1.

\begin{figure}
  \centering
  \includegraphics[scale=0.8,trim=4 4 4 4,clip]{Figures/graderflow.png}
  \caption[Ροή Kewii]{Το διάγραμμα ροής που ακολουθείται σε κάθε νέα υποβολή
  στον Kewii, όπως παρουσιάζεται στο \cite{Tsiamitros}.}
\end{figure}

\bigskip

Γενικά, η λειτουργία του Kewii περιορίζεται στο να δέχεται υποβολές για
προβλήματα με συγκεκριμένα αρχεία ελέγχου. Αξιολογεί κάθε υποβολή με 0 - λάθος
και 1 - σωστό για κάθε αρχείο ή αναθέτει την αξιολόγηση στο ειδικό πρόγραμμα
που θα επιστρέψει μια τιμή ανάμεσα στα 0 και 1. Τότε, η "ευθύνη" του τελειώνει,
δηλαδή δεν εμπλέκεται στη συνολική αξιολόγηση των διαγωνισμών και των
προβλημάτων, τον ορισμό υποβολών ως ενεργών, ή με το ποια αρχεία ελέγχου θα
επιλεγούν για κάθε υποβολή. Η αποστασιοποίηση του από τα παραπάνω, το γεγονός
δηλαδή ότι δρα ως ένα μαύρο κουτί για την εκτέλεση των υποβολών, είναι πολύ
σημαντικό διότι θα μας επιτρέψουν να επανασχεδιάσουμε τον αλγόριθμο της
υποβολής, δημιουργώντας ομάδες αρχείων ελέγχου, όπως και άλλα κομμάτια του
Grader χωρίς να χρειαστεί να τροποποιήσουμε τον Kewii.

\section{Διαδικτυακή εφαρμογή Grader}

Ο Grader είναι μια web εφαρμογή υλοποιημένη σε PHP και HTML/CSS/JS, η οποία
αποτελεί το frontend και μέρος του backend του συστήματος μας. Ως frontend
εφαρμογή αναλαμβάνει να παρουσιάσει σε διαγωνιζόμενους και διαχειριστές τις
σελίδες διαχείρισης, υποβολών και αποτελεσμάτων, ενώ ως backend αναλαμβάνει την
υλοποίηση της λογικής του συστήματος, των διάφορων αλγορίθμων και ροών και την
επικοινωνία με τη βάση δεδομένων και τον Kewii.

\bigskip

Τα συνήθη σενάρια χρήσης της εφαρμογής αναφέρονται παρακάτω.

\subsection{Εμφάνιση διαθέσιμων διαγωνισμών και προβλημάτων}

Τόσο οι διαγωνιζόμενοι, όσο και οι διαχειριστές έχουν τη δυνατότητα να βλέπουν
τους ενεργούς διαγωνισμούς και τα προβλήματα που περιέχονται σε αυτούς. Η
σελίδα κάθε διαγωνισμού ενημερώνει το χρήστη για τη διάρκεια του καθώς και για
το ποια προβλήματα περιέχει. Μεταβαίνοντας σε κάποιο πρόβλημα, ο χρήστης βλέπει
την ακριβή περιγραφή του και έχει τη δυνατότητα να υποβάλλει τη λύση του.

\subsection{Εμφάνιση υποβολών προβλήματος και πηγαίου κώδικα}

Κάθε χρήστης μπορεί μέσα από τη σελίδα του διαγωνισμού να περάσει στις υποβολές
για καθένα από τα προβλήματα του. Σε αυτή τη σελίδα υπάρχουν όλες οι υποβολές
που έχει κάνει για αυτό το πρόβλημα, ενώ υπάρχει χρωματική διάκριση ανάμεσα σε
σωστές και λανθασμένες υποβολές, καθώς και για την ενεργή υποβολή. Ως ενεργή
υποβολή τίθεται η τελευταία σωστή, αν και υπάρχει η δυνατότητα στην ίδια
σελίδα να επιλεχθεί μια διαφορετική σωστή υποβολή ως ενεργή. Επιλέγοντας μια
υποβολή, ο χρήστης μεταφέρεται στη σελίδα λεπτομερειών της υποβολής του, όπου
εμφανίζονται και τα ακριβή αποτελέσματα της λύσης του για κάθε αρχείο ελέγχου.
Για τα αρχεία ελέγχου που το επιτρέπουν, υπάρχει η σελίδα προεπισκόπησης.
Παρόμοια δυνατότητα δίνεται και για τον πηγαίο κώδικα της υποβολής, αν ο
χρήστης θέλει να τον δει στην εφαρμογή.

(% todo search for οθόν)
\subsection{Δημιουργία και διαχείριση προβλημάτων και διαγωνισμών}

Η δημιουργία και η διαχείριση διαγωνισμών γίνεται από τη σελίδα της διαχείρισης
που δεν είναι προσβάσιμη στους κανονικούς χρήστες. Σε αυτή τη σελίδα, ο
διαχειριστής μπορεί να δει όλους τους διαγωνισμούς και τα προβλήματα που έχουν
δημιουργηθεί. Οι διαγωνισμοί παρουσιάζονται ταξινομημένοι κατά χρονολογική
σειρά δημιουργίας μαζί με τα προβλήματα που περιέχονται στον καθένα. Δίνονται
επιλογές για επεξεργασία προβλημάτων και διαγωνισμών, καθώς και δημιουργία
νέων. Αφού δημιουργηθεί ένα πρόβλημα, αρχικά δεν ανήκει σε κάποιον διαγωνισμό
έως ότου επιλεχθεί κάποιος από το πλευρικό μενού μετακίνησης του προβλήματος.
Διπλά σε κάθε πρόβλημα υπάρχουν, επιπλέον, στοιχεία για τα αρχεία ελέγχου που
διαθέτει και τις συνολικές λύσεις που έχουν υποβληθεί.

\bigskip

Εξαιτίας της άμεσης σύνδεσης προβλημάτων και υποβολών, τα προβλήματα διατηρούν
τις υποβολές που έχουν γίνει σε αυτά κατά τους σε νέους διαγωνισμούς.
Επιπροσθέτως, όπως είναι προφανές, ο διαγωνισμός στον οποίο άνηκε αρχικά το
πρόβλημα φαίνεται κενός και ουσιαστικά χάνει και την ιστορικότητα του. Ο
συγκεκριμένος τρόπος λειτουργίας αποτελεί απόρροια της αρχικής σχεδίασης του
Grader για διοργανώσεις και όχι για ακαδημαϊκούς σκοπούς, με αποτέλεσμα να μην
έχει προβλεφθεί η δημιουργία διαγωνισμών-σειρών ασκήσεων με επαναχρησιμοποίηση
προβλημάτων.

\bigskip

Μια ακόμα σελίδα που είναι προσβάσιμη από την κεντρική της διαχείρισης προβλημάτων
και διαγωνισμών είναι αυτή των αρχείων ελέγχου του προβλήματος. Σε αυτήν μπορεί
ο διαχειριστής να ανεβάσει καινούρια αρχεία ελέγχου, καθώς και να αλλάξει τον τύπο
εκτέλεσης και την βαθμολογία τους. Η συγκεκριμένη σελίδα θα μας απασχολήσει αρκετά
στα επόμενα κεφάλαια, δεδομένου ότι θα τροποποιηθεί τόσο για τις ομάδες αρχείων
ελέγχου όσο και για την προσθήκη μαζικής δημιουργίας αρχείων και ομάδων.

\subsection{Ενεργοποίηση διαγωνισμού και τελική αξιολόγηση}

Ένα πολύ συνηθισμένο σενάριο χρήσης για έναν διαχειριστή είναι αυτό κατά το
οποίο, αφού έχει δημιουργήσει ένα νέο διαγωνισμό και τα προβλήματα του, πρέπει
να το δημοσιοποιήσει στους χρήστες. Μέσα από τη σελίδα διαχείρισης των
διαγωνισμών, έχει τη δυνατότητα αρχικά να επιλέξει τους χρήστες που επιτρέπεται
να συμμετέχουν στο διαγωνισμό. Έπειτα, έχοντας επιλέξει την επιθυμητή
ημερομηνία έναρξης και λήξης του διαγωνισμού κατά τη δημιουργία του, μπορεί να
επιλέξει την ενεργοποίηση αυτού με το αντίστοιχο πλήκτρο στη σελίδα
διαχείρισης. Τότε ο διαγωνισμός και τα προβλήματα του γίνονται ορατά στους
επιλεγμένους χρήστες και οι τελευταίοι μπορούν να ξεκινήσουν να κάνουν
υποβολές.

\bigskip

Όταν λήξει ή απενεργοποιηθεί ο διαγωνισμός, ο διαχειριστής μπορεί να εκκινήσει
την τελική αξιολόγηση, κατά την οποία επιλέγονται όλες οι ενεργές υποβολές για
κάθε πρόβλημα του διαγωνισμού και αυτές αποστέλλονται στον Kewii για να
αξιολογηθούν εκ νέου συμπεριλαμβάνοντας αυτή τη φορά τα αρχεία ελέγχου που
είναι αποκλειστικά για την τελική αξιολόγηση (πράσινα). Μόλις ολοκληρωθεί η
διαδικασία, εμφανίζονται στη σελίδα τα τελικά αποτελέσματα, τα οποία μπορούν να
δημοσιοποιηθούν σαν δημοσιεύσεις στην αρχική σελίδα του Grader. Η βαθμολογία
υπολογίζεται από το άθροισμα των ενεργών υποβολών του κάθε διαγωνιζόμενου στα
προβλήματα που περιέχει ο διαγωνισμός. Η βαθμολογία του προβλήματος είναι το
άθροισμα των πόντων των αρχείων ελέγχου της τελικής αξιολόγησης.


\chapter{Προσθήκη Ομάδων Αρχείων Ελέγχου}

Η μεγαλύτερη σε πολυπλοκότητα αλλαγή λειτουργικότητας του Grader ήταν η
τροποποίηση του τρόπου αξιολόγησης των υποβολών με την εισαγωγή ομάδων αρχείων
ελέγχου (testcase groups) για ομαδοποίηση των τελευταίων, καθώς και η
δημιουργία ενός νέου τύπου εκτέλεσης των αρχείων. Η υλοποίηση του νέου τύπου
εκτέλεσης, που θα αντιστοιχεί στο μπλε χρώμα (blue tag
\includegraphics[scale=0.8]{Figures/tag_blue.png}) κατά την αντιστοίχιση που
παρουσιάστηκε στον πίνακα 3.1, ήταν μια χρήσιμη εισαγωγή στη λειτουργία και
στον κώδικα του Grader αλλά και τη βάση δεδομένων. Στο παρόν κεφάλαιο θα
περιγραφεί πρώτα η μικρή αυτή προσθήκη και έπειτα η λογική και η υλοποίηση της
προσθήκης των testcase groups.

\section{Προσθήκη blue tag για μη απαραίτητα αρχεία ελέγχου}

\subsection{Κίνητρο}

Ένα αρχείο ελέγχου χαρακτηρισμένο με blue tag ελέγχεται κανονικά σε κάθε
αξιολόγηση αλλά το αποτέλεσμα της εκτέλεσης του δεν επηρεάζει την ορθότητα της
υποβολής. Όπως τα "κίτρινα" αρχεία ελέγχου, τα "μπλε" διατηρούν κρυφή την είσοδο
τους από τους διαγωνιζόμενους. Ο συγκεκριμένος τύπος εκτέλεσης είχε
υλοποιηθεί πρώτα (πριν την παρούσα εργασία), στο branch του Grader που
χρησιμοποιεί το hellenico.gr, το οποίο όμως διαφέρει αρκετά από αυτό του softlab,
γεγονός που δεν επέτρεπε το απλό merge του σχετικού κώδικά.


\bigskip

Η ύπαρξη αρχείων ελέγχου που εξετάζονται στις κανονικές υποβολές αλλά δε
κρίνουν την έκβαση τους προσφέρει το κύριο πλεονέκτημα ότι επιτρέπει την
εισαγωγή δυσκολότερων αρχείων ελέγχου εκτός τελικής αξιολόγησης. Ας θυμηθούμε
τη λειτουργία του Grader όσον αφορά στις αρχικές υποβολές και την τελική
αξιολόγηση: Κατά τη διεξαγωγή του διαγωνισμού, κάθε πρόβλημα είναι ανοιχτό σε
υποβολές. Μια υποβολή θεωρείται ορθή μόνο αν όλα τα αρχεία ελέγχου που έτρεξαν
είναι σωστά. Για να πάρει βαθμολογία για το πρόβλημα, ο διαγωνιζόμενος πρέπει
να έχει τουλάχιστον μια ορθή υποβολή σε αυτό (την ενεργή).

\bigskip

Αυτό δημιουργεί το πρόβλημα ότι αρχεία ελέγχου με μη εμφανείς δυσκολίες του
αλγόριθμου (corner cases) ή αρχεία με μεγάλο μέγεθος εισόδου, αποτελούν
ρίσκο όσον αφορά τον χαρακτηρισμό τους ως "κίτρινα" ή "πορτοκαλί", δηλαδή
αρχεία ελέγχου που τρέχουν σε κανονικές και τελικές υποβολές.  Όσοι
διαγωνιζόμενοι δεν καταφέρουν να υποβάλουν λύση που να αξιολογηθεί σωστά σε όλα
τα αρχεία ελέγχου δεν καταφέρνουν να βαθμολογηθούν καθόλου, πιθανόν άδικα. Ως
φυσικό επακόλουθο, τέτοιου τύπου αρχεία ελέγχου μπορούν να χαρακτηριστούν μόνο
ως πράσινα, δηλαδή να χρησιμοποιούνται αποκλειστικά στην τελική αξιολόγηση.

\bigskip

Τα μπλε αρχεία ελέγχου προσφέρουν μια λύση στο πρόβλημα, καθώς επιτρέπουν
ουσιαστικά μια υποβολή να χαρακτηριστεί ορθή/ενεργή χωρίς να έχει "περάσει" όλα
τα αρχεία ελέγχου. Ακόμα κι αν ο διαγωνιζόμενος δεν καταφέρει να βελτιώσει την
υλοποίηση του έτσι ώστε να ικανοποιεί όλα τα αρχεία ελέγχου, θα διαθέτει μια
ενεργή υποβολή και συνεπώς θα βαθμολογηθεί. Παράλληλα, θα γνωρίζει ότι έχει
αποτύχει σε τουλάχιστον μία περίπτωση και θα έχει κίνητρο να συνεχίσει τις
υποβολές ώστε να μη χάσει τη δυνατότητα να πάρει πλήρη βαθμολογία.

\subsection{Υλοποίηση}

Η υλοποίηση δεν είχε ιδιαίτερες δυσκολίες αλλά απαιτούσε την κατανόηση της
αρχιτεκτονικής του Grader και του Kewii. Αλλαγές απαιτούνταν τόσο στο frontend
κομμάτι του Grader, όσο και στον κώδικα κατά την υποβολή και κατά το callback,
που τρέχει μόλις ολοκληρωθεί η αξιολόγηση μιας υποβολής. Ο Kewii δε χρειάστηκε
τροποποιήσεις, διότι όπως έχει περιγραφεί σε προηγούμενο κεφάλαιο, σε κάθε
υποβολή λαμβάνει απλά τη λίστα με τα αρχεία ελέγχου που πρέπει να
χρησιμοποιήσει και επιστρέφει την έκβαση τους. Η βάση δεδομένων επίσης δεν
υποβλήθηκε σε αλλαγές, καθώς η μόνη αλλαγή που την επηρεάζει είναι η προσθήκη
μιας πιθανής τιμής στο πεδίο του τύπου εκτέλεσης του πίνακα των αρχείων
ελέγχου.

\bigskip

Οι αλλαγές που αφορούν στο frontend κομμάτι έγιναν κυρίως στη σελίδα της
διαχείρισης αρχείων ελέγχων. Όπως φαίνεται στο σχήμα 4.1, δίπλα σε κάθε
αρχείο ελέγχου είναι τα χρωματικά tags και χάρη στη CSS διακρίνεται το
επιλεγμένο. Για την προσθήκη του blue tag, χρησιμοποιήθηκε η εικόνα από το
hellenico, και αυτή προστέθηκε μετά το κίτρινο tag. Αντίστοιχα, προστέθηκε η
περιγραφή του συγκεκριμένου tag και τροποποιήθηκε ο κώδικας που διαχειρίζεται
το πάτημα του tag και τροποποιεί τη βάση.

\bigskip

Στον κώδικα που τρέχει κατά την υποβολή, επιλέγονται τα αρχεία ελέγχου που θα
εκτελεστούν και γράφονται σε ένα αρχείο στον εξυπηρετητή ώστε να μπουν στην
ουρά του Kewii. Εκεί προστέθηκε ο νέος τύπος εκτέλεσης σε αυτούς που στέλνονται
σε όλες τις υποβολές. Αντίστοιχα, στο callback script, το κομμάτι του Grader
που τρέχει μόλις έχει ολοκληρωθεί η βασική αξιολόγηση μιας υποβολής από τον
Kewii, υλοποιήθηκε η λογική των "μπλε" αρχείων ελέγχου, που ακόμα και να έχουν
χαρακτηριστεί ως λανθασμένα, δεν επηρεάζουν την έκβαση.

\begin{figure}
  \centering
  \includegraphics[scale=0.5,trim=4 4 4 4,clip]{Figures/bluetag.png}
  \caption[Προσθήκη blue tag]{Η σελίδα διαχείρισης αρχείων ελέγχου μετά την
  προσθήκη του blue tag.}
\end{figure}

\section{Ομάδες αρχείων ελέγχου (testcase groups)}

Έχοντας προσθέσει το blue tag, τροποποιώντας πολλαπλά σημεία του Grader τόσο
για την υποβολή όσο και για την αξιολόγηση, μπορούσαμε να προχωρήσουμε στην
υλοποίηση της αρκετά πιο σύνθετης δυνατότητας, των testcase groups.

\subsection{Κίνητρο}

Πριν τις αλλαγές μας ο διαχειριστής, κατά την δημιουργία του προβλήματος,
έπρεπε να δημιουργήσει αρχεία ελέγχου και να επιλέξει στο καθένα βαθμολογία και
τύπο εκτέλεσης. Τα αρχεία ελέγχου δεν είχαν δυνατότητα για οποιαδήποτε
κατηγοριοποίηση ή διαχωρισμό. Ο διαχειριστής, σε κάθε σημείο, όφειλε να
διατηρεί την ισορροπία όσον αφορά στις βαθμολογίες των αρχείων ελέγχου και να
θυμάται την αναλογία εύκολων και δύσκολων αρχείων.

\bigskip

Άλλο ένα πρόβλημα που υπήρχε ήταν η δυνατότητα για δημιουργία ειδικών λύσεων σε
συγκεκριμένα προβλήματα έτσι ώστε να λαμβάνουν αξιοπρεπή βαθμολογία έχοντας
υλοποιήσει περιορισμένο μέρος του αλγόριθμου που να αρκεί για την ορθότητα της
υποβολής. Κάθε αρχείο ελέγχου που αξιολογείται ως σωστό αθροίζεται στην
βαθμολογία της τελικής αξιολόγησης και μια τέτοια υποβολή μπορεί να επιτύχει
καλύτερη βαθμολογία από ότι θα έπρεπε.

\bigskip

Η προσθήκη testcase groups θα επιτρέψει την ομαδοποίηση των αρχείων ελέγχου σε
groups ανεξάρτητα στην αξιολόγηση, με δική τους βαθμολογία και με την ορθότητα
τους να κρίνεται στην ορθότητα όλων των επιμέρους αρχείων ελέγχου. Έτσι, θα
δοθεί μεγάλη ευελιξία στη δημιουργία διαφορετικών κατηγοριών αρχείων. Ένας
χρήσιμος διαχωρισμός θα μπορεί να είναι ανάλογα με το μέγεθος της εισόδου,
δηλαδή σε μικρά, μεσαία και μεγάλα. Με αυτό τον τρόπο ο διαχειριστής γλιτώνει
πολύ κόπο πετυχαίνοντας την επιθυμητή αναλογία βαθμολογίας στις διάφορες λύσεις
βάζοντας απλά τους βαθμούς που επιθυμεί στο group, ανεξάρτητα με το πόσα αρχεία
ελέγχου ανήκουν σε κάθε group.

\bigskip

Επιπροσθέτως, λύνεται το πρόβλημα των προσαρμοσμένων λύσεων, αφού αν τα
υπάρχοντα groups αποτελούνται από αρχεία πολλαπλών περιπτώσεων, οι λύσεις αυτού
του τύπου δε θα καταφέρνουν να ικανοποιήσουν ταυτόχρονα τα αρχεία και δε θα
βαθμολογούνται σε αυτά τα groups.

\subsection{Προδιαγραφές}

Για την καθοδήγηση της υλοποίησης τέθηκαν συγκεκριμένες προδιαγραφές όσον
αφορά στις ομάδες αρχείων ελέγχου και τη λειτουργία τους.

\begin{itemize}

    \item Οι ομάδες αρχείων ελέγχου, όπως περιγράφηκαν και παραπάνω, θα μπορούν
      να περιέχουν οποιοδήποτε υποσύνολο των διαθέσιμων αρχείων. Επιθυμούμε,
      για μεγαλύτερη ευελιξία, τα αρχεία ελέγχου να μπορούν να ανήκουν σε
      πολλαπλές ομάδες, με επιλογή για διαφορετικό τύπο εκτέλεσης σε κάθε ομάδα.

    \item Η αξιολόγηση θα γίνεται με βάση μόνο τις ομάδες, ανεξάρτητα με το
      πόσα αρχεία ελέγχου υπάρχουν. Μια υποβολή θα θεωρείται ορθή και θα μπορεί
      να τεθεί ως ενεργή αν ικανοποιεί τουλάχιστον μια ομάδα.

    \item Οι ομάδες θα μπορούν να αποκτήσουν τίτλο από το διαχειριστή και θα
      διαθέτουν πόντους. Τα παραπάνω καθιστούν πόντους και τύπους
      εκτέλεσης των αρχείων ελέγχου ανούσιους.

    \item Οι ομάδες που περιέχουν τουλάχιστον ένα αρχείο ελέγχου με τύπο εκτέλεσης
      μη τελικής αξιολόγησης, δηλαδή κίτρινο, πορτοκαλί ή μπλε, θα αξιολογούνται
      κατά τις κανονικές υποβολές και θα είναι εμφανείς στους διαγωνιζόμενους
      μαζί με τα αρχεία ελέγχου που αξιολογήθηκαν.

\end{itemize}

\subsection{Υλοποίηση}

Με βάση τις προδιαγραφές που περιγράφηκαν παραπάνω διαμορφώνεται η εικόνα της
υλοποίησης και των κρίσιμων μερών της.

\bigskip

Αρχικά, όσον αφορά στη βάση δεδομένων, θα χρειαστεί ένας νέος πίνακας για τα
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.6,trim=4 4 4 4,clip]{Figures/groupsbefore.png}
  \caption[Βάση πριν τα testcase groups]{Οι πίνακες και οι σχέσεις της βάσης πριν
  τις αλλαγές μας.}
\end{figure}

\begin{figure}
  \centering
  \includegraphics[scale=0.6,trim=4 4 4 4,clip]{Figures/groupsafter.png}
  \caption[Βάση μετά τα testcase groups]{Δημιουργήθηκε ο νέος πίνακας GroupDetails,
  που είναι απαραίτητος για την αντιστοίχιση testcase groups με αρχεία ελέγχου.
  Επίσης, προστέθηκε το πεδίο resultsjson για την αποθήκευση των υπολογισμένων
  αποτελεσμάτων της υποβολής.}
\end{figure}

\bigskip

Από τη στιγμή που υπάρχει η πιθανότητα δύο groups να έχουν κοινά αρχεία ελέγχου
, δημιουργείται το θέμα της πιθανής αχρείαστης αξιολόγησης των ίδιων αρχείων
ελέγχου πολλές φορές. Στην υλοποίηση μας αυτό θα αποφευχθεί διατηρώντας την
αρχιτεκτονική της εφαρμογής όσον αφορά στις αρμοδιότητες Kewii και Grader
απαράλλαχτη. Αυτό σημαίνει ότι ο Kewii θα συνεχίσει να παίρνει απλά μια λίστα
με τα αρχεία ελέγχου που πρέπει να εκτελέσει και θα επιστρέφει το αποτέλεσμα
τους. Πρακτικά, δε θα "αντιληφθεί" την αλλαγή, καθώς ο Grader θα παραμείνει
υπεύθυνος, κατά την υποβολή μιας λύσης, να φιλτράρει τα μοναδικά αρχεία ελέγχου
που του χρειάζονται και κατά το callback να συνθέτει τα αποτελέσματα που θα
λάβει κατάλληλα ώστε να αποφανθεί για την ορθότητα κάθε group.

\bigskip

Για τη διαχείριση και τη δημιουργία των testcase groups κρίθηκε αναγκαίο να
δημιουργηθεί μια νέα σελίδα, η οποία εισάχθηκε στην ήδη υπάρχουσα διαχείριση
αρχείων ελέγχου. Η τελευταία χρειάστηκε σημαντικές τροποποιήσεις, καθώς πλέον
τα αρχεία ελέγχου δεν μπορούν να έχουν βαθμολογίες και τύπους εκτέλεσης (tags)
έξω των ομάδων που ανήκουν. Τα χρωματικά tags παρέμειναν, δίνοντας τη
δυνατότητα στο διαχειριστή να αλλάξει μαζικά τον τύπο ενός αρχείου ελέγχου σε
όλες τις ομάδες που ανήκει. Κρίθηκε σημαντικό η πληροφορία για τις ομάδες, τις
βαθμολογίες τους και το ποια αρχεία εμπεριέχει η κάθε μια, να εμφανίζεται στη
συγκεκριμένη σελίδα χωρίς να είναι απαραίτητη η μετάβαση στη σελίδα της
διαχείρισης ομάδας αρχείων ελέγχου. Οι δύο προαναφερθείσες σελίδες εμφανίζονται
στα σχήματα 4.4 και 4.5.

\bigskip

\begin{figure}
  \centering
  \includegraphics[scale=0.5,trim=4 4 4 4,clip]{Figures/groupoverview.png}
  \caption[Επισκόπηση ομάδων αρχείων ελέγχου]{Η σελίδα διαχείρισης των αρχείων
  ελέγχου μετά την προσθήκη των testcase groups. Διακρίνεται η επισκόπηση τους,
  μαζί με τα αρχεία ελέγχου που περιέχουν και τους βαθμούς τους.}
\end{figure}

\begin{figure}
  \centering
  \includegraphics[scale=0.5,trim=4 4 4 4,clip]{Figures/groupedit.png}
  \caption[Διαχείριση ομάδας αρχείων ελέγχου]{Εδώ φαίνεται η νέα σελίδα που
  δημιουργήθηκε για την δημιουργία και τροποποίηση μιας ομάδας αρχείων ελέγχου.}
\end{figure}

\bigskip

Η εισαγωγή των testcase groups στο Grader επηρέασε, ακόμα, μεγάλο πλήθος σελίδων
και λειτουργιών συμπεριλαμβανομένων των παρακάτω:

\begin{itemize}
    \item Αλλαγές στη σελίδα των λεπτομερειών υποβολής. Στη συγκεκριμένη
      σελίδα πλέον εμφανίζονται ομάδες αντί για αρχεία, οι οποίες περιέχουν
      τα αρχεία που αντιστοιχούν σε αυτές μέσα σε πλαίσια. Οι χρωματικές ενδείξεις
      επιτυχίας (πράσινο φόντο) και αποτυχίας (κόκκινο) έχουν παραμείνει. Το φόντο
      του τίτλου του group χρωματίζεται και αυτό ανάλογα με την ορθότητα του.

    \item Αλλαγές στη σελίδα παρουσίασης όλων των υποβολών και επιλογής της
      ενεργής.  Εδώ έπρεπε να προστεθεί μία ένδειξη ορθότητας κάθε υποβολής σε
      σχέση με το πόσα σωστά groups έχει. Πρόκειται απλά για ένα κλάσμα των
      σωστών groups προς όλα όσα ελέγχθηκε. Μια ορθή υποβολή θα είναι πράσινη
      αλλά μπορεί π.χ. να έχει περάσει μόνο το ένα από τα τρία testcase groups,
      κάτι που δεν είναι εμφανές μέχρι να μεταβεί ο διαγωνιζόμενος στις
      λεπτομέρειες υποβολής. Σε αυτή την περίπτωση θα αναγράφεται 1/3.

    \item Στη σελίδα διαχείρισης προβλημάτων και διαγωνισμών άλλαξαν τα στατιστικά
      δίπλα σε κάθε πρόβλημα που έως τώρα παρουσίαζαν την αναλογία αρχείων ελέγχου
      ανά τύπο εκτέλεσης. Πλέον, εμφανίζονται μόνο δύο αριθμοί, ο συνολικός αριθμός
      αρχείων ελέγχου και ομάδων.

\end{itemize}

\begin{figure}
  \centering
  \includegraphics[scale=0.5,trim=4 4 4 4,clip]{Figures/allsubmissions.png}
  \caption[Νέα σελίδα εμφάνισης υποβολών]{Η τροποποιημένη παρουσίαση όλων των
  υποβολών ενός διαγωνιζόμενου, όπου διακρίνεται ο βαθμός επιτυχίας της υποβολής
  ως προς τα testcase groups που είχε σωστά.}
\end{figure}

\begin{figure}
  \centering
  \includegraphics[scale=0.5,trim=4 4 4 4,clip]{Figures/cursubmission.png}
  \caption[Νέα σελίδα λεπτομέρειων υποβολής]{Η σελίδα τροποποιήθηκε σύμφωνα με τον
  νέο τρόπο αξιολόγησης, παρουσιάζοντας για κάθε group την αξιολόγηση της υποβολής
  για κάθε αρχείο ελέγχου που περιέχει.}
\end{figure}

\bigskip

Άλλη μια σημαντική πτυχή της υλοποίησης αποτελεί ο τρόπος που θα γίνει η
μετάβαση από τον προηγούμενο τρόπο αξιολόγησης στο νέο. Εκτός από τις πολλαπλές
τροποποιήσεις στον κώδικα και στη βάση, επιβάλλεται να τροποποιηθούν όλα τα
προβλήματα, παλιά και τρέχοντα. Ο λόγος είναι ότι στο νέο σύστημα η αξιολόγηση όλων
των υποβολών βασίζεται στα testcase groups αντί για τα μεμονωμένα αρχεία ελέγχου.
Ως αποτέλεσμα, κάθε υπάρχων πρόβλημα θα πρέπει να αποκτήσει groups τα οποία,
ιδανικά, θα είναι ισοδύναμα με τα υπάρχοντα αρχεία ελέγχου.

\bigskip

Ο τρόπος να επιτευχθεί η ισοδυναμία προηγούμενης και νέας κατάστασης είναι η
δημιουργία ενός group που να περιέχει μόνο τα αρχεία ελέγχου κανονικών
υποβολών, δηλαδή μπλε, κίτρινα και πορτοκαλί, με βαθμολογία 0. Αυτό το group,
πετυχαίνει ουσιαστικά, την προσομοίωση της προηγούμενης κατάστασης όπου οι
υποβολές ελέγχονταν στα συγκεκριμένα αρχεία ελέγχου και εφόσον τα περνούσαν
όλα, η λύση ήταν σωστή και γινόταν ενεργή. Αυτό το group όμως δεν αρκεί, καθώς
χρειάζονται και άλλα για την τελική αξιολόγηση. Αντίστοιχα, θα πρέπει να
δημιουργηθούν ακόμα ίσος αριθμός groups με τα ενεργά αρχεία ελέγχου (όλα εκτός
των μωβ), και πιο συγκεκριμένα, κάθε group θα περιέχει ένα αρχείο ελέγχου με
χρώμα πράσινο και η βαθμολογία της θα είναι ίση με τη βαθμολογία του αρχείου
ελέγχου. Έτσι, πετυχαίνουμε την προσομοίωση και της τελικής αξιολόγησης, καθώς
όλα αυτά τα groups δε θα ελέγχονται στην κανονική υποβολή διότι περιέχουν μόνο
πράσινα αρχεία ελέγχου (από ένα κάθε group). Για την αυτοματοποίηση της
διαδικασίας μετατροπής που περιγράφηκε υλοποιήθηκε script, το οποίο εισάχθηκε
στη σελίδα διαχείρισης αρχείων ελέγχου του προβλήματος.

\bigskip

Η υλοποίηση όσον αφορά στο frontend και τη λογική του Grader, συνδυάστηκε με
μερικό refactoring των κλάσεων και των συναρτήσεων, χρησιμοποιώντας πολλές από
τις αρχές που περιγράφονται στο Clean Code του Robert Martin
\cite{martin2009clean}. Μέρος των αλλαγών ήταν και η προσθήκη ενός πεδίου στον
πίνακα των υποβολών, με τίτλο resultsjson (σχήμα 4.3), το οποίο περιέχει τα
αναλυτικά αποτελέσματα μιας υποβολής, κωδικοποιημένα σε μορφή JSON, έτσι ώστε
να μην υπολογίζονται κάθε φορά που απαιτούνται. Επιπλέον, αλλαγές έγιναν ώστε
να αφαιρεθούν κομμάτια επαναλαμβανόμενου κώδικα με την αντίστοιχη δημιουργία
νέων δομών και κλάσεων, αποσύνδεση της λογικής διαφορετικών αντικειμένων και
μείωση της πολυπλοκότητας μεγάλων κομματιών κώδικα με δημιουργία μικρότερων
συναρτήσεων με περιγραφικά ονόματα.


\chapter{Σχεδίαση για διαχωρισμό Προβλημάτων - Διαγωνισμών}

Στο παρόν κεφάλαιο θα περιγραφούν οι αλλαγές που έγιναν στο Grader για την
τροποποίηση της λογικής του με σκοπό τη βελτίωση της ευκολίας χρήσης του
στο πλαίσιο μαθημάτων προγραμματισμού και σειρών ασκήσεων. Αυτό απαιτεί την
μερική αποσύνδεση των προβλημάτων από τους διαγωνισμούς ώστε αυτά να μπορούν
να επαναχρησιμοποιηθούν. Θα αναλύσουμε πρώτα το κίνητρο για την αλλαγή αυτή
και έπειτα τις λεπτομέρειες της υλοποίησης.

\section{Κίνητρο}

Ο πρωταρχικός στόχος που δημιουργήθηκε ο Grader ήταν η χρήση του για διαγωνισμούς
πληροφορικής. Κάθε διαγωνισμός θα αποτελούσε ξεχωριστό, μεμονωμένο γεγονός με
προβλήματα που θα είχαν δημιουργηθεί για το συγκεκριμένο διαγωνισμό και υποβολές
που αντιστοιχούν αποκλειστικά στο πρόβλημα.

\bigskip

Τα προβλήματα, έπειτα από τη δημιουργία τους, παραμένουν ανένταχτα, στην
κατηγορία "Προβλήματα εκτός διαγωνισμών" της σελίδας διαχείρισης όπως φαίνεται
και στο σχήμα 5.1. Το επόμενο βήμα είναι η μετακίνηση τους σε κάποιον
διαγωνισμό με χρήση του μενού στα δεξιά του προβλήματος. Η μετακίνηση αυτού του
τύπου είναι ο μόνος τρόπος να επαναχρησιμοποιηθεί το πρόβλημα και σε άλλους
διαγωνισμούς, αφότου τελειώσει αυτός για τον οποίο δημιουργήθηκε (ουσιαστικά, ο
πρώτος στον οποίο μετακινήθηκε). Το θέμα που δημιουργείται σε αυτό το σημείο
είναι ότι κατά τη μετακίνηση του, το πρόβλημα διατηρεί όλες τις προηγούμενες
υποβολές του, οι οποίες πρακτικά αγνοούνται στο νέο διαγωνισμό, ενώ ο
προηγούμενος διαγωνισμός χάνει το πρόβλημα που είχε. Όλα τα παραπάνω οφείλονται
στον τρόπο που είναι σχεδιασμένη η βάση, ο οποίος παρουσιάζεται στο σχήμα 5.2.

\begin{figure}
  \centering
  \includegraphics[scale=0.5,trim=4 4 4 4,clip]{Figures/beforesep.png}
  \caption[Προβλήματα εκτός διαγωνισμών]{Το κάτω μέρος της διαχείρισης
  διαγωνισμών περιέχει τα προβλήματα που δεν έχουν ενταχτεί σε κάποιο
  διαγωνισμό. Με το πράσινο κουμπί στα δεξιά μπορούν να μεταφερθούν σε
  διαγωνισμό. Με τον ίδιο τρόπο μπορούν όλα τα προβλήματα να μεταφερθούν σε
  καινούριους διαγωνισμούς ώστε να επαναχρησιμοποιηθούν.}
\end{figure}

\bigskip

\begin{figure}
  \centering
  \includegraphics[scale=0.5,trim=4 4 4 4,clip]{Figures/sepbefore.png}
  \caption[Βάση πριν το διαχωρισμό]{Οι πίνακες και οι σχέσεις τους πριν την
  αλλαγή μας. Παρατηρούμε, ότι οι υποβολές δεν έχουν σύνδεση με το διαγωνισμό,
  ενώ τα προβλήματα μπορούν να ανήκουν μόνο σε ένα διαγωνισμό.}
\end{figure}

\bigskip

Στο σχήμα 5.2 αρχίζει να διακρίνεται το πρόβλημα που δημιουργείται. Η σύνδεση
κάθε προβλήματος με το διαγωνισμό γίνεται μέσω του πεδίο competitionID στον πίνακα
των προβλημάτων. Ως αποτέλεσμα, το μόνο που κάνει η λειτουργία της μετακίνησης
προβλήματος σε άλλον διαγωνισμό είναι να αλλάξει αυτό το πεδίο. Επιπροσθέτως,
όπως βλέπουμε, οι υποβολές συνδέονται άμεσα μόνο με τα προβλήματα και αυτός
είναι ο λόγος που μεταφέρονται μαζί με αυτά κατά τη μετακίνηση τους.

\bigskip

Τέλος, είναι αξιοσημείωτος ο τρόπος που στον πίνακα finalresults, στον οποίο
καταχωρούνται τα αποτελέσματα μετά την τελική αξιολόγηση, αποθηκεύονται τα
επιμέρους σκορ των προβλημάτων του. Αυτό γίνεται στο πεδίο scoreDetails, όπου
εισάγονται οι βαθμολογίες των προβλημάτων του διαγωνισμού χωρισμένες απλά με
κόμμα, σύμφωνα με μια αύξουσα ταξινόμηση των id των προβλημάτων που περιείχε ο
διαγωνισμός κατά την τελική αξιολόγηση.

\bigskip

Παραδείγματος χάρη, αν ο διαγωνισμός 15 περιέχει τα προβλήματα 48 και 51 και ένας
διαγωνιζόμενος έχει λάβει 7 βαθμούς στο πρώτο και 9 στο δεύτερο, το πεδίο score θα
έχει την τιμή 16 και το πεδίο scoreDetails θα έχει την τιμή 7,9. Όπως γίνεται
αντιληπτό, όταν αλλάξει η σύνθεση ενός διαγωνισμού, χάνεται η ιστορικότητα των
αποτελεσμάτων αφού δεν είναι δυνατό να ανακτηθεί από τη βάση η σύνδεση των
βαθμολογιών με τα προβλήματα του διαγωνισμού.

\bigskip

\section{Υλοποίηση}

Η κύρια λειτουργική αλλαγή/δυνατότητα που θα προστεθεί είναι αυτή της προσθήκης
των προβλημάτων σε νέους διαγωνισμούς χωρίς να επηρεάζονται οι προηγούμενοι, με
αντιγραφή δηλαδή των προβλημάτων. Το κυριότερο μέρος της υλοποίησης έχει να κάνει
με την αλλαγή των πινάκων της βάσης και των σχέσεων μεταξύ τους.

\bigskip

Αρχικά, θα πρέπει να δημιουργηθεί ένας πίνακας που να συνδέει κάθε διαγωνισμό
με τα προβλήματα που διαθέτει. Το πεδίο στον πίνακα των προβλημάτων που έως
τώρα χρησίμευε για αυτή τη σύνδεση δεν αρκεί αφού θέλουμε πλέον να υπάρχει
σχέση "πολλά προς ένα¨ για προβλήματα και διαγωνισμούς. Ο νέος πίνακας
χρειάζεται απλά να περιέχει τα πεδία competitionID και probID.

\bigskip

Όπως αναφέρθηκε και παραπάνω, οι υποβολές θα πρέπει να συνδέονται με το
διαγωνισμό και όχι με το πρόβλημα. Αυτό θα επιτευχθεί με την προσθήκη του
πεδίου competitionID στον πίνακα των υποβολών. Με αυτό τον τρόπο είναι εύκολο να
γίνει ο διαχωρισμός των υποβολών ανά διαγωνισμό και πρόβλημα ώστε κάθε πρόβλημα
να μπορεί να έχει ξεχωριστά δεδομένα υποβολών και αποτελεσμάτων σε κάθε
διαγωνισμό που ανήκει.

\bigskip

Άλλη μια αλλαγή που κρίθηκε σημαντική είναι η προσθήκη ενός πεδίου JSON στον
πίνακα των αποτελεσμάτων σε αντικατάσταση του scoreDetails. Το scoreDetailsjson
θα έχει την ίδια λογική, δηλαδή θα αναγράφει τις επιμέρους βαθμολογίες σε κάθε
πρόβλημα του διαγωνισμού. Η διαφορά θα είναι ότι δε θα σημειώνεται στη βάση μόνο
η βαθμολογία αλλά ζευγάρια probID: βαθμολογία. Στο παράδειγμα που χρησιμοποιήθηκε
προηγουμένως, το πεδίο θα έχει τη μορφή $\{48: 7, 51: 9\}$.

\bigskip

Χάρη στην προσθήκη του πεδίου scoreDetailsjson, ένας διαχειριστής θα μπορεί να δει
με λεπτομέρεια τα αποτελέσματα ενός διαγωνισμού για κάθε διαγωνιζόμενο ακόμα και
αν έχει αλλάξει η δομή του, κάτι που πριν ήταν αδύνατο. Βεβαίως, από τη στιγμή που
θα εισαχθεί η δυνατότητα αντιγραφής αντί μετακίνησης των προβλημάτων δε θα τίθεται
συχνά θέμα αλλαγής της δομής ενός διαγωνισμού μετά τον υπολογισμό αποτελεσμάτων και
την ολοκλήρωση του.

\bigskip

Έπειτα από τις αλλαγές που περιγράφηκαν, η νέα μορφή της βάσης φαίνεται στο
σχήμα 5.3. Ο πίνακας CompProblems είναι η νέα προσθήκη που είναι αναγκαία για
τη σύνδεση προβλημάτων με διαγωνισμός διατηρώντας μια κανονικοποιημένη βάση για
αποφυγή του πλεονασμού δεδομένων. Νέα πεδία προστέθηκαν επίσης και στους
πίνακες Submissions και FinalResults.

\bigskip

\begin{figure}
  \centering
  \includegraphics[scale=0.5,trim=4 4 4 4,clip]{Figures/sepafter.png}
  \caption[Βάση μετά το διαχωρισμό]{Δημιουργήθηκε ο πίνακας CompProblems που
  μας επιτρέπει τη σύνδεση προβλημάτων με πολλούς διαγωνισμούς ταυτόχρονα.
  Παράλληλα, οι υποβολές απέκτησαν σύνδεση με το διαγωνισμό ώστε να
  ανεξαρτητοποιηθούν από το πρόβλημα και να ανήκουν στο διαγωνισμό για τον
  οποίο δημιουργήθηκαν. Επίσης, προστέθηκε και το πεδίο scoreDetailsjson στο
  FinalResults.}
\end{figure}


Έχοντας αλλάξει τη βάση, το επόμενο βήμα ήταν η υλοποίηση των αλλαγών στον
Grader ώστε να δίνεται η δυνατότητα της αντιγραφής των προβλημάτων και να
αξιοποιούνται τα νέα πεδία και πίνακες. Η πλειοψηφία των αλλαγών αφορούν τη
σελίδα διαχείρισης, καθώς εκεί πρέπει να αλλάξει ο τρόπος που αντιστοιχίζονται
τα προβλήματα με τους διαγωνισμούς, όπως και οι υποβολές αυτών. Ακόμα, η
λειτουργία του πλήκτρου μετακίνησης αλλάζει σε αντιγραφή, πάλι επιλέγοντας
διαγωνισμό. Τέλος, στο κάτω μέρος της σελίδας, όπου αναγράφονταν τα ανένταχτα
προβλήματα, κρίθηκε προτιμότερο να αναγράφονται όλα τα προβλήματα ώστε να είναι
ευκολότερο να αναζητηθεί και να αντιγραφεί κάποιο σε ένα νέο διαγωνισμό. Η νέα
διαχείριση παρουσιάζεται στα σχήματα 5.4 και 5.5.

\bigskip

\begin{figure}
  \centering
  \includegraphics[scale=0.5,trim=4 4 4 4,clip]{Figures/aftersep.png}
  \caption[Διαχείριση διαγωνισμών με αντιγραφή προβλημάτων]{Η διαχείριση διαγωνισμών
  δεν έχει κάποια διαφορά εμφανισιακά, αλλά πλέον επιτρέπεται η χρήση ενός
  προβλήματος σε πολλαπλούς διαγωνισμούς, όπως φαίνεται στο πρόβλημα sudokugame.
  Το πρώην πλήκτρο μεταφοράς στα δεξιά κάθε προβλήματος πλέον αντιγράφει το πρόβλημα
  στον επιλεγμένο διαγωνισμό, ενώ το X το αφαιρεί χωρίς να το διαγράφει.}
\end{figure}

\begin{figure}
  \centering
  \includegraphics[scale=0.5,trim=4 4 4 4,clip]{Figures/aftersepall.png}
  \caption[Εμφάνιση όλων των προβλημάτων]{Το κάτω μέρος της διαχείρισης
  επανασχεδιάστηκε ώστε να περιέχει όλα τα προβλήματα για εύκολη επισκόπηση,
  τροποποίηση τους και αντιγραφή τους σε διαγωνισμούς.}
\end{figure}

\bigskip

Μια ενδιαφέρουσα παρατήρηση είναι ότι η αντιγραφή ενός προβλήματος σε νέο
διαγωνισμό, απλά αλλάζει τους συσχετισμούς στη βάση, προσθέτοντας μια νέα
εγγραφή στον CompProblems. Τόσο τα αρχεία ελέγχου, που είναι αποθηκευμένα στο
δίσκο του εξυπηρετητή για να διαβάζονται από τον Kewii, όσο και οι ομάδες
αρχείων ελέγχου που αντιστοιχίζονται στη βάση με τα προβλήματα, δεν
αντιγράφονται και ως αποτέλεσμα αντιστοιχούν στο πρόβλημα σε όλους τους
διαγωνισμούς που αυτό ανήκει. Η συγκεκριμένη σχεδιαστική επιλογή στηρίχθηκε στο
σκεπτικό ότι το πρόβλημα δεν αναμένεται να αλλάζει σημαντικά κατά την
επαναχρησιμοποίηση του. Το ενδεχόμενο να χρειαστεί κάποια αλλαγή σε πρόβλημα
που ανήκει ήδη σε παλαιότερους ή παράλληλους διαγωνισμούς δε μπορεί να
αποκλειστεί, και για το λόγο αυτό προστέθηκε ένα προειδοποιητικό μήνυμα στη
σελίδα διαχείρισης αρχείων ελέγχου, προς όποιο διαχειριστή επιχειρήσει τέτοιες
αλλαγές.


\chapter{Λοιπές Προσθήκες}

Εκτός από τις νέες δυνατότητες που αναλύθηκαν στα προηγούμενα κεφάλαια,
υλοποιήθηκαν και αλλαγές μικρότερης πολυπλοκότητας, που δε χρειάζονται
ολόκληρο κεφάλαιο για να περιγραφούν ξεχωριστά. Στο συγκεκριμένο κεφάλαιο θα
αναφερθούν οι σημαντικότερες από αυτές.

\section{Προσθήκη γλώσσας προγραμματισμού Python}

\subsection{Προσθήκη γλωσσών στο Grader/Kewii}

Ο Grader, όπως έχει αναφερθεί και σε προηγούμενα κεφάλαια, επιτρέπει στους
διαγωνιζόμενους την υποβολή λύσεων σε οποιαδήποτε γλώσσα προγραμματισμού
υποστηρίζεται. Οι υποστηριζόμενες γλώσσες προγραμματισμού είναι οι παρακάτω:

\begin{itemize}
    \setlength\itemsep{0em}
    \item C
    \item C++
    \item Pascal
    \item Pazcal
    \item F\#
    \item OCaml
    \item Java
    \item Fortran
    \item Haskell
\end{itemize}

\bigskip

Η προσθήκη μιας νέας γλώσσας στο Grader δεν αποτελεί δύσκολη διαδικασία. Όσον
αφορά στο frontend, αρκεί απλά η προσθήκη στο μενού επιλογής γλώσσας στην
υποβολή και η αντίστοιχη κωδικοποίηση που θα χρησιμοποιηθεί για την καταχώρηση
της υποβολής σε βάση και Kewii (γίνεται συνήθως με χρήση της επέκταση των
πηγαίων αρχείων της γλώσσας, π.χ. cpp για C++). Όπως ο Kewii δεν εμπλέκεται
στη διαδικασία της αξιολόγησης, ο Grader, αντίστοιχα, έχει καθήκον απλά να
περάσει την επιλογή της γλώσσας και τον πηγαίο κώδικα ώστε να αναλάβει ο Kewii
τον έλεγχο.

\bigskip

Ο Kewii αναλαμβάνει, για κάθε υποβολή, να μεταγλωττίσει τον πηγαίο κώδικα ώστε
να παράξει το εκτελέσιμο αρχείο και έπειτα να τρέξει το εκτελέσιμο για κάθε
αρχείο ελέγχου που του έχει ζητηθεί. Η μεταγλώττιση και η εκτέλεση των υποβολών
γίνεται σε ένα περιορισμένο περιβάλλον, με τη χρήση μόνο των αναγκαίων
μεταγλωττιστών και βιβλιοθηκών. Για την προσθήκη μιας γλώσσας θα πρέπει να
εγκατασταθούν στο συγκεκριμένο περιβάλλον τα αντίστοιχα εκτελέσιμα και να
τροποποιηθεί το αρχείο που περιέχει τις αντιστοιχίσεις γλωσσών και εντολών
μεταγλώττισης/εκτέλεσης.

\subsection{Επιλογή Python}

Η Python είναι μια interpreted προγραμματιστική γλώσσα υψηλού επιπέδου γενικού
σκοπού. Διαθέτει πολύ πλούσια βιβλιοθήκη για μια ευρεία γκάμα λειτουργιών και
επιστημονικών πεδίων. Έχει σχεδιαστεί με έμφαση στην αναγνωσιμότητα και στη
χρησιμοποίηση λιγότερου κώδικα, ενώ ευνοεί πολλαπλά προγραμματιστικά στυλ όπως
είναι ο δομημένος, ο αντικειμενοστρεφής και ο συναρτησιακός προγραμματισμός.

\bigskip

Δεδομένης της δημοτικότητας της Python και της ευκολίας χρήσης της, είναι μια
απαραίτητη προσθήκη στο Grader που πιθανότατα θα εκτιμηθεί από διαγωνιζόμενους
μαθητές και φοιτητές, για τους οποίους είναι αρκετά πιθανό να αποτέλεσε πρώτη
γλώσσα εισαγωγής στον προγραμματισμό. Η Python δε λείπει από κανένα από τα
συστήματα αξιολόγησης που μελετήθηκαν, ενώ πλέον αποτελεί τη δημοφιλέστερη
επιλογή στα κορυφαία αμερικάνικα πανεπιστήμια όσον αφορά στα εισαγωγικά
μαθήματα των τμημάτων επιστήμης των υπολογιστών (\cite{popularpython}).
Είναι μια από τις πιο αναπτυσσόμενες προγραμματιστικές γλώσσες σύμφωνα με
στοιχεία του Stack Overflow (\cite{pythongrowth}) χάρη κυρίως στην
καθιέρωση της σε πολλά προγράμματα προπτυχιακών σπουδών και στην ανάπτυξη των
τομέων της ανάλυσης δεδομένων και μηχανικής μάθησης, στους οποίους κυριαρχεί ως
εργαλείο (\cite{whypython}).

\bigskip

Η διαφορά της Python με τις γλώσσες που υποστηρίζει ο Kewii είναι ότι αυτή
αποτελεί μια interpreted γλώσσα και ως αποτέλεσμα δεν έχει ιδιαίτερο νόημα η
μεταγλώττιση της σε ένα εκτελέσιμο. Σε κάθε υποβολή που χρησιμοποιείται, θα
γίνεται απευθείας εκτέλεση με είσοδο τα αρχεία ελέγχου και θα εμφανίζονται μόνο
τα σφάλματα κατά τον χρόνο εκτέλεσης στον διαγωνιζόμενο, αντίθετα με τις
υπόλοιπες γλώσσες όπου υπάρχουν και σφάλματα μεταγλώττισης. Στο μέλλον θα
μπορούσε να διερευνηθεί η δυνατότητα ενός εργαλείου ανάλυσης του πηγαίου κώδικα
για τη διευκόλυνση των διαγωνιζόμενων με καλύτερα μηνύματα σφαλμάτων.

\bigskip

Η έκδοση της Python που επιλέχθηκε είναι η 2.7. Η υποστήριξη της συγκεκριμένης
έκδοσης και γενικά της Python 2 θα διαρκέσει έως το 2020, οπότε καλό θα είναι
να προστεθεί και η Python 3 στο μέλλον. Δεδομένης της δουλειάς που έγινε για
την προσθήκη της έκδοσης 2, η προσθήκη της 3 θα είναι αρκετά εύκολη και άμεση.

\section{Μαζικό ανέβασμα αρχείων ελέγχων/ομάδων}

\subsection{Κίνητρο}

Κατά τη διαδικασία δημιουργίας ενός προβλήματος, είναι απαραίτητο να προστεθεί
ένας συχνά μεγάλος αριθμός αρχείων ελέγχου. Ο μόνος τρόπος να γίνει αυτό είναι
μέσω της σελίδας διαχείρισης των αρχείων ελέγχου, όπως φαίνεται στο σχήμα 4.1,
και κάθε νέο αρχείο ανεβαίνει ξεχωριστά, δηλαδή δεν υπάρχει κάποια μαζική
διαδικασία.

\bigskip

Για να αποφευχθεί η επαναληπτική και χρονοβόρα διαδικασία, οι έως τώρα διαχειριστές
έγραφαν απλά PHP scripts για την ενημέρωση της βάσης με τα νέα αρχεία ελέγχου,
και αντέγραφαν χειροκίνητα τα αρχεία στους αντίστοιχους φακέλους του Kewii.
Μετά την προσθήκη των testcase groups, στη διαδικασία αυτή προστέθηκε και
η δημιουργία και παραμετροποίηση των groups με τα επιθυμητά αρχεία και tags.

\bigskip

Για τους παραπάνω λόγους κρίθηκε αναγκαία η προσθήκη ενός αυτοματοποιημένου
τρόπου μαζικής προσθήκης αρχείων για τα προβλήματα, στο οποίο να υπάρχει και η
δυνατότητα ορισμού των κατάλληλων testcase groups. Το εργαλείο που θα
υλοποιηθεί θα οφείλει τόσο να ενημερώνει τη βάση, όσο και να φορτώνει τα αρχεία
στον εξυπηρετητή του Kewii. Για την επεξεργασία των ομάδων, θα πρέπει να
χρησιμοποιηθεί ένα περιγραφικό αρχείο, ιδανικά σε ένα ανθρωπίνως αναγνώσιμο
τύπο αρχείου με σκοπό την εύκολη δημιουργία του.

\subsection{Υλοποίηση}

Το εργαλείο που περιγράφηκε θα προστεθεί στη σελίδα διαχείρισης των αρχείων
ελέγχου κάτω από το ήδη υπάρχον ανέβασμα μεμονωμένου αρχείου. Μετά την προσθήκη
η σελίδα θα έχει τη μορφή του σχήματος 6.1. Ο διαχειριστής θα ανεβάζει ένα
συμπιεσμένο αρχείο (zip) με τα αρχεία εισόδου και εξόδου που θέλει να προσθέσει
στο πρόγραμμα. Στο αρχείο θα πρέπει, επιπλέον, να υπάρχει και ένα αρχείο με
όνομα descriptor.json το οποίο θα αναλαμβάνει να περιγράψει στο εργαλείο τις
προδιαγραφές αρχείων και ομάδων.

\bigskip

Η μορφή JSON επιλέχθηκε για τους λόγους που αναφέρθηκαν παραπάνω, δηλαδή για τα
χαρακτηριστικά της ως αναγνώσιμη και με δυνατότητα εύκολης εισαγωγής αντικειμένων
και λιστών. Στο συγκεκριμένο αρχείο θέλαμε να περιγράφονται τα παρακάτω:

\begin{itemize}
    \item Ο τρόπος ονομασίας των αρχείων ελέγχου για τα αρχεία εισόδου και εξόδου

    \item Το πλήθος των ομάδων αρχείων ελέγχου

    \item Για κάθε ομάδα αρχείων ελέγχου το όνομα της, οι πόντοι
      και τα αρχεία ελέγχου που περιέχει

    \item Για κάθε αρχείο ελέγχου μέσα σε ομάδα ο τύπος εκτέλεσης του (tag)

\end{itemize}

Ο Grader περιμένει να βρει μέσα στο συμπιεσμένο αρχείο ζευγάρια εισόδου-εξόδου
για κάθε αρχείο ελέγχου που πρέπει να προστεθεί. Επομένως, θα πρέπει να είναι
γνωστή η μορφή των ονομάτων των αρχείων. Για μεγαλύτερη ευελιξία,
δημιουργήθηκαν δύο προαιρετικά πεδία, για αρχεία εισόδου και εξόδου αντίστοιχα,
τα οποία δέχονται τη μορφή ονομασίας που θα χρησιμοποιηθεί με χρήση ενός format
παρόμοιου με το printf της PHP. Προφανώς, αυτό θα πρέπει να περιέχει ένα
προσδιοριστή για ακέραιους αριθμούς ώστε να λειτουργεί σωστά η αντικατάσταση
για την παραγωγή των ονομασιών των αρχείων. Αν τα πεδία αυτά δεν έχουν
συμπληρωθεί χρησιμοποιείται η προεπιλεγμένη μορφή, δηλαδή probname.in1 και
probname.out2, για το πρώτο αρχείο εισόδου και εξόδου ενός προβλήματος με όνομα
probname.

\bigskip

Όσον αφορά στις ομάδες αρχείων ελέγχου, αυτές πρέπει να περιέχονται μέσα στο
descriptor.json σαν λίστες αντικειμένων. Κάθε αντικείμενο που αντιστοιχεί σε
μια νέα ομάδα, έχει πεδία για το όνομα της, τους πόντους που αξίζει και τα
αρχεία ελέγχου που θα περιέχει. Το τελευταίο πεδίο αποτελεί λίστα και περιέχει
αντικείμενα με δύο πεδία: αριθμός αρχείου ελέγχου και τύπος εκτέλεσης. Ο τύπος
εκτέλεσης θα δίνεται με το όνομα του χρώματος, δηλαδή θα μπορεί να έχει τις
τιμές orange, yellow, blue, green, purple. Ακολουθεί ένα πρότυπο
descriptor.json στο οποίο έχουν συμπληρωθεί όλα τα διαθέσιμα πεδία.

\FloatBarrier

\lstinputlisting[frame=single,captionpos=b,caption=Παράδειγμα descriptor.json.
Το συγκεκριμένο αρχείο περιγράφει 4 αρχεία ελέγχου σε 3 ομάδες αρχείων. Ακόμα\,
ορίζει τη μορφή ονομασίας των αρχείων εισόδου και
εξόδου.]{Listings/descriptordiploma.json}

\begin{figure}
  \centering
  \includegraphics[scale=0.5,trim=4 4 4 4,clip]{Figures/massupload.png}
  \caption[Προσθήκη επιλογής μαζικού ανεβάσματος αρχείων]{Η επιλογή μαζικού
  ανεβάσματος αρχείων ελέγχου τοποθετήθηκε κάτω από το ανέβασμα μεμονωμένων αρχείων.
  Στον τίτλο συμπεριλήφθηκε και η προειδοποίηση για τη διαγραφή υπαρχόντων αρχείων
  και ομάδων κατά το ανέβασμα.}
\end{figure}

\subsection{Εργαλείο δημιουργίας}

Χάρη στην αναγνώσιμη μορφή του JSON είναι εύκολο ένας διαχειριστής να συντάξει
ένα JSON αρχείο για το ανέβασμα αρχείων ελέγχου και καθορισμό groups. Παρόλα
αυτά, θα είναι αρκετά χρήσιμο το συγκεκριμένο αρχείο να μη συντάσσεται με το
χέρι, ώστε να μην υπάρχει και η πιθανότητα σφάλματος. Για το λόγο αυτό
δημιουργήθηκε ένα interactive script σε Python για την αυτόματη παραγωγή ενός
descriptor.json αρχείου.

\bigskip

Το συγκεκριμένο script, μόλις εκτελεστεί, σε οποιοδήποτε περιβάλλον, διατυπώνει
ερωτήσεις σχετικές με τον αριθμό και τα ονόματα των αρχείων ελέγχου και ομάδων
και έπειτα για κάθε ομάδα σχετικά με το ποια αρχεία περιέχει και τους τύπους
εκτέλεσης τους. Στο τέλος, παράγει το αρχείο που περιγράφηκε. Στο σχήμα 6.2
φαίνεται μια τυπική εκτέλεση του συγκεκριμένου εργαλείου.

\begin{figure}
  \centering
  \includegraphics[scale=0.6,trim=4 4 4 4,clip]{Figures/interactive.png}
  \caption[Εκτέλεση διαδραστικού generator αρχείου descriptor.json]{Ένα παράδειγμα
  εκτέλεσης του generatejson.py για την αυτόματη παραγωγή του απαραίτητου
  descriptor.json. Οι εντολές του χρήστη είναι υπογραμμισμένες.}
\end{figure}

\section{Αλλαγή MySQL connector}

Μια τροποποίηση που θεωρήθηκε απαραίτητη ήταν η αλλαγή της επέκτασης
επικοινωνίας της PHP με τη MySQL βάση δεδομένων μας. Η επέκταση, που
χρησιμοποιείται τόσο από τον Grader όσο και από τον Kewii, είναι το πρωτότυπο
(original) MySQL API. Το συγκεκριμένο API έχει αρκετά μειονεκτήματα, που έχουν
οδηγήσει και στην παύση της υποστήριξης του όπως περιγράφεται στο
\cite{deprecation}.

\bigskip

Δεδομένου ότι η συγκεκριμένη επέκταση δεν συντηρείται πλέον και ακόμα χειρότερα
εμφανίζει σφάλματα ήδη από την έκδοση 5.5 της PHP και στην 7 δεν υπάρχει, είναι
επιτακτικό να αφαιρεθεί από τον κώδικα της εφαρμογής μας και να αντικατασταθεί
με μια πιο σύγχρονη. Οι επίσημα υποστηριζόμενες επεκτάσεις που μπορούμε να
χρησιμοποιήσουμε είναι οι mysqli και PDO. Για την επιλογή χρησιμοποιήθηκε ο
πίνακας σύγκρισης των προαναφερθέντων επεκτάσεων που υπάρχει στο manual της PHP
(\cite{mysqlapis}) και φαίνεται στο σχήμα 6.3.

\begin{figure}
  \centering
  \includegraphics[scale=0.55,trim=4 4 4 4,clip]{Figures/mysqlconnectors.png}
  \caption[Σύγκριση των επεκτάσεων MySQL της PHP]{Οι δυνατότητες των επίσημων
  επεκτάσεων της PHP για επικοινωνία με MySQL βάση. Παρατηρούμε ότι mysqli και
  PDO\_MySQL είναι εξίσου καλές επιλογές.}
\end{figure}

\bigskip

Όπως βλέπουμε, τόσο το mysqli όσο και το PDO υποστηρίζονται και προτείνονται
για νέες υλοποιήσεις. Κάτι που δεν γίνεται εμφανές στο συγκεκριμένο πίνακα
είναι το γεγονός ότι το PDO αποτελεί μια γενικευμένη διεπαφή ή οποία διαθέτει
οδηγούς για πολλές διαφορετικές βάσεις δεδομένων εκτός από την SQL,
προσφέροντας στο χρήστη ένα API υψηλού επιπέδου και επιτρέποντας του να αλλάξει
πολύ εύκολα βάση δεδομένων, αν χρειαστεί. Και οι δύο επεκτάσεις έχουν αρκετές
δυνατότητες που μας ενδιαφέρει να υλοποιηθούν με σημαντικότερη αυτή των
prepared statements.

\bigskip

Τα prepared statements επιτρέπουν την εκτέλεση συγκεκριμένων επερωτημάτων
(queries) με αντικατάσταση των παραμέτρων που αλλάζουν κάθε φορά. Αυτό έχει δύο
σημαντικά πλεονεκτήματα. Αρχικά, αυξάνει ιδιαίτερα την απόδοση στην εκτέλεση
διαδοχικών queries βασισμένων στο ίδιο prepared statement. Επιπλέον, βελτιώνει
σε μεγάλο βαθμό την ασφάλεια της εφαρμογής μας, καθώς αποκλείει ουσιαστικά την
πιθανότητα επίθεσης έκχυσης (injection) κώδικα SQL.

\bigskip

Η επίθεση με SQL injection γίνεται δυνατή λόγω του τρόπου που δημιουργείται το
κάθε query. Αν δεν ελεγχθεί σωστά η είσοδος του χρήστη, υπάρχει η περίπτωση ο
τελευταίος να εκμεταλλευτεί ειδικούς χαρακτήρες της SQL, π.χ. τον χαρακτήρα που
ξεκινάει ένα σχόλιο, και να αλλοιώσει το query, επηρεάζοντας την εκτέλεση και
επιτυγχάνοντας, ιδανικά για τον επιτιθέμενο, την πρόσβαση σε ευαίσθητα δεδομένα
ή σελίδες.

\bigskip

Ο τρόπος που επιτυγχάνεται η αντοχή στις προαναφερθείσες επιθέσεις βασίζεται
στον τρόπο λειτουργίας των prepared statements. Σε πρώτη φάση, δημιουργείται το
πρότυπο επερώτημα δίχως τις παραμέτρους και μεταγλωττίζεται ξεχωριστά. Οι
παράμετροι, στέλνονται έπειτα με διαφορετικό πρότυπο επικοινωνίας με
αποτέλεσμα να μην είναι δυνατόν να εισαχθούν ειδικοί χαρακτήρες που θα
επηρεάσουν την εκτέλεση του query.

\bigskip

Για την υλοποίηση επιλέχθηκε, τελικά, το PDO για τους λόγους επεκτασιμότητας
που αναφέρθηκαν παραπάνω δεδομένου ότι στα υπόλοιπα κριτήρια δεν υστερεί σε
σχέση με το mysqli, και η υπάρχουσα σχεδίαση μας είναι αντικειμενοστρεφής ούτως
ή άλλως, που υποστηρίζεται από το PDO (που δεν υποστηρίζει στυλ δομημένου
προγραμματισμού).

\subsection{Συνοπτική περιγραφή επέκτασης PDO}

Η επέκταση PDO (PHP Data Objects), αποτελεί μια μικρού μεγέθους, συνεπή (για
τις διαφορετικές βάσεις δεδομένων) διεπαφή για την πρόσβαση και χρήση βάσεων
δεδομένων σε PHP. Μέσω των διάφορων, χαμηλού επιπέδου, οδηγών της επιτρέπει την
ενοποίηση του πλήθους των μεθόδων κάθε βάσης σε μια κοινή, πλούσια διεπαφή που
περιστρέφεται γύρω από κοινά αντικείμενα που αντιστοιχούν σε κάθε πίνακα ξεχωριστά.
(\cite{pdo}).

\bigskip

Η σχεδίαση της συγκεκριμένης επέκτασης έχει γίνει με έμφαση στην ευκολία χρήσης
και την επαναχρησιμοποίηση του ίδιου κώδικα για διαφορετικές βάσεις δεδομένων
και συναφείς λειτουργίες. Η σύνδεση στην εκάστοτε βάση δεδομένων γίνεται με τη
χρήση μιας σειριακής δομής δεδομένων, με όνομα Data Source Name (\cite{dsn}),
έπειτα από την οποία, δημιουργείται ένα αντικείμενο που αντιστοιχεί στη
σύνδεση. Τα queries εκτελούνται με τη χρήση της μεθόδου query, εκτός αν
χρησιμοποιηθούν prepared statements (PDOStatement), όπου χρησιμοποιούνται οι
μέθοδοι prepare και execute. Η επέκταση εμπεριέχει, επίσης, και δική της κλάση
εξαιρέσεων (PDOException). Ακολουθούν παραδείγματα απλών λειτουργιών
χρησιμοποιώντας τη συγκεκριμένη επέκταση/API.

\bigskip

\FloatBarrier

\lstinputlisting[frame=single,captionpos=b,caption=Παραδείγματα χρήσης PDO για σύνδεσή με βάση\, εκτέλεση απλών queries και εκτέλεση prepared statement.]{Listings/pdoexamples.php}

\chapter{Συμπεράσματα}

\section{Καταληκτικές Παρατηρήσεις}

Στη συγκεκριμένη εργασία έγινε μια προσπάθεια βελτίωσης του συστήματος
αυτόματης αξιολόγησης Grader και προσθήκης δυνατοτήτων που θα το καταστήσουν
πιο ευέλικτο και εύκολο στη χρήση του. Για να επιτευχθεί αυτό, διερευνήθηκε ο
τρόπος λειτουργίας του όπως και ο τρόπος λειτουργίας άλλων παρόμοιων
συστημάτων. Για τις τροποποιήσεις και τις προσθήκες που υλοποιήθηκαν, έγινε
προσπάθεια να χρησιμοποιηθούν σωστές σχεδιαστικές επιλογές με έμφαση στη
βελτίωση της ποιότητας του κώδικα και στην μετέπειτα ευκολία συντήρησης και
επέκτασης του.

\bigskip

Στο Κεφάλαιο 2, παρουσιάστηκαν συστήματα αυτόματης αξιολόγησης ελεύθερου
λογισμικού που προσφέρονται για τη διενέργεια διαγωνισμών και λειτουργούν με
παρόμοιο τρόπο με το Grader. Αναλύθηκε η σχεδίαση, οι δυνατότητες και ο
τρόπος χρήσης τους.

\bigskip

Στο κεφάλαιο 3, είδαμε τον τρόπο λειτουργίας του Grader και του Kewii, της
εφαρμογής που τρέχει στον εξυπηρετητή και αναλαμβάνει την εκτέλεση των
υποβληθέντων προγραμμάτων. Αναλύθηκε η αρχιτεκτονική και ο τρόπος επικοινωνίας
μεταξύ τους. Αναφέρθηκαν, ακόμα, όλα τα βασικά στοιχεία του συστήματος, οι
συσχετισμοί τους και η χρήση τους από Kewii και Grader. Το συγκεκριμένο
κεφάλαιο έχει τον επιπρόσθετο σκοπό να λειτουργήσει στο μέλλον σαν έγγραφο
αναφοράς για όποιον επιθυμεί να επεκτείνει το σύστημα, βοηθώντας τον να
αντιληφθεί γρηγορότερα τον σχεδιασμό του.

\bigskip

Στα κεφάλαια 4,5 και 6, αναλύθηκαν οι σημαντικότερες αλλαγές που έγιναν κατά τη
διάρκεια της παρούσας εργασίας. Αυτές συμπεριλάμβαναν τη δημιουργία μιας νέας
έννοιας για το σύστημα, αυτής των ομάδων αρχείων ελέγχου (και ως αποτέλεσμα την
επέκταση ολόκληρου του συστήματος για την υποστήριξη της), την αλλαγή της
αρχιτεκτονικής προβλημάτων, διαγωνισμών και υποβολών προς διευκόλυνση της
λειτουργίας του Grader και ένα σύνολο άλλων, μικρότερης σημασίας, προσθηκών.

\bigskip

Κατά τη διαδικασία προσθήκης των παραπάνω δυνατοτήτων έγινε προσπάθεια
βελτίωσης της εκάστοτε υλοποίησης με αναδιαμόρφωση κλάσεων μεθόδων και δομών
δεδομένων ώστε ο κώδικας να είναι περισσότερο κατανοητός και διαχειρίσιμος από
τους μελλοντικούς συντηρητές του. Επίσης, καταγράφηκε η διαδικασία εγκατάστασης
της συνολικής εφαρμογής του σε ένα καινούριο σύστημα ώστε να είναι εύκολο να
μετεγκατασταθεί στο μέλλον ή να δημιουργηθεί περιβάλλον δοκιμών.
%(TODO: πρώτη φορά τα αναφέρω αυτά!)

\section{Μελλοντική Εργασία}

Υπάρχουν πολλές προσθήκες που θα μπορούσαν να γίνουν σε Grader και Kewii για τη
βελτιστοποίηση τους. Όσον αφορά στον πρώτο, θα μπορούσε να προστεθεί η δυνατότητα
επισκόπησης και σχολιασμού υποβληθέντων λύσεων (code reviews) όπου οι διαχειριστές
ή υπεύθυνοι για τους διαγωνισμούς θα μπορούσαν να σχολιάζουν τις λύσεις των
διαγωνιζόμενων και εκεί να γίνεται συζήτηση μεταξύ τους για τυχόν βελτιστοποιήσεις
και σφάλματα.

\bigskip

Επιπροσθέτως, θα ήταν αρκετά θετικό αν μπορούσε να διενεργηθεί ένας
επανασχεδιασμός της διαδικτυακής εφαρμογής σύμφωνα με μια αρχιτεκτονική
Model-View-Controller (MVC) ή παρόμοια με χρήση κάποιου σύγχρονου πλαισίου
(framework) ώστε να γίνει άμεσα πιο κατανοητός ο διαχωρισμός παρουσίασης και
υλοποίησης της λογικής της αξιολόγησης και των υπόλοιπων λειτουργιών. Κάτι
τέτοιο θα είχε ως προϋπόθεση πλήρη κατανόηση του Grader και του συνόλου των
μερών του, αλλά θα επιβράβευε άμεσα όσους θα ήταν υπεύθυνοι για την περαιτέρω
ανάπτυξη και συντήρηση του.

\bigskip

Μελλοντικά, θα μπορούσε να υπάρξει βελτίωση και του Kewii σε αρκετά θέματα.
Αρχικά, όπως έχει αναφερθεί και στο κεφάλαιο 6.1.2 για την Python, οι
διαγωνιζόμενοι θα επωφελούνταν στην περίπτωση προσθήκης ενός μηχανισμού για
ανάλυση του πηγαίου κώδικα των υποβολών τους, καθώς δεν εκτελείται μεταγλώττιση
και όλα τα σφάλματα εμφανίζονται κατά την εκτέλεση. Ένα εργαλείο που θα
μπορούσε να χρησιμοποιηθεί για το συγκεκριμένο σκοπό είναι το pylint
\footnote{\url{https://www.pylint.org/}}. Το συγκεκριμένο πρόγραμμα, έχει τη
δυνατότητα τόσο να εντοπίζει σφάλματα πριν την εκτέλεση, όσο και να ελέγχει την
ποιότητα του κώδικα σύμφωνα με συγκεκριμένα στάνταρ όπως είναι π.χ. το PEP 8
\footnote{\url{https://www.python.org/dev/peps/pep-0008/}}.

\bigskip

Άλλο ένα θέμα που επιδέχεται βελτίωση είναι η ασφάλεια εκτέλεσης του Kewii.
Προφανώς, είναι αρκετά δύσκολο να επιτυγχάνεται η απόλυτη ασφάλεια όταν εξ
ορισμού εκτελείται άγνωστος κώδικας σε έναν εξυπηρετητή. Παρόλα αυτά, μπορεί να
υλοποιηθεί ένα πιο αποκλεισμένο (sandboxed) περιβάλλον, πιθανόν με τη χρήση
ενός εικονικού μηχανήματος που να έχει ως στόχο τον αποκλεισμό των εκτελούμενων
προγραμμάτων ή με χρήση ειδικευμένου λογισμικού ως container, π.χ. Docker
\footnote{\url{https://www.docker.com/}}.

\bigskip

Τέλος, θα ήταν ωφέλιμο για την απόδοση του Kewii να υλοποιηθεί μια παραλληλοποίηση
των εκτελέσεων πολλαπλών υποβολών ταυτόχρονα, που θα μείωνε σε μεγάλο βαθμό το
χρόνο εκτέλεσης, εάν χρησιμοποιούνταν με χρήση συστάδας εικονικών ή φυσικών
μηχανημάτων. Η συγκεκριμένη υλοποίηση έχει ήδη γίνει στο \cite{Tsiamitros} και
είναι συμβατή με το σύστημα μας. Μένει να διερευνηθούν οι λεπτομέρειες της
προσθήκης και να υλοποιηθεί, με την προϋπόθεση να υπάρχει δυνατότητα πλήρης
αξιοποίησης του νέου συστήματος σε θέμα πόρων.

%%%  Bibliography

\bibliographystyle{softlab-thesis}
\bibliography{thesis}

%%%  End of document

\end{document}