Architecture and Component Diagrams
In this page, you will find NUS Oracle's architecture diagram and component diagrams. The architecture diagrams will give you a large overview of how the database, business logic and web framework are designed. The component diagrams in the next section of this page will then allow you to zoom into the functionalities of each component.
Our application uses Meteor + ReactJS framework which has a Minimongo client-side database and a MongoDB server-side database.
- The components with no fill refer to the UI templates written in React Javascript.
- The red components refer to components that utilize Meteor Javascript functions.
- The blue components represent our business-side application logic that is independent of the Meteor framework written in pure Javascript.
- The black components represent our external logic that may be written in a coding language besides Javascript.
This is UI's component hierarchy diagram. Our Student View component manages the entire front-end of NUS Oracle and we made it using the ReactJS library. If you are a seasoned ReactJS developer, you will be able to find this simple component hierarchy diagram useful for getting an understanding of how the React components were organized.
This is the App component of the UI Student View. It is the main view where students will access after they log into the system and contains the greatest number of component in UI. If you are a seasoned ReactJS developer, you will be able to find this simple component hierarchy diagram useful for getting an understanding of how the React components were organized.
This component manages the user accounts in NUS Oracle. It handles validation of user information and communicates with the database to store user account information.
This is the brain of NUS Oracle - it manages all the logical functions of NUS Oracle, as specified in the Functional Requirements. Basic CRUD functions are handled by Meteor functions, while all module searches, module validity, graduation checks and recommendations are powered by our student application logic that is independent of the Meteor framework.
The status of whether a student is able to graduate or not is validated in this component. Here, we will check for foundation, IT-professionalism, Math-science, Industrial Experience, Team-project, focus area, UE and university requirements with our graduation checker logic and the information from the database.
Since our database contains many different kinds of student/module/study plan data and will inevitably handle many different types of requests, we have further decomposed our database component into sub-components that will handle the different data formats.
This component is reserved for us to handle parsing the data from external sources into the format that we are storing in. This includes parsing the JSON files from locations such as NUSMods and the Computer science website.
