|
|
|
@ -393,14 +393,14 @@ recruiters and also some universities.
|
|
|
|
|
|
|
|
|
|
# Analysis
|
|
|
|
|
|
|
|
|
|
None of the existing projects we came across is capable of all the required
|
|
|
|
|
features for the new system. There is no grading system which is designed to
|
|
|
|
|
support a complicated evaluation pipeline, so this unexplored field has to be
|
|
|
|
|
designed with caution. Also, no project is modern and extensible enough so it
|
|
|
|
|
could be used as a base for the new system. After considering all these facts,
|
|
|
|
|
it is clear that a new system has to be written from scratch. This implies, that
|
|
|
|
|
only a subset of all the features will be implemented in the first version, the
|
|
|
|
|
others coming in the following releases.
|
|
|
|
|
None of the existing projects we came across fulfills all the requested features
|
|
|
|
|
for the new system. There is no grading system which supports arbitrary-length
|
|
|
|
|
evaluation pipeline, so we have to implement this feature ourselves, cautiously
|
|
|
|
|
treading through unexplored fields. Also, no existing solution is extensible
|
|
|
|
|
enough to be used as a base for the new system. After considering all these
|
|
|
|
|
facts, it is clear that a new system has to be written from scratch. This
|
|
|
|
|
implies that only a subset of all the features will be implemented in the first
|
|
|
|
|
version, the others coming in the following releases.
|
|
|
|
|
|
|
|
|
|
Gathered features are categorized based on priorities for the whole system. The
|
|
|
|
|
highest priority has main functionality similar to current CodEx. It is a base
|
|
|
|
@ -417,7 +417,7 @@ side) and command-line submit tool. Plagiarism detection is not likely to be
|
|
|
|
|
part of any release in near future unless someone other makes the engine. The
|
|
|
|
|
detection problem is too hard to be solved as part of this project.
|
|
|
|
|
|
|
|
|
|
We named the new project as **ReCodEx -- ReCodEx Code Examiner**. The name
|
|
|
|
|
We named the new project **ReCodEx -- ReCodEx Code Examiner**. The name
|
|
|
|
|
should point to the old CodEx, but also reflect the new approach to solve
|
|
|
|
|
issues. **Re** as part of the name means redesigned, rewritten, renewed, or
|
|
|
|
|
restarted.
|
|
|
|
@ -446,28 +446,29 @@ of the system.
|
|
|
|
|
|
|
|
|
|
## Basic concepts
|
|
|
|
|
|
|
|
|
|
The system is designed as a web application. The requirements say, that user
|
|
|
|
|
interface must be accessible from students' computers without installation
|
|
|
|
|
additional software. This immediately implies that users are connected to the
|
|
|
|
|
internet, so it is used as communication medium. Today, there are two main ways
|
|
|
|
|
of designing graphical user interface -- native app or web page. Make nice and
|
|
|
|
|
multi-platform application with graphical interface is almost impossible because
|
|
|
|
|
of large number of different environments. Also, these applications often
|
|
|
|
|
requires installation or at least downloading its files (sources or binaries).
|
|
|
|
|
However, creating web application is easier, because every personal computer has
|
|
|
|
|
a internet browser installed. Also, browsers supports sort of unified and
|
|
|
|
|
standardized environment of HTML5 and JavaScript. CodEx is also web application
|
|
|
|
|
and everybody seems happy about it. There are other communicating channels every
|
|
|
|
|
user have available like email or git, but they are totally inappropriate for
|
|
|
|
|
designing user interfaces on top of them.
|
|
|
|
|
|
|
|
|
|
The application interacts with users. From the project assignment is clear, that
|
|
|
|
|
the system has to keep personalized data about users and adapt presented content
|
|
|
|
|
according to this knowledge. User data cannot be publicly visible, so that
|
|
|
|
|
implies necessity of user authentication. The application also has to support
|
|
|
|
|
multiple ways of authentication (university authentication systems, a company
|
|
|
|
|
LDAP server, an OAuth server...) and permit adding more security measures in the
|
|
|
|
|
future, such as two-factor authentication.
|
|
|
|
|
The system is designed as a web application. The requirements say that the user
|
|
|
|
|
interface must be accessible from students' computers without the need to
|
|
|
|
|
install additional software. This immediately implies that users have to be
|
|
|
|
|
connected to the internet, so it is used as communication medium. Today, there
|
|
|
|
|
are two main ways of designing graphical user interface -- as a native
|
|
|
|
|
application or a web page. Creating a nice and multi-platform application with
|
|
|
|
|
graphical interface is almost impossible because of the large number of
|
|
|
|
|
different environments. Also, these applications often requires installation or
|
|
|
|
|
at least downloading its files (sources or binaries). On the other hand,
|
|
|
|
|
distributing a web application is easier, because every personal computer has an
|
|
|
|
|
internet browser installed. Also, browsers support an (mostly) unified and
|
|
|
|
|
standardized environment of HTML5 and JavaScript. CodEx is also a web
|
|
|
|
|
application and everybody seems satisfied with it. There are other communicating
|
|
|
|
|
channels most programmers have available, such as e-mail or git, but they are
|
|
|
|
|
inappropriate for designing user interfaces on top of them.
|
|
|
|
|
|
|
|
|
|
The application interacts with users. From the project assignment it is clear,
|
|
|
|
|
that the system has to keep personalized data about users and adapt presented
|
|
|
|
|
content according to this knowledge. User data cannot be publicly visible, so
|
|
|
|
|
that implies necessity of user authentication. The application also has to
|
|
|
|
|
support multiple ways of authentication (university authentication systems, a
|
|
|
|
|
company LDAP server, an OAuth server...) and permit adding more security
|
|
|
|
|
measures in the future, such as two-factor authentication.
|
|
|
|
|
|
|
|
|
|
User data also includes a privilege level. From the assignment it is required to
|
|
|
|
|
have at least two roles, _student_ and _supervisor_. However, it is wise to add
|
|
|
|
@ -481,22 +482,21 @@ duties related with lecturing of labs are already associated with supervisors,
|
|
|
|
|
so this role seems not so useful. In addition, no one requested more than three
|
|
|
|
|
level privilege scheme.
|
|
|
|
|
|
|
|
|
|
School labs are lessons for some students lead by one (or sometimes two or
|
|
|
|
|
three) supervisors. Students have the same homework and supervisors are
|
|
|
|
|
evaluating its solutions. This organization has to be carried into the new
|
|
|
|
|
system. Counterpart to real labs are virtual groups. This concept was already
|
|
|
|
|
discussed in previous chapter including need for hierarchical structure of
|
|
|
|
|
groups. Right for attending labs has only a person, who is student of the
|
|
|
|
|
university and is recorded in university information system. To allow
|
|
|
|
|
restriction of group members in ReCodEx, there two type of groups -- _public_
|
|
|
|
|
and _private_. Public groups are open for every registered users, but to become
|
|
|
|
|
a member of private group one of its supervisors have to add that user. This
|
|
|
|
|
could be done automatically at beginning of the term with data from information
|
|
|
|
|
system, but unfortunately there is no such API yet. However, creating this API
|
|
|
|
|
is now considered by university leadership. Another just as good solution for
|
|
|
|
|
restricting membership of a group is to allow anyone join the group with
|
|
|
|
|
supplementary confirmation of supervisors. It has no additional benefits, so
|
|
|
|
|
approach with public and private groups is implemented.
|
|
|
|
|
School labs are lessons for some students lead by supervisors. Students have the
|
|
|
|
|
same homework and supervisors are evaluating its solutions. This organization
|
|
|
|
|
has to be carried into the new system. Counterpart to real labs are virtual
|
|
|
|
|
groups. This concept was already discussed in previous chapter including need
|
|
|
|
|
for hierarchical structure of groups. Right for attending labs has only a
|
|
|
|
|
person, who is student of the university and is recorded in university
|
|
|
|
|
information system. To allow restriction of group members in ReCodEx, there two
|
|
|
|
|
type of groups -- _public_ and _private_. Public groups are open for every
|
|
|
|
|
registered users, but to become a member of private group one of its supervisors
|
|
|
|
|
have to add that user. This could be done automatically at beginning of the term
|
|
|
|
|
with data from information system, but unfortunately there is no such API yet.
|
|
|
|
|
However, creating this API is now considered by university leadership. Another
|
|
|
|
|
just as good solution for restricting membership of a group is to allow anyone
|
|
|
|
|
join the group with supplementary confirmation of supervisors. It has no
|
|
|
|
|
additional benefits, so approach with public and private groups is implemented.
|
|
|
|
|
|
|
|
|
|
Supervisors using CodEx in their labs usually set minimum amount of points
|
|
|
|
|
required to get a credit. These points can be get by solving assigned exercises.
|
|
|
|
|