One of the most common questions that staff at universities receive is: "Can I take this particular unit of study?". Staff must then individually examine the student's credit units and deliver a verdict, a process which is often prone to error and prompts multiple follow up queries from students. This strain on universities builds as the possible combinations of units that students take increases throughout the duration of their degree, adding undue costs to administration.

Current methods to view course requirements are incredibly cumbersome, requiring navigation of to up to 10 unique subpages and links from the portal homepage to identify course requirements. The information available is also not personalised to individual students and only identifies units which are immediate pre-requisites. These pre-requisites themselves may hold other pre-requisites, not viewable on the page.

Course Viewer came about as a way to reduce this frustration, providing a neat visualisation which allows students to map out a pathway for further study.

What it does

Course Viewer is a web app that visualises the courses that a student has taken and provides a graphical way to identify the pre-requisites required for courses at university. It identifies what courses a student has done in the past as well as what a student can do currently, given the units it has already taken. The web app is also able to identify what units a student may do eventually if they are able to satisfy intermediate pre-requisite courses that they have not currently completed. Essentially, this is able to identify what options are still available for students to undertake further studies.

This visualisation is also supported by links on the web-app which allow students to query whether they can take specific units by typing in its respective unit code. It is able to answer common questions such as "What units can I take?" and "What other units do I need to take in order to be eligible for X?".

How we built it

The relationships between courses can be represented as a directed acyclic graph; for example, if A is a prerequisite for B, we can draw a graph with an arrow going from A to B. However, course dependencies are often much more complicated than this; for example the prerequisite for course A might be ((B and C) or (D or E)), which can't be captured in a simple DAG. Our product displays the information to the user in a visual manner, so they can make better decisions about what courses to take.

The key data structure behind our web app is a directed acyclic graph that is able to capture complex Boolean expressions for its dependencies. Regular graph search techniques don't work well for this data structure, since the next step in the "search" depends on the nodes that have already been marked as "completed". Instead, we have used a new technique which stores the dependencies between the nodes and figures out which nodes to visit based on this information.

This data structure is able to figure out complicated dependencies between courses; for example, in the above example, course A has the prerequisites((B and C) or D or E). If the user specifies that they want to take course A and they have already taken course B, the data structure can calculate that the student only needs to take (C or D or E), because completing just C alone is now enough to satisfy the condition of (B and C).

Each of these queries takes O(nm) time, where n is the number of courses in the list of prerequisites, and m is the number maximum of units that rely on any of these prerequisites, either directly or indirectly. We assume that both of these are extremely small (both less than 10 in most use cases), making this data structure extremely fast and scalable.

Challenges we ran into

Web scraping the data from the university’s database was challenging as the information required to determine prerequisites was difficult to find and often presented in a manner that was inconsistent to other units. However, we were able to overcome this programmatically by using regex to distinguish course codes from HTML and JavaScript source code. The nature of prerequisites was also difficult to interpret as these were often written in the form of “(X or Y) and Z” or “(X or Y) and (Z or A)”. This was overcome by parsing this information through regex to identify unit codes and conjunctive statements, then constructing a parse tree to represent these associations. Communicating this information to the front-end web app also proved difficult due to the nature of the data and this required re-interpretation of the parse tree into a visual format.

Accomplishments that we're proud of

Constructing a suitable algorithm to be able to interpret the natural language written on the university’s portal is an achievement that we are incredibly proud of as this proved to be a major hurdle in the implementation of our program.

What's next for Course Viewer

Our application is highly flexible. The backend support for visualising courses of other universities besides the University of Sydney is available and updates are coming to allow this to be visualised in the web app. There are also plans to extend the program to identify whether a student is eligible to graduate, and if not, the subjects they are required to take in order to finish their degrees. There are also plans to provide support display the years and semesters which the subjects are offered in, and the available class times. If this feature is implemented, we can create personalised draft timetable system where students can select the subjects they wish to take and make their future timetables (currently at the University of Sydney, students are required to do this manually by using Excel and checking all available times for each unit they wish to take).

Built With

Share this project: