Detailed Design Elements
This article covers a variety of low-level detailed design elements making up the PC2v9 code.
The InternalController class is the controller (the "C" in the Model-View-Controller (MVC) structure) for the contest.
This class provides ways to fetch and update contest data, control contest state, and control logins (logoff, etc.)
The InternalContest class is the model (the "M" in the Model-View-Controller (MVC) structure) for the contest.
This class holds the data (the "model") for the contest; the class also contains listeners for data changes.
Instances of InternalContest are frequently named contest in the code, reflecting the fact that they
hold the data for the contest. An instance of InternalContest contains fields for things like
ContestInformation (including things such as contest title, scheduled start time, etc.); ProblemList
(a description of the contest problems); LanguageList (a list of the programming languages supported
in the contest); and many additional data fields.
The InternalContest class defines accessor methods for each of the types of data in the model.
For example, the following methods are defined for accessing and updating the ContestInformation field:
ContestInformation getContestInformation()
void addContestInformation(ContestInformation contestInformation)
void updateContestInformation(ContestInformation contestInformation)InternalContest also defines methods for adding and removing a listener for any change
in ContestInformation:
void addContestInformationListener(IContestInformationListener contestInformationListener)
void removeContestInformationListener(IContestInformationListener contestInformationListener)There are similar methods in InternalContest for accessing and manipulating other contest data classes, including
Account, Clarification, ClientSettings, Connection, ContestTime, Group,
Judgement, Language, Problem, Profile, Run, Site, and others.
The Packet class defines the types of packets which move over a network between PC2v9 Modules.
See the separate PC2 Packets article for details.
This class defines a list of RunResultsFiles, typically stored on disk.
This class is a collection of files and statistics produced as output for a run, judgement and validation.
Each RunResultsFile is associated with a Run and RunJudgement, because each time a submitted run is executed a new judgement/set of statistics is produced.
This interface defines the external view of a controller (in the Model-View-Controller (MVC) sense). In essence, IInternalController defines the functions provided by modules comprising the contest system.
IInternalController is implemented by the InternalController class, as well as by a variety of
additional special-purpose classes.
This interface defines the external view of a model (in the Model-View-Controller (MVC) sense). In essence,
IInternalContest defines the functions available for manipulating the contest model (data).
IInternalContest is implemented by the InternalContest class.
This interface defines methods to store and retrieve information from disk.
TBD add extending class names
There are PC2 List classes that were designed to manage/fetch certain files/data. Another List class is RunFilesList.
On the Server these classes are responsible for storing their namesake classes. On the Server the requirement is to store and get the classes without caching any of the classes.
Rationale: reduce memory usage for certain classes to avoid running out of memory due to large numbers of those classed created during the contest. An implication is that the classes would be rarely used, thus not needing the speed of a cached copy.
On the client (Judge/Admin) they are used to store a single class instance (cached in memory). The List class will store a single class instance and when a new class instance is added it replaces the existing instance.
Rationale: reduce memory usage and for security reasons keep only one instance of the classes. Since a single RunFiles or RunResultFiles would be on the Judge/Admin for a particular (checked out) run if a new run is checked out then those files are replaced with the new run's instances.
The boolean writeToDisk field controls whether instance are cached or not; the boolean is assigned in the respective constructors.
List classes:
- RunResultFilesList
- RunFilesList
These lists actually cache all instances (Runs, Clars) etc. on the Judge:
- ClarificationList
- RunList
