CS21 Lab 7: Academic Records, Top-Down Design

Design due Friday, March 22, before midnight.

Full Implementation due Saturday, March 30, before midnight.

The primary goals of this lab are to practice using Top-Down Design and to write a complex program from scratch.

Please read through the entire lab before starting!

Make sure all programs are saved to your cs21/labs/07 directory. Files outside this directory will not be graded.

  $ update21
  $ cd ~/cs21/labs/07

Note: This is a two-part lab, split over two weeks. For the first week, you will 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 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 Friday (March 22) and the implementation the following week (March 30). It is highly recommended that you submit your top-down design a few days before the due date so that we have time to give you feedback before you begin your full implementation. If you submit your design Friday March 22 at midnight, it might take us a few days to get to it and send you comments on your design.

See below for the design requirements.

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:

1. The student ID of the student taking the course.
2. The department of the course.
3. The course number of the course.
4. The semester in which the student took the course.
5. 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.

Examples, Requirements, and Tips

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

• Example 1
• Example 2
• Example 3

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 (i.e. via the input() function)

• 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.

  • Quit. This option allows the user to quit.

• Do not assume the user enters valid input. For example, when handling a "compute GPA" request, you cannot assume that the user enters a valid studentID. 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.

Top-Down Design requirements

You 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), run handin21 to turn it in! After running handin21, send your professor and lab instructor a short email, letting them know your design is done. We will take a look at the design and send you comments (usually within a day or two).
• After you have the design and have heard back from your professor, 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.
• 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

Each lab has a short questionnaire at the end. Please edit the QUESTIONS-07.txt file in your cs21/labs/07 directory and answer the questions in that file.

Turning in Your Labs

Don't forget 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.