CSC/ECE 517 Spring 2023 - E2337. Reimplement node hierarchy
Introduction
Packages of information are distributed based on the context that they are delivered. For courses, information and functionalities are packaged into Course nodes and team information is packaged into Team nodes. These nodes are supplemented by the base node class in order to inherit basic functionality/attributes such as the type of node, the parent id, identifying whether the node is a leaf or not, etc. This hierarchical structure allows for code reuse and custom implementations to exist alongside default implementations in order to keep functionalities modular and isolated, minimizing the risk of breakage.
Problem Statement
First off, the node models have a problem with repetition in two major areas. First off, Node.rb defines a bunch of functions to fetch a given property such as name, directory, creation_date, etc. These functions all fetch data from the same entity with the same filter parameters. Instead of having five functions, we can consolidate down to one function where a given parameter would be passed in. This parameter could specify which field we want to fetch on a given entity. For example, we could fetch the creation date of an entity by invoking a call like such: node.getProperty("creation_date"). The getProperty function would be responsible for parsing the parameter and determine which field needs to be returned back to the user.
Secondly, there are methods that are repetitive between assignment_node.rb and course_node.rb. In order to reduce repetition, the shared methods can be pulled out into a module, which then the two node models would import in order to use the methods. Some of these repetitive methods are get_instructor_id, retrieve_institution_id, get_private, etc.
Test Plan
Example of test cases added to test course_node
| Test No. | Description |
|---|---|
| 1 | Tests if a course node is saved with data |
| 2 | Tests when show and current user are set and you are not a TA |
| 3 | Tests that the table returns courses |
| 4 | Tests when show and current user are set and you are a TA |
| 5 | Tests that user id is returned when you are not a TA |
| 6 | Tests returning id of parent folder when parent is found |
| 7 | Tests returning nil when parent is not found |
| 8 | Tests returning assignment node when children are found |
| 9 | Tests whether the course returned is private |
| 10 | Tests that the course returns a survey distribution id |
Example of test cases added to test questionnaire_node
| Test No. | Description |
|---|---|
| 1 | Tests the questionnaire returns when the user is a teaching assistant |
| 2 | Tests the questionnaire returns when the user is not a teaching assistant |
| 3 | Tests the questionnaire returns with association with student when the user is not a teaching assistant and show is enabled |
| 4 | Tests the questionnaire returns with association with student when the user is a teaching assistant and show is enabled and parent id is enabled |
| 5 | Tests the return of name of table |
| 6 | Test whether the node is a leaf |
| 7 | Test when the questionnaire was last changed |
| 8 | Test when the questionnaire was created |
| 9 | Test when the questionnaire is private |
| 10 | Test whether the instructor id is associated with questionnaire |
| 11 | Test whether the questionnaire name is returned |
Class Hierarchy
The node.rb model is the base class from which all other nodes inherit from. The children of the node model are assignment_node.rb, course_node.rb, folder_node.rb, questionnaire_node.rb, questionnaire_type_node.rb, team_node.rb, and team_user_node.rb. The functionalities of these nodes are implemented by polymorphism and the subclasses implement the specifications of the base class.