The Model is an abstract set of interfaces that encapsulate any code in the system that could possibly have multiple realisations. The Model is split into a set of discrete components, each with its own factory for generating classes supporting the defined interfaces. The discrete components currently in the Model are the auto assignment algorithms, the database access objects, sending mail, session authentication, the testing framework, and administrative operations.
factories.propertiesfile and using introspection.
Factories derive from the
Factory interface, which requires
methods for Factories to explain which configuration options they require,
and these are used for automatic configuration the first time BOSS2
Auto assignment algorithms are responsible for assigning markers to students automatically. The Factory provides methods to query what algorithms are available and their class names. The implementing classes themselves provide a single method that takes a list of markers, a list of students, and returns a map of markers to the students that they will mark.
|Auto Assignment Algorithms||uk.ac.warwick.dcs.boss.model.autoassignment||AutoAssignmentMethodFactory|
Data access objects are responsible for brokering persistent storage.
The model defines a set of beans that may be stored in the
database. and a set of query results that are returned by DAOs
tailored for Student, Staff, Marker and Admin operations. The Factory
provides methods to initialise storage, begin/end/abort transactions,
and obtain objects to broker these beans with the storage. Brokerage is
done by a persistent identifier (which is a
|Data Access Objects||uk.ac.warwick.dcs.boss.model.dao||DAOFactory|
|Assignment||An assignment||Module, Person, Resource||DAO provides access to markers|
|DeadlineRevision||A deadline revision||Assignment, Person|
|Entity||Generic entity in the database||No DAO, used internally|
|Mark||A mark||MarkingAssignment, Person|
|MarkingAssignment||A binding of student to marker||Assignment, Person|
|MarkingCategory||A marking category||Assignment|
|Model||A model||Top level entity in the model tree|
|Module||A module||Model, Person||DAO provides access to students and administrators|
|Person||A user of the BOSS2 system||Unique identifier doubles up as username|
|Resource||A stored resource (file)||DAO provides access to data via streams|
|Result||A published result||Assignment, Person|
|Submission||A submission||Assignment, Person, Resource|
|Test||A test||Assignment, Resource||DAO provides access to parameters|
|IAdminInterfaceQueriesDAO||Fetching models to administrate||AdminModelsQueryResult||Aministrator 'model management' page|
|IAdminInterfaceQueriesDAO||Fetching modules for a model||AdminModulesQueryResult||Administrator 'module management' page|
|IMarkerInterfaceQueriesDAO||Fetching assignments to mark||MarkerAssignmentsQueryResult||Marker 'assignments to mark' page|
|IMarkerInterfaceQueriesDAO||Fetching marks for a marking assignment||MarkerMarksQueryResult||Marker 'marks for a student' page|
|IMarkerInterfaceQueriesDAO||Fetching students to mark for an assignment||MarkerStudentsQueryResult||Marker 'students to mark' page|
|IMarkerInterfaceQueriesDAO||Fetching submissions by a student for an assignment||MarkerSubmissionsQueryResult||Marker 'submissions by student' page|
|IStaffInterfaceQueriesDAO||Fetching assignments for a module||StaffAssignmentsQueryResult||Staff 'assignments' page|
|IStaffInterfaceQueriesDAO||Fetching deadline revisiosn for an assignment||StaffDeadlineRevisionsQueryResult||Staff 'deadline revisions' page|
|IStaffInterfaceQueriesDAO||Fetching marking assignments for an assignment||StaffMarkingAssignmentsQueryResult||Staff 'marking assignments' page|
|IStaffInterfaceQueriesDAO||Fetching modules to adminsitrate||StaffModulesQueryResult||Staff 'modules' page|
|IStaffInterfaceQueriesDAO||Fetching results for an assignment||StaffResultsQueryResult||Staff 'results' page|
|IStaffInterfaceQueriesDAO||Fetching submissions for an asignment||StaffSubmissionsQueryResult||Staff 'submissions' page|
|IStudentInterfaceQueriesDAO||Fetching assignments to submit or details for an assignment||StudentAssignmentsQueryResult||Multiple student pages|
|IStudentInterfaceQueriesDAO||Fetching modules that have assignments to submit to||StudentModulesQueryResult||Student 'modules' page|
|IStudentInterfaceQueriesDAO||Fetching assignments you have previously submitted to||StudentSubmissionCountsQueryResult||Student 'previous submissions' page|
|IStudentInterfaceQueriesDAO||Fetching submissions previously submitted to an assignment||StudentSubmissionsQueryResult||Student 'submissions for assignment' page|
Mail sending is used for communicating with students, typically via email (although IM could easily be used instead). The Factory provides a method to get an object that can send mails. Mails have a recipient, a subject, and a message and are sent asynchronously.
The Factory provides a method to get an object that can authenticate users or change their authentication credentials. A successful login generates a session which contains the Person that logged in, a preferred locale (currently unused), future test results, and an arbitrary session memory.
Note: Future test results should be moved out of the session and into the testing framework at some point.
The testing framework is responsible for running tests on the submissions.
The test runner is responsible for queuing tests given a
submission and a test. It is responsible for unpacking the submission
and test resources, running the test executor and feeding the results
into the test method.
The test runner returns Future TestResult objects for accessing
test results when they are complete, and
TestRunnerFactory provides a method to generate an object that
can queue tests given a submission and a test.
NOTE: Future test results are currently stored in the session by the controller. This is bad, and the Test Runner really should handle this.
A test method takes an
ExecutionResult object and
TestMethodFactory provides methods to query which test methods
are available and their class names.
A test executor takes a submission directory, a test resource
directory, and a command to run and generates an
TestExecutorFactory provides methods to query which test
executors are available and their class names.
An administration operation takes parameters and performs some form
of operation, returning an
AdminUtilityFactory provides methods to query which operations
are available and their class names.