View
222
Download
0
Category
Tags:
Preview:
Citation preview
Central Online Grading SystemCOGS
Dec15-21
dec1521.sd.ece.iastate.edu
Problem Statement
● Cpr E 185 has weekly programming practices● Blackboard is a frustrating interface
o Cannot display .c or .txt fileso Downloading, compiling, and running student code is
tedious
Solution Overview
The goal of COGS: Streamline the grading process● Features
o Intuitive Assignment creationo Easy student submissiono Secure compilero Automatic testingo Cheating detectiono Streamlined gradingo Blackboard Integration
Conceptual Sketch
Resources and Risks
● Resources:o Virtual Machine Server
● Risks:o Securityo Hosting student datao Blackboard interfacing
Project Divisions
● Web Teamo Zend Frameworko User Interfaceo Blackboard Interfacingo Database Communicationo Members
Forrest Scott Katie Widen Daniel McDonough
● Systems Teamo Gradero Authentication/Securityo Cheating Detectiono Members
Zachary Lones Daniel Riechers
Detailed Design - Front End
● Zend Frameworko Open Sourceo Object Orientedo MVC structureo Modularo Secureo High Performance
Detailed Design - Front End
Complex Diagram
Sim
plified
Detailed Design - Front End
● Zend Autoloadero Resource Loadingo Object Buildingo Securityo Configurable Routes
Detailed Design - Front End
● Zend Controllerso M-V-Co The “Brains” of the Front Endo Communicates with Back Endo Forms, Plugins, Modules
Detailed Design - Front End
● Doctrine 2 Databaseo M-V-Co MySQLo Object Orientedo Lazy loadingo Custom Macroso Auto Hydration
Detailed Design - Front End
● ZendFramework Viewso M-V-Co PHP + HTMLo Final Stage
Detailed Design - Grading
Complex DiagramSimplified
Detailed Design - Grading
● Student Submitso Custom execution inputso Back end runso Returns errors, outputso Last submission is used
Detailed Design - Grading
● T.A. Gradingo Streamlined grading pageso Can create new executiono Alerts when cheating
detectedo Notes viewable by studentso Upload to Blackboard
via .csv file
Detailed Design - Security
● Prevents stalled code using timers● All student code is run in a chrooted environment
o Minimal filesystem● The system uses a Mandatory Access Control policy
o Transparent to administrators
Detailed Design - Chroot Filesystem
● Adds level of system protection● Prevents student software from
interacting with the filesystem.o Changing system
configurationo Installing Malwareo Gathering system
information
Mandatory Access Control (MAC)
● Forces permissionso Permissions limit user access to
Files System Calls
● Devices● Shared Resources● Network
● We used SELinux for MACo SELinux is an implementation of MAC by NSA
Detailed Design - SELinux
● Policy is transparent to administrators.o Policy should not limit
administrationo Policy should not need
modification● Policy is extra strict on student code
executions.o System calls are whitelisted
● SELinux Aware Firewallo Further limits network traffic
Front End Requirements
● Administration (Add/Remove/Edit) o Classeso Instructors
● Instructors (Add/Remove/Edit)o Assignmentso Studentso Submission Scores
● Students o Upload Assignmentso Check Results
Back End: Grader Requirements
● Preliminary Reporto Shows compiler errors and warningso Includes students custom inputs and resulting outputso Shows results of unit tests
● Final Report o Everything in Preliminary Report of final submissiono Include additional tests and static analysiso Returned to student after Instructor has written grades
and comments
Back End: Cheating Detector Requirements
● Cheating Report○ Displays code similarities across submissions○ Generates a cheating confidence score
● Run cheating detection algorithm on students’ final submissions
● Report is viewable by Instructors if cheating is detected.
Security Requirements
● Use Mandatory Access Control to encapsulate student code.● Use a chroot environment to encapsulate student code.● Use a firewall that restricts unauthorized network
communication● The student code will be allowed to execute the following
system calls:○ read ○ close○ write ○ open○ create
Integration Requirements
● Web server executes the grader● Grader returns its output to the web server via stdout● Web server stores grader results in database● Blackboard integration is handled manually via .csv
Non-functional Requirements
● Streamline the process: make grading as intuitive as possible
● Mandatory Access Control will be transparent to system administrators
● All external dependencies will be verified to be secure and reliable
o Shibboleth
o Zend plugins
o Runtime libraries
● Maintainable
● Extreme care taken when handling student information
Test Plan - Front End
● Manual testing for individual components● Alpha testing using a small group of students and single
instructor● Beta testing using a larger volume of students and
multiple instructors
Test Plan - Backend
● All backend modules (Grader, Cheating detection) are unit tested with Google Tests.
● The SELinux Policy and security encapsulation are tested manually.
Current status and Future Plans
Current Status
Questions?
Recommended