Home

Welcome to the AutomatedJudgeSystem wiki!

Introduction

Team Members

• Isa Abdul-Hamid
• Andre Benjamin
• Anwar Khayyam
• Alejandro Marin
• Elijah Sinclair

Project Scope

Our team intends to develop an automated judge system for evaluating assignments submitted in Object Oriented Programming 1. The system shall:

• Accept a zip file containing zero or more student submissions as zipped files.
• Extract and process zero or more Java files in a student submission.
• Accept, reject, or penalise improperly named submissions in accordance with the assignment specification.
• Evaluate all of the required features of the Java classes based on a given assignment specification.
• For each student, calculate an overall score, generate feedback, and produce a PDF report on this into the submission folder.
• Require the intervention of a course marker to source and select the zip file containing student submissions. This allows the marker to apply any unwritten or external policy on their selection as they deem necessary.
• Evaluate all submissions within the zip file equally. The responsibility to penalise or reject individual assignments based on course policies independent of the assignment specification (such as late submission policies) rests on the course marker.
• Calculate and report on class performance statistics based on the selected zip file.

Purpose

The purpose of the project is to automatically mark Object-Oriented Programming 1 assignments.

Analysis

Major Requirements

• Read and extract student submissions
• Create/Read assignment specification
• Test student submissions
• Generate individual reports of student submissions including information such as: grade, score and details relating to where they lost marks.
• Generate class report with summary of each student's ID number and grade.

Use Cases

• Extract student submissions to project directory
• Create assignment specification
• Read assignment specification
• Create test cases
• View individual results
• View Class results

Target Students

• Students that have submitted assignments. Those who have not submitted are not included in our scope.

Design

Design Patterns Used

• Builder design pattern https://refactoring.guru/design-patterns/builder The specBuilder acts as a builder to create different variations of assignment specifications based on what the user needs to be created and the properties associated with the classes and interfaces they want created.
• Iterator design pattern
  • TestableIterator is the abstract iterator
  • TestableContainer is the abstract Aggregate
  • AssignmentSpec is the concrete aggregate for the TestableContainer
  • AssignmentItemIterator is the concrete aggregate for the TestableIterator
  • The purpose of the iterator pattern in this design was because there were multiple classes that needed to iterate through the files so that abstraction allowed them to be decoupled from the physical implementation of the classes.
• Composite design pattern incomplete
  • Testable is the component interface
  • The intention was for AssignmentJava is the composite which implements Testable
  • AssignmentProperty is the leaf that implements Testable. AssignmentProperty is also an abstract class so all the classes that extend AssignmentProperty: AssignmentAttribute, AssignmentClass, AssignmentConstructor, AssignmentMethod are also leaves of the Testable interface

Conformance to SOLID Principles

FileExtraction

Single Responsibility Principle

All classes uphold the single responsibility principle except for the ZipExtractor. Although it's general purpose was to read the single zip file of submissions, the process that it reads submissions involves multiple smaller methods which would not make sense to have as separate objects since it would simply be unnecessary abstraction.

Open/Closed Principle

The existence of the FileFilter interface and FileExtractor interface allows for different types of files to be filtered as well as different types of files to be extracted.

Liskov Substitution Principle

this.zipFileFilter = new ZipFileFilter();  
this.studentZipExtractor = new ZipFileExtractor(new JavaFileFilter(), bufferSize);

The code snippet from the ZipExtractor class shows a violation of the Liskov Substitution principle. The reason why the principle was not upheld was because if we were to program to the interface instead of the subclass, it would create a long parameter code smell.

Interface Segregation Principle

The interface segregation principle is upheld as there are no methods in any of the implementations that are empty or do not have relevant code.

Dependency Inversion Principle

This was not upheld since the ZipFileFilter and JavaFileFilter was instantiated in the ZipExtractor class. Due to Dependency Inversion being related to Liskov Substitution

TestCreation Done by Elijah Sinclair

Single Responsibility Principle

All classes adhere to this principle, except the AssignmentAttribute, AssignmentConstructor and AssignmentMethod classes, since within those classes, there are methods to both add data to the appropriate fields of the class object as well as to generate tests on that object. This test generation should have had its own class as a collection of all the tests that could be generated between the different types, that is, attribute, constructor and method.

Open/Closed Principle

The code adheres to this principle, since each test is knit together around its appropriate testable data, so theoretically to create a new testable feature, a new class should be created for it here, like the AssignmentAttribute, AssignmentConstructor and AssignmentMethod classes.

Liskov Substitution Principle

There are no noticeable violations of this principle, therefore this principle is adhered to.

Interface Segregation Principle

This principle is adhered to throughout this folder. The interfaces possess only the relevant methods.

Dependency Inversion Principle

This principle does not have any apparent instance of violation within this group of classes.

GUI Done by Elijah Sinclair

Single Responsibility Principle

Each class, is responsible for the appropriate stage, hence all the functionality of a particular scene is stored in its controller class, this means that while from an overall GUI perspective each class handles the functionality of its scene, from the class/code perspective it does not conform to this principle

Open/Closed Principle

This principle is not adhered to since, to create a new scene you must add a new scene with its appropriate controller, and then link that scene within the controller of another scene, since the scene would be otherwise inaccessible. Therefore you must modify to extend.

Liskov Substitution Principle

Since the GUI utilizes JavaFX and its classes, this principle is not noticeably violated.

Interface Segregation Principle

There are no interfaces used in this code section, hence this principle is invalid here

Dependency Inversion Principle

There are no applicable instances within the application  code to state whether this principle has been violated.

Views Done by Elijah Sinclair

Single Responsibility Principle

While PDFReport and ReportGenerator adhere to this principle, the GUI class does not adhere to this principle, since it both creates the visual GUI and handles the data on actionEvents in one class. Although due to the nature of this GUI and its creation in NetBeans this may be an excusable instance of violation.

Open/Closed Principle

Due to the nature of the GUI and its creation in NetBeans, this principle is violated since the GUI would need to be modified directly to change how it looks and to add more functionality to the Event Triggers.

Liskov Substitution Principle

There are no violations to this principle.

Interface Segregation Principle

There are no noticeable violations to this principle in this folder due to the only interface here being used for its single method.

Dependency Inversion Principle

There are no violations to this principle.

Class Diagram

!Pasted image 20241121180439.png This UML diagram was our original idea of how the project would be completed. This was an initial design and the code has deviated slightly from this but shows the original ideas and patterns that were intended to be used in the project. This was used as a strong base to build off of and is still relevant to what we have as our final product. The Graphical user interface was not included in the UML design.

!Pasted image 20241121193952.png This is the up to date UML diagram which was generated by Intellij IDEA a JetBrains product.

Implementation

How to run

Run project with mvn clean javafx:run

Setup Requirements

• None

Testing and Evaluation

Test Cases and Suites

No maven tests for the project were created.

Demo Link Video

https://youtu.be/LGAqu6pGgHM