[2022] COMP1531 Software Engineering Fundamentals - Lab03 Academics
Lab03 - Academics
Background
Rationale
As a software engineer, it is important to quickly adapt to changing requirements. Seeing your success from lab01, the university has reached out again for help with redesigning their entire academic-course system.
You were presented with a new set of requirements, including the admission of new academics and courses to the system. Any design decisions and inner workings of your software are left to your professional judgement - the university is only interested in the input/output from the interface.
However, being the brilliant engineer that you are, you will of course ensure that your software is robust and flexible for future changes.
Getting Started
Please make sure you have completed lab03_password prior.
Copy the SSH clone link from Gitlab and clone this repository on either VLAB or your local machine.
In your terminal, change your directory (using the cd command) into the newly cloned lab. To check if you have done this correctly, type ls in this new directory to see if you can see the relevant files (including academics.js).
Package Installation
1. Open package.json and look under the key "devDependencies" . We have added these development packages from lab03_password for you:
2. Use the command below to install all "devDependencies" (and also "dependencies" , although none is needed in this lab):
3. Under "scripts" , make the following changes:
4. Use git status, add, commit and push your package.json and package-lock.json.
Interface: Functions
The functions from lab01_academics are no longer a part of the interface. However, you are welcome to copy and repurpose them in your code if you want to.
Note
For many functions above, the first parameter academicId is only for verifying that the academic that is calling the function is valid. Currently, there is no way for an academic to join a course or become a staff unless they were the creator.
For error cases, you can
Interface: Data Types
This is only regarding the input/output of the functions in the Interface: Functions and has no relation to the data object (implementation). Sometimes the implementation data types will very closely align, but there is no expectation they do.
Note
Array of objects, where each Object is of type academic
Object containing keys {courseId, name, description, allMembers, staffMembers}
Array of objects, where each object contains the keys {academicId, academicName}
Array of objects, where each object contains the keys {courseId, courseName}
Some objects have been added or updated from lab01_academics. Pay close attention to the keys as well. All arrays of objects can have items in any order. Your tests need to account for this (see Tips).
Task
Testing
This should be done before designing your database or implementing your functions.
In the file academic.test.js, write tests for all functions in Interface: Functions. You should expect most of your tests to fail on your implementation initially!
IMPORTANT: Your tests should not make assumptions about:
how data is stored how IDs are generated
For example, one implementation could have the academicId start at id -1000 and decrease by 5 for each new academic, i.e. -1000, -1005,-1010, etc.
another could randomise the ID (while still ensuring uniqueness).
which helper functions (i.e. not in the Interface: Functions) are available.
In your tests, you should only be importing functions from Interface: Functions and write your tests using only the knowledge of the input
parameters, return values and the description of the function.
Tips
1. Each test should be independent of the other. To achieve this, you can use the clear function at the beginning of every test. Consider using Setup and Teardown to streamline your code.
2. When testing/comparing arrays of objects, since we don't know which order they will be in, we could:
sort both arrays by IDs before comparing, or
(recommended) convert each array into a Set before comparing, as order won't matter in sets. The side effect is that duplicated elements are lost, although array objects in this lab exercise are unique by ID so this is fine.
Database
The database is now black-boxed to us - you can design it however you like! We will have zero knowledge of your data structure when auto-marking. See more details in the Testing section.
However, you may want to design your database such that the same information isn't stored/duplicated in multiple places. Consider the case where an academic may want to change their name in the future:
will this be easily achieved by changing one data entry (e.g. the value of an object key) in your code, or will you have to find and change their name in multiple places?
Implementation
1. Open the file academics.js in your preferred text editor. The stub code for each function has been provided for you.
2. Complete each function in Interface: Functions.
3. Test your code with your previously-written tests with
4. Fix up any errors in your implementation.
Submission
Use git to add , commit , and push your changes on your master branch.
Check that your code has been uploaded to your Gitlab repository on this website (you may need to refresh the page).
If you have pushed your latest changes to master on Gitlab no further action is required! At the due date and time, we automatically collect your work from what's on your master branch on Gitlab.
Additional Information
Sample package.json
Click to view our sample package.json
