University of Sydney: Unit of Study Feedback System Project Proposal

This document outlines a project proposal for a Unit of Study Feedback System, designed to assist students at the University of Sydney's School of IT in selecting courses. The system will be a web application built using the Spring framework and MVC architecture. The solution details the system architecture, leveraging JSF for the presentation tier, Spring for the business logic tier, and Hibernate for data persistence. It describes the key entities, including STUDENT, COURSE, and PROFESSOR, and the associative entities that manage many-to-many relationships. The system aims to provide a platform for students and faculty to share feedback, aiding in course selection based on prerequisites and student reviews. The project is divided into five packages: Common, Model, Persistence, Presentation, and Service, each responsible for specific functionalities within the application. The system's ER model is also detailed, showcasing the relationships between various entities within the system. The project seeks to improve the decision-making capabilities of enrolled students and provide a real-time communication space for the School of IT.

System architecture
The JSF and MVC (Presentation Tier) – The java server faces adjust well with the
presentation tier architecture of MVC. JSF offers a simple as well as clean demarcation
between the presentation and behaviour. It pulls a familiar UI component as well as the web
tier concepts without actually being limited a specific scripting or mark-up language. Also,
JSF backing beans are typically at the model layer. The consists of actions that are an
extension towards controller layer and also are responsible for assigning tasks to the logic tier
of business.
The Spring Framework (Business logic tier) – The business objects as well as the services
exists inside the business logic tier. A business object would typically contain both the logic
for the specific object as well as the data. There are over three different types of business
objects that has been identified and they include sample application, the user category and the
product category. A typical business interface layer needs to be always defined which will
then contain the service level interface for the end-user to be using it directly. By leveraging
the spring framework, the business logic tier shall be implemented by POJO. Spring would
also be based on the inversion of IOC or the control.
Hibernate is overall significantly less invasive in comparison to other o/r based mapping
frameworks. At the same time, the runtime byte code generation as well as the reflection shall
be used. The SQL generation happens during the start-up of the system. It typically allows
one to develop persistent based objects that is followed by java idioms including the

inheritance, association, java collection framework, the polymorphisms as well as the
composition. The business objects are simply based on POJO and doesn’t need a hibernate-
specific based interface.
The application would be divided into 5 different projects: Persistence, Service, Common,
Model as well as Presentation.
 Common package – The package would include utilities as well as service, that are
being used by other projects.
 Model package – The package is responsible for holding the customer’s book, the
details of the book, the login, the password and username as well as other criteria.
 Persistence package – This particular package would hold the database access object
which means it would interact via hibernate with database. It would contain the class
of implementation corresponding to DAO objects.
 Presentation package – This would contain the controller which is meant to be aligned
with events as well as elements of the package.
 Service package – It might contain services which would contain all the essential
business logic as well as interaction with DAO based objects.
ER model

The proposed system has following key entities:
 STUDENT
 COURSE
 FEEDBACK
 PROFESSOR
 SEMESTER
 SUBJECT
 UNIT
 MENTOR
 PROFESSOR
 TUTOR
There are associative entities which resolve the many-to-many relationship between the
entities:
 COURSE_PROF – It is an associative entity between Course, Professor and student.
 STUDENT_TUTOR - It is an associative entity between Student and Tutor.
 STUDENT_MENTOR - It is an associative entity between Student and Mentor.