Software Design Specification
| Authors | Key |
|---|---|
| Ryan Gurnick | rg |
| Joseph Goh | jg |
| Samuel Lundquist | sl |
| Mason Sayyadi | ms |
| Owen McEvoy | om |
5. Operational Scenarios (Use Cases)
- Case A: First meeting
- Case B: Importing new course history information
- Case C: Viewing major/degree progress and potential roadmaps
| Date | Author | Description |
|---|---|---|
| 02/13/2020 | sl | Initial SDS Template |
| 02/13/2020 | sl | SDS Rough Draft |
| 02/14/2020 | jg | Updated formatting, Migrated software module descriptions to the appropriate section, added basic acknowledgements, added brief rough draft of software architecture section |
| 02/14/2020 | rg | moving changes over from gd |
| 02/18/2020 | jg | Added to overall design rationale section |
| 02/19/2020 | rg | Adding to operational scenarios |
| 02/20/2020 | om | Adding design rationale to software modules |
| 02/20/2020 | ms | Adding operation use cases |
| 02/20/2020 | sl | Updated software architecture section |
| 02/27/2020 | jg | Updating document based on new focus for advisers as users and related feature/design choices |
| 02/28/2020 | jg | Unified spelling of the word 'adviser' across documents |
| 02/28/2020 | jg | Updated software architecture and use case A diagrams |
| 03/05/2020 | jg | Updated software module and use case listings as well as updating and replacing all use case diagrams |
| 03/07/2020 | jg | All mentions of regTools changed to Registration Tools |
| 03/07/2020 | jg | Added static UML class models for Class and Status Data Store and Class Web Scraper modules |
| 03/08/2020 | jg | Added acknowledgements regarding referencing previous group docs |
| 03/08/2020 | jg | Added a markdown table of contents because why not |
This project is designed to be a class registration and planning assistant primarily for use by University of Oregon advisers.
It provides useful information to the adviser and students being advised about which classes are available and which classes the student should take in order to make progress towards graduation.
Advisers will also be able to easily structure potential course roadmaps for students' college careers based on major degree requirements and the student's course history.
Advisers will also be able to save and manage such information for multiple students for future use.
The system will provide course information by web scraping data from classes.uoregon.edu and manage all its data in a local database.
Figure 3.1.1 Software Architecture Diagram
Below is the set of components as well as a brief description of their function and interactions with other components:
Class Web Scraper: Accesses classes.uoregon.edu to collect information regarding classes offered and the related metadata for the class offering.
- Interaction: This module can be manually activated by the user from the Collect Data Menu in order to fetch the latest catalog of courses. Once activated, it retrieves class information from the publicly displayed course listings on the University of Oregon classes website. Upon retrieval, this module will send updated class information to the Class and Status Data Store module.
Class and Status Data Store: Database of courses and their additional information, student profiles containing individual course histories, and requirements for graduation.
- Interaction: This module receives data from the Class Web Scraper. This allows it to provide (and in turn receive) up-to-date data from the Adviser Interaction Center modules. The Adviser Interaction Center's Student Profile Management and Class Management modules can access the Class and Status Data Store to add or edit student profiles and course histories.
Adviser Interaction Center (UI): These modules together provide a graphically navigable interface to access and manipulate information provided by the system's other components.
-
Student Profile Selection: Interface for selecting and managing student profiles. Also serves as the welcome screen on program startup.
- Interaction: This module receives and updates the list of student profiles from the Class and Status Data Store.
-
Collect Data Menu: Interface from which the user may fetch class data, especially for new terms.
- Interaction: This module triggers collection of new class data by the Class Web Scraper.
-
Class Management: Interface for viewing an exhaustive list of courses by term and for updating the course history of a student.
- Interaction: This module will interact with the Class and Status Data Store, mainly to receive existing course histories of students as well as update that information.
-
Long Term Planning: Assesses and displays major and degree requirements to fulfill and also creates and shows long term roadmaps accordingly.
- Interaction: This module will interact with the Class and Status Data Store for degree requirements, additional information on courses that meet the wanted criteria for specific terms, and the student's current course history.
TODO: Review design rationale section for additions and improvements
Maintainability, more specifically changeability, is one advantage of defining a clear flow of data from the Class Web Scraper, to the Class and Status Data Store, and finally to the Adviser Interaction Center modules. For example, if a change to the way the system collects information from classes.uoregon.edu is required, that change can be made independently of other software components.
Similarly, changes in the Adviser Interaction Center modules do not require significant changes to existing functions of the Class and Status Data Store or Class Web Scraper modules.
Additionally, this design allows the system to have a degree of reliability and fault tolerance. Though the Adviser Interaction Center modules require information from the Class and Status Data Store and the Class and Status Data Store is dependent on data from the Class Web Scraper, if an issue in one of the modules cause a failure to provide up-to-date information, other modules can still operate using the existing database with outdated but otherwise valid information and logic.
TODO: Add diagrams and design descriptions to each module
Module's role and primary function
The purpose of this module is to allow the system to capture and parse class information from classes.uoregon.edu automatically en masse. This information not only includes term-specific course listings, but also additional data such as lecture/lab times, the instructor, a course summary, and general education requirement groupings.
Interface specification
This module will access the Class and Status Data Store directly to save the collected course data. The module will be triggered manually by the user through the Collect Data Menu module.
Static and dynamic models
Figure 4.1.1 Static UML class diagram for Class Web Scraper
Figure 4.1.2 Dynamic model placeholder for Class Web Scraper
Design rationale
A module designated for scraping class information is essential because this information is required by the system to accurately provide a student or adviser with scheduling solutions. Furthermore since the HTML structure of this website is unique, the parser used to scrape the majors requirements would not be applicable. This makes modifying the module easier in the event that the format of classes.uoregon.edu ever changes, without effecting the other modules.
Module's role and primary function
The purpose of the Class and Status Data Store is to store the relevant data pertaining to the classes the student being advised must take or desires to take. In addition to the class itself, this module stores the number of remaining spaces in the class, the time & date of the class, and the instructor of the class.
Interface specification
This module consistently receives fresh data from Information Accumulation Modules. This allows it to provide the data to the background notification system, in the event a previously full class now has an available spot. Furthermore, it provides the data used by the User Interaction Center modules.
Static and dynamic models
Figure 4.2.1 Static UML class diagram for Class and Status Data Store
Figure 4.2.2 Dynamic model placeholder for Class and Status Data Store
Design rationale
The data collected from the Information Accumulation Modules will be converted to JSON format and stored in a SQLite database. This enables the system to ensure that the data being stored is in a uniform format that other modules rely on. Additionally, the data is stored in a secure location to be reliably accessed by the other modules.
Module's role and primary function
TODO: Describe the module's purpose and function here
Interface specification
TODO: Describe the module's interactions and interfaces with other components here
Static and dynamic models
TODO: Add static and dynamic models of the component here
Figure 4.3.1 Static model placeholder for Student Profile Management module
Figure 4.3.2 Dynamic model placeholder for Student Profile Management module
Design rationale
TODO: Describe the above models and provide rationale here
Module's role and primary function
TODO: Describe the module's purpose and function here
Interface specification
TODO: Describe the module's interactions and interfaces with other components here
Static and dynamic models
TODO: Add static and dynamic models of the component here
Figure 4.3.3 Static model placeholder for Collect Data Menu
Figure 4.3.4 Dynamic model placeholder for Collect Data Menu
Design rationale
TODO: Describe the above models and provide rationale here
Module's role and primary function
TODO: Describe the module's purpose and function here
Interface specification
TODO: Describe the module's interactions and interfaces with other components here
Static and dynamic models
TODO: Add static and dynamic models of the component here
Figure 4.3.5 Static model placeholder for Class Management module
Figure 4.3.6 Dynamic model placeholder for Class Management module
Design rationale
TODO: Describe the above models and provide rationale here
Module's role and primary function
TODO: Describe the module's purpose and function here
Interface specification
TODO: Describe the module's interactions and interfaces with other components here
Static and dynamic models
TODO: Add static and dynamic models of the component here
Figure 4.3.7 Static model placeholder for Long Term Planning module
Figure 4.3.8 Dynamic model placeholder for Long Term Planning module
Design rationale
TODO: Describe the above models and provide rationale here
TODO: Update all use case descriptions to match that of SRS.
TODO: Change use case content to provide insight into software design
Figure 5.1 Dynamic flowchart diagram of Case A grouped by modules
Actor: Student
Brief Description: A University of Oregon adviser or student has downloaded the Registration Tools application to their computer and launches it for the first time.
Preconditions: A University of Oregon student has logged into DuckWeb and has reviewed their degree guide (Student Menu > Degree Guide - Interactive > "Degree Guide" > Duck ID Login Page > Request Audit > Run Degree Audit > View Audit).
- The student will launch Registration Tools for the first time and be greeted by a welcome display.
- The user will be asked the first time to perform the initial information processing and scraping from classes.uoregon.edu to collect a database.
- If a database is already present with the installation then the user will be able to optionally choose the prior one. (This is to prevent the need for an internet connection to run the application)
- The system will then ask for the student to input some information regarding their degree audit, this will aid in providing accurate information based on the students goals and completed course load.
- Registration Tools then processes all of this information, and then saves the students degree information as well as major/degree progress based on the selected course roadmap.
- The student will be able to continue utilizing the functionality of the application moving forward.
Postconditions: The student's data has been entered and processed by the application and the student has had the opportunity to re-generate the classes data (from classes.uoregon.edu) or use a predefined database. The student will be able to access the entire application after this case has completed.
Figure 5.2 Dynamic flowchart diagram of Case B grouped by modules
Actor: Student
Brief Description: This use case is intended for when the student has completed new courses to update the system, or inputting degree data the first time the system launches as well.
Preconditions: The student has finished new courses since first completing (Case A), and has a file or a previous degree course path that has been saved to the database.
- The student will launch Registration Tools for the first time and be greeted by a welcome display.
- The user selects the option to update their degree information by choosing a degree path to load into the system either via .txt file or via one of the saved database entries.
- The system displays a list of classes relevant to the user's loaded major(s) that will be visually displayed, and grouped by the class subject. Each class is going to be generated into a class hierarchy (where prerequisites and core classes rank as more important in the earlier stages).
- The user goes through each subject and marks the classes which they have completed by clicking on the buttons that are greyed out in order to select what they have completed.
- The system updates the course completion flags on each of the courses and re-calls the algorithm to check which classes are eligible to take.
- The system is now able to continue to use and update the information originally generated from (Case A), as well as load and override any previous saves with the current session.
Postconditions: The student's data is updated and stored as a JSON list into our local SQLite database that will be able to be reloaded upon any session on that machine.
Figure 5.3 Dynamic flowchart diagram of Case C grouped by modules
Actor: Student
Brief Description: This use case is meant to describe the process of viewing major/degree progress.
Preconditions: The student has an intended major with a regenerated degree path that’s been newly created or loaded into the system.
-
The user launches Registration Tools and clicks on the 'degree roadmap' button.
-
Upon loading the degree requirements, the system displays the conditions and prerequisites that the student has taken, as well as the conditions that are still required to be eligible for the remaining classes.
-
The user clicks on the 'create roadmap' button, and the system asks the user for a list of given constraints such as: term to graduate by, maximum number of major courses per term, cost per class, summer quarter inclusion.
-
The system uses algorithms to generate multiple graduation paths (roadmaps) for the student and displays them in the form of tables of classes that the user can interact with to check off. This is done in the form of buttons labeled with the class names that the class.
-
The student can choose and tailor their graduation path and add selected classes to the “watch list” so that the user can be notified later on.
Postconditions: The generated roadmaps are saved by the system in the form of a .JSON format into a SQLite database that can be loaded into the next session by the user. This information stays consistent until class information is updated or the user puts in different constraints to the road map.
Ryangurn. “ryangurn/group1.” GitHub, github.com/ryangurn/group1.
Sceotere. "sceotere/uoregon-cis422-p1." Github, github.com/sceotere/uoregon-cis422-p1.
This document is built directly upon a template provided by Anthony Hornof, produced by him in 2019. That template itself was built slightly on another document produced by Stuart Faulk in 2017 as well as other publications.
The documentation of Groups 1 (Ryangurn) and 3 (Sceotere) for project 1 of the 2020 winter term CIS 422 course at the University of Oregon were also referenced while writing this document.