1. Central Online Grading System COGS Dec15-21 dec1521.sd.ece.iastate.edu

2. Problem Statement ●Cpr E 185 has weekly programming practices ●Blackboard is a frustrating interface o Cannot display.c or.txt files o Downloading, compiling, and running student code is tedious

3. Solution Overview The goal of COGS: Streamline the grading process ●Features o Intuitive Assignment creation o Easy student submission o Secure compiler o Automatic testing o Cheating detection o Streamlined grading o Blackboard Integration

4. Conceptual Sketch

5. Resources and Risks ●Resources: o Virtual Machine Server ●Risks: o Security o Hosting student data o Blackboard interfacing

6. Project Divisions ●Web Team o Zend Framework o User Interface o Blackboard Interfacing o Database Communication o Members  Forrest Scott  Katie Widen  Daniel McDonough ●Systems Team o Grader o Authentication/Security o Cheating Detection o Members  Zachary Lones  Daniel Riechers

7. Detailed Design - Front End ●Zend Framework o Open Source o Object Oriented o MVC structure o Modular o Secure o High Performance

8. Detailed Design - Front End Complex Diagram Simplified

9. Detailed Design - Front End ●Zend Autoloader o Resource Loading o Object Building o Security o Configurable Routes

10. Detailed Design - Front End ●Zend Controllers o M-V-C o The “Brains” of the Front End o Communicates with Back End o Forms, Plugins, Modules

11. Detailed Design - Front End ●Doctrine 2 Database o M-V-C o MySQL o Object Oriented o Lazy loading o Custom Macros o Auto Hydration

12. Detailed Design - Front End ●ZendFramework Views o M-V-C o PHP + HTML o Final Stage

13. Detailed Design - Grading Complex Diagram Simplified

14. Detailed Design - Grading ●Student Submits o Custom execution inputs o Back end runs o Returns errors, outputs o Last submission is used

15. Detailed Design - Grading ●T.A. Grading o Streamlined grading pages o Can create new execution o Alerts when cheating detected o Notes viewable by students o Upload to Blackboard via.csv file

16. 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

17. Detailed Design - Chroot Filesystem ●Adds level of system protection ●Prevents student software from interacting with the filesystem. o Changing system configuration o Installing Malware o Gathering system information

18. Mandatory Access Control (MAC) ●Forces permissions o Permissions limit user access to  Files  System Calls ● Devices ● Shared Resources ● Network ●We used SELinux for MAC o SELinux is an implementation of MAC by NSA

19. Detailed Design - SELinux ●Policy is transparent to administrators. o Policy should not limit administration o Policy should not need modification ●Policy is extra strict on student code executions. o System calls are whitelisted ●SELinux Aware Firewall o Further limits network traffic

20. Front End Requirements ●Administration (Add/Remove/Edit) o Classes o Instructors ●Instructors (Add/Remove/Edit) o Assignments o Students o Submission Scores ●Students o Upload Assignments o Check Results

21. Back End: Grader Requirements ●Preliminary Report o Shows compiler errors and warnings o Includes students custom inputs and resulting outputs o Shows results of unit tests ●Final Report o Everything in Preliminary Report of final submission o Include additional tests and static analysis o Returned to student after Instructor has written grades and comments

22. 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.

23. 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

24. 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

25. 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

26. 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

27. Test Plan - Backend ●All backend modules (Grader, Cheating detection) are unit tested with Google Tests. ●The SELinux Policy and security encapsulation are tested manually.

28. Current status and Future Plans Current Status

29. Questions?