FYDP – Course Audit

FYDP – Course Audit


Project Description

DegreeAudit is a liberator that frees academic advisers from hours of tedious manual work determining if a student can graduate within seconds. It is a web-based utility that allows advisers to specify graduation requirements in an easy fashion – they only have to load the student JSON transcripts to receive a fast and accurate response about the student’s graduation status.

DegreeAudit is currently still a work in progress for a projected completion data by April 2016.

 

BehaviourDiagram

Explanation of Design

● What are the components? Transcript(JSON files); Transcript parser; Table for storing global course definition; (Generated) Alloy files along with its solver(unSAT core); Alloy outcome; Newly designed formal language; Formal language parser; ANTLR parser; Code Generator(to Alloy); SQL generator; Human readable Calendar; Pretty printer

● What libraries and tools are used? Java: Alloy, Antlr, JUnit 4.11

● How are they arranged? Refer to Behaviour Diagram

● Any noteworthy uses of architectural styles or design patterns? Visitor pattern: use it to be able to generate code that is human readable and code that is inline and find where the user failed, documentation for senate approval. The visitor pattern is used in ANTLR to pass the parse tree. Fitness for Purpose

● A rationale for why this design meets the specification. The specification of our design is to make a degree audit system that is flexible enough to meet most degree requirements. In order to achieve our specification we need to solve for a NP­complete problem.

● Why is this design better than reasonable alternatives? This problem is NP­Complete so the best way to solve it should be using SAT solver (i.e. Alloy). Also, Alloy provides Java API that can be utilized in our Java project.

● If the project is in a novel domain or has a novel solution strategy, why is the proposed design a good match? Our project does not have a novel domain or a novel solution strategy.

○ Why is visitor best? In code generator/pretty printer (tree traversal), we want to test for more grammars (operations) to see if all of them work for parsing. Currently we only have one file (class) to store all possible grammars so we do not require for the ability to modify the class itself. Visitor pattern can provide the extensibility of more grammars instead of changing the parser class. In this case we require for an uniform interface for all operators.

○ Why don’t we have other alternatives? We did not choose any other alternatives such as computing the problem within Java (or other popular programming language) because the problem could be categorized as SAT problem and Alloy is the only SAT solver that properly fit the requirement of our project ­ Alloy has API to be utilized in Java. Fitness for Future

● What are the anticipated kinds of change, growth, or variability in the domain? Anticipated kinds of change in the future would be addition to the language domain. In the future there may be new requirements that needs to be represented in the language. Designing our own language tree allows for the expansibility for new symbols and expressions. This also allows for variability in degree audits as well as if there needs to be changes to old plans. Allowing for change is very important as graduating stands tend to change over the years.

● Does the design facilitate managing that change in a modular fashion? Yes. The visitor pattern is good for adding more grammars to the current language and parser. Any changes from visitor pattern, the trees, will not affect any other modules/components. In the future, we will expand the language that will be translated from by the desugar and avoid changing the code generator.

● What are core assumptions that cannot be changed?

1. The failed courses should never be counted as credited course. That is to say, when we doing course parsing, all failed courses will be ignored

2. Advisors should have the ability to learn our newly designed formal language,

3. Advisors has the authorization to make an override.

4. That the University of Waterloo is willing to adapt to a technology designed by students