CS21 Lab 7: Academic Records, Top-Down Design

Design is due Saturday, October 30, before midnight

Full Implementation is due Saturday, November 6, before midnight

Goals

practice using Top-Down Design
write a complex program, with multiple functions, from scratch
practice using file I/O

Notes

Please read through the entire lab before starting!

This is a two-part lab, split over two weeks. For the first week you will work with a partner and focus on using top-down design to create the overall structure for the program. Once your proposed structure has been reviewed and approved by your professor or lab instructor, you will each individually use bottom-up implementation to complete the full program.

You have two weeks to complete the full program. The first week is for the design, and the second for the full program. Your initial top-down design is due this Saturday (Oct 30) and the full implementation the following week (Nov 6). We highly recommended that you submit your top-down design as soon as is possible so that we have time to give you feedback before you begin your full implementation. If you submit your design on the last day at midnight, it might take us a few days to get to it and send you comments.

The list of partnerships is on here.

Please see the following guidelines for lab partnerships for information about how to best collaborate with a partner on lab assignments.

Academic Records

Students generate large amounts of official academic information throughout their time at Swarthmore. This can include information on which courses a student has taken, from which departments they’ve taken courses, and what their grades are. For this lab assignment, you will write a program that helps a user manage this data.

For this lab, here is the information you’ll keep track of:

The student ID of the student taking the course.
The department of the course.
The course number of the course.
The semester in which the student took the course.
The grade the student earned in the class.

You will need to support reading this information in from a file. Each line of a file should have information about one course that one student took. The information above should be separated by commas. Here is an example file of student data. You can also access example files at:

/usr/local/doc/academic-records/small.txt
/usr/local/doc/academic-records/medium.txt
/usr/local/doc/academic-records/large.txt

Examples, Requirements, and Tips

Here are a few examples of the running program, to help you see how things should work.

You have some freedom in how you want your application to look and in the functionality you provide. Here are the minimal requirements:

At the start of your program, you will have no student grade records. A user of your program should be able to load this information from a file or add this information directly.
You must provide the user a menu of options for what they can do with their program. Your program must perform requested actions from the user until they elect to quit. Here are the actions your program must support:
Load From File. When this option is selected, your program should discard previously loaded academic data, prompt for the name of a file where new academic data is stored, and load that into a list of records.
Display Classes. When this option is selected, your program should ask for a student ID, and display information about the classes this student has taken.
Display Classes by Department. When this option is selected, your program should ask for a student ID and a department, and display information about the classes this student has taken in this department.
Add Course. When this option is selected, your program should ask the user for information on a single course a student has taken. Then, your program should add this course to the existing list of records. It’s possible that this is the first course added, in which case your program should have a list of a single course after performing this action. It’s also possible that the student/course information already exists. This is fine---it’s possible for students to retake a course.
Compute GPA. Prompt the user for a student ID, and compute that student’s GPA from the known courses they’ve taken. When calculating GPA, use Swarthmore’s letter grade to GPA conversion to convert letter grades to point values. If a student hasn’t taken any courses, say so.
Quit. This option allows the user to quit.
It’s ok to treat all academic record data as strings (including the course number).
Do not assume the user enters valid input. For example, when handling a "Add Course" request, you cannot assume that the user enters a valid letter grade. You can assume the user enters a string when you’re expecting a string, and int when you’re expecting an int, etc. In situations when the user enters a studentID for a student not in your records, print a helpful message saying so. When the user enters a department, course number, or semester not currently in your records, assume this is a valid department/course number/semester you just haven’t seen yet. It’s OK if e.g. the department doesn’t correspond to an actual department at Swarthmore.
As you develop your top-down design, be mindful of the data structure(s) you’ll use to maintain the data in your program, and how this data gets passed around your functions.

Top-Down Design requirements

You and your partner should complete your top-down design (TDD), submit it, and obtain feedback on it before beginning the full implementation. Special procedures for this lab:

create design-ar.py first.
after you have a working design (see below), you and your partner should both run handin21 to turn it in! After running handin21, send an email to tddf21@cs.swarthmore.edu, letting us know your design is done. We will take a look at each design and send you comments (usually within a day or two). If the design is incomplete or insufficient, you may be asked to submit a second design.
After you have the design and have heard back from us, copy the file to ar.py (ex. cp design-ar.py ar.py) and implement the full program. Leave design-ar.py as it is. Work by yourself for the implementation portion of this lab.
Please ensure your design meets the following requirements before submitting:
main() should be completely written, and should perform high-level steps without focusing on details.
main() should call the functions you create in your design, in the appropriate order, and with arguments that match parameters. Return values should be saved in main(), even if you don’t do anything with them yet.
All functions should be stubbed out with parameters, a block comment, and a return statement. They don’t need to do anything yet, except possibly call other functions.
If your function is supposed to return something, you should return a dummy value of the appropriate type (e.g. return 0 for an int, [1,2,3] for a list, …).
Your design should contain several functions. Each function should be function worthy (i.e., not a trivial task). Each function should also demonstrate encapsulation (one clearly defined purpose)
The design should run without syntax errors. (even if it doesn’t do much)

Here is a simple example of Top-Down Design.

Answer the Questionnaire

Please edit the Questions-07.txt file in your cs21/labs/07 directory and answer the questions in that file.

Once you’re done with that, run handin21 again.

Turning in your labs…

Remember to run handin21 to turn in your lab files! You may run handin21 as many times as you want. Each time it will turn in any new work. We recommend running handin21 after you complete each program or after you complete significant work on any one program.

Logging out

When you’re done working in the lab, you should log out of the computer you’re using. First quit any applications you are running, like the browser and the terminal. Then click on the logout icon ( or other logout icon ) and choose "log out".

If you plan to leave the lab for just a few minutes, you do not need to log out. It is, however, a good idea to lock your machine while you are gone. You can lock your screen by clicking on the lock xlock icon. PLEASE do not leave a session locked for a long period of time. Power may go out, someone might reboot the machine, etc. You don’t want to lose any work!