Problem Description
We were pleased with the initial design, and it helped us refine and further develop our requirements. Our main goal right now is supporting the student’s ability to take various courses while ensuring that they are also reasonably prepared for these courses in terms of background preparation. Also, we want to ensure that we have instructors to support these courses, while maintaining records of the courses that have been taught and taken. Therefore, we would like you to develop a prototype system that will read the input data, and then process the various student and instructor actions to maintain the proper system state.Input Data Files and Formats:
Your system will need to read in data from six files: students.csv, courses.csv, instructors.csv, terms.csv, prereqs.csv and eligible.csv. Descriptions of these file formats are presented below.Also, the data in these files can (and likely will) change from test case to test case, so don’t assume that the data in these files will remain static, or that the records in a file will be in any particular order. students.csv: Our student data is contained in the students.csv file. This file (like the others) will be presented in a basic Comma Separated Values format. Each record in this file will have four fields: (1) a unique identifier over the student domain; (2) the student’s name; (3) the student’s address of record; and, (4) the student’s official phone/contact number. Note that some of the fields do contain spaces; however, we have scrubbed the files as much as possible to ensure that there are no “embedded commas” which might complicate your processing. Here is an example of a students.csv file:
4,ROBERT RYAN,481 Valley View Drive 42223,7153848491
5,JOSEPH LAWSON,447 Carriage Drive 77403,7405768930
9,GARY ALLEN,128 Pine Street 83866,8304231126
12,JULIE TURNER,927 6th Avenue 78553,2587799053
14,RENEE CARNEY,840 Main Street West 28729,8118091235
15,JAMES FISHER,231 Windsor Court 12288,4477500021
16,TRACEY WHITE,387 Canterbury Drive 49531,4952312905
17,CAROL TAYLOR,215 4th Avenue 27517,516479061
20,LILLIE LEWIS,373 Magnolia Court 55751,566944369
21,JEFFREY CLAYTON,600 Bridle Lane 70941,6222277693
22,SUE VELASQUEZ,204 Riverside Drive 72894,7543928902
24,DWIGHT WILCOX,981 Laurel Street 49148,7571682264
The student’s address is given as a house number, street name and zip code – our automated mailing systems obviate the need for us to store the city and state information explicitly. And, as you can imagine, some of the data that we are providing you has been “anonymized” (e.g. randomized) to protect the student’s privacy rights – however, the formats are exactly accurate in accordance with the actual data files. courses.csv: Our course data is contained in the courses.csv file. Like the records in the students.csv file, the records here are fixed length, and have two fields each. The fields are: (1) unique identifier over the course domain; and, (2) the course’s (short) name. Please note that some courses will still be listed in the file even if they are not being offered currently – this happens occasionally due to various administrative reasons: lack of instructors, budgeting priority, etc. Here is an example of a courses.csv file:
2,Computer Programming
5,Data Structures
10,Operating Systems
17,Relational Databases
28,Computer Graphics
Course descriptions will be important in the future, but we can do without them for now. One more key observation – you might notice that the course IDs and names have changed in comparison to the Course Catalog presented in earlier assignments. Please understand that our course listings are very flexible – names and IDs can be changed between test cases, so please not “hardcode” this information directly into your system. This is also true for student data, etc. Once we develop a more solid, running system, the IDs for courses, students, etc. will be more persistent over time. For now, though, the information submitted to your system in different test cases will likely change – treat every test case (set of files) independently.
instructors.csv: Our instructor data is contained in the instructors.csv file. The format of the instructor file is fundamentally identical to the student.csv file right now; however, we expect that some of our future requirements will make more distinctions between the two groups. For example, we will need to support the capability to identify which instructors are qualified to teach certain courses. We’re also addressing a potential need to support some of our students who have decided to assist the program as instructors while still enrolled and taking classes themselves. This will probably have some implications for how we track them in the system, and so we would like to discuss this in a future requirements session. Here is an example of instructors.csv file:
2,EVERETT KIM,699 Sheffield Drive 59251,8041174317
3,JOSEPH LE,974 River Road 61972,9939922102
4,ROBERT RYAN,481 Valley View Drive 42223,7153848491
5,JOSEPH LAWSON,447 Carriage Drive 77403,7405768930
8,REBECCA CURRY,692 Ashley Court 92876,9636667844
16,TRACEY WHITE,387 Canterbury Drive 49531,4952312905
terms.csv: Finally, records about when courses will be offered are contained in the terms.csv file. Each record represents one instance of a specific course being offered in the Fall, Winter, Spring or Summer, and has two fields: (1) the ID of the course; and, (2) the term designator. The first line below indicates that course ID 2 (Computer Programming) is offered during the Fall term. Here is an example of a terms.csv file:
2,Fall
5,Winter
5,Spring
5,Summer
10,Winter
10,Summer
28,Spring
prereqs.csv: The data provided in the prereqs.csv file provides information about which courses serve as prerequisites for other courses. Each record in this file has two fields of integers, and both field values represent the course identifiers for courses selected from the catalog. The course ID value in the first field means that that course serves as a prerequisite for the course ID represented in the second field. All of the course ID values must refer to valid courses as listed in the courses.csv file. The first line below represents the fact that course 2 (Computer Programming) is a prerequisite for course 10 (Operating Systems). Here is an example of a prereqs.csv file:
2,10
4,17
4,10
8,10
2,16
4,29
8,29
4,28
eligible.csv: The data provided in the eligible.csv file provides information about which courses can be taught by each instructor. Each record in this file has two fields of integers, where the first integer represents the ID for an instructor, and the second integer represents the ID for a course. All of the ID values must refer to valid instructors and courses as listed in the instructors.csv and courses.csv files, respectively. The first line below represents the fact that instructor 2 (Everett Kim) is eligible to teach course 2 (Computer Programming). Here is an example of a eligible.csv file:
2,2
2,5
3,5
3,10
8,28
16,17
Data Storage, Analysis, and Processing:
Your program will take on the flavor of a “running simulation” as it processes ten different types of instructions in the actions.csv file to maintains the changing system state information:- timeline-based instructions: start_sim, next_term and stop_sim;
- instructor-based instructions: hire, take_leave, teach_course and assign_grade;
- student-based instructions: request_course; and,
- query-based instructions: instructor_report and student_report.
The timeline-based instructions are used to control the flow of events. The instructor- and studentbased instructions focus on the management of offering and enrollment in courses during each term.
Finally, the query-based instructions allow the user to view the status of instructors and students.
The information provided in the actions.csv file represent the events that will occur during the academic terms. Each line (and the entire file) will always be presented in comma-separated values (CSV) format. Each line in the file represents one instruction, followed by zero or more parameters.
Your program will: (1) maintain the state information such as active and assigned instructors, available courses & seats, and student enrollments & grades; and, (2) update the state information while processing the instructions and displaying the appropriate responses.
Timeline-based Instructions:
When used together, the instructions define when specific terms begin and end in our timeline of events. The start_sim instruction has one parameter – an integer that represents the initial year – and will always be the first instruction in an actions.csv file. Similarly, the last instruction will always be stop_sim, which has no parameters. The next_term instruction, which also has no parameters, is used to end the current term and begin the following term. The initial term will always be Fall; and, the terms will follow the cyclic Fall, Winter, Spring and Summer sequence. Also, the year will advance during the transition from the Summer to Fall terms.The stop_sim and next_term instruction take no additional parameters, while the start_sim instruction has the format:
start_sim, <starting year: int>
Examples of the timeline-based instructions are given in test_case1.Instructor-based Instructions:
The hire and take_leave instructions are used select which instructors are active and able to teach classes for a given term. All instructors initially begin in the inactive (on leave) mode. Once hired, an instructor remains in the active (hired) mode for term after term until they go back on leave.
Instructors can only teach courses while they are active.
The hire and take_leave instructions have the formats:
- hire, <instructor ID: int>
- take_leave, <instructor ID: int>
Examples of the hire and take_leave instructions are given in test_case2.
The teach_course instruction is used to allow an instructor to select which course he or she will teach during a term. An instructor must be active to be able to teach a course. An instructor can only select an eligible course, and can also only teach one course per term. There is no requirement that an active instructor must teach a course. And, unlike hiring status, the selection to teach a course only lasts during the current term: an instructor must explicitly re-execute the teach_course instruction during the next term if they want to teach the course again.
If an instructor does successfully select a course to be taught, then that instructor can teach three (3) students in that course during the term. This is not really realistic compared to many real-world limitations, but the low numbers will make testing for things like the non-availability of free seats for a course a bit easier.
teach_course, <instructor ID: int>, <course ID: int>
The teach_course instruction has the format:teach_course, <instructor ID: int>, <course ID: int>
Examples of the teach_course instruction are given in test_case3 and test_case4.
There are a number of different things that might prevent an instructor from teaching a course. If multiple circumstances occur during execution, then your program should only print the single, highest priority issue in this order:
- nstructor has not been hired for the term;
- instructor is not eligible to teach the selected course; or,
- instructor is already teaching a different course.
The assign_grade instruction is used to record a final grade for the student once the course has been completed. The grade that the student receives impacts their ability to retake the course at a later date, especially if the course serves a prerequisite for others. Grades of A, B and C are considered “passing” for prerequisite purposes. The instructor ID does not necessarily have to be from the specific instructor who taught the course – there are cases where a different instructor might have to step in to complete the course grading after the term has begun. Also, comments are optional, so the assign_grade instruction might have four or five parameters.
assign_grade, <student ID: int>, <course ID: int>, <grade: string>, <instructor ID: int>, [optional: <comments: string>]
The assign_grade instruction has the format:assign_grade, <student ID: int>, <course ID: int>, <grade: string>, <instructor ID: int>, [optional: <comments: string>]
Examples of the assign_grade instruction are given in test_case5 through test_case10.
Student-based Instructions:
The request_course instruction allows students to request enrollment in a given course for that specific term. A number of circumstances must be true for successful enrollment – the course must be offered and have available seats, and the student must have successfully completed any and all prerequisites. Also, a student cannot retake a course if they’ve already earned a passing grade.
A student does not have to be enrolled in a specific section of the course. If two or more instructors are teaching a course during a single term, then you are free to consider the (three) available seats from each instructor as one consolidated pool of available seats.
request_course, <student ID: int>, <course ID: int>
The request_course instruction has the format:request_course, <student ID: int>, <course ID: int>
Examples of the request_course instruction are given in test_case5 through test_case10. There are a number of different things that might prevent a student from enrolling in a course. If multiple circumstances occur during execution, then your program should only print the single, highest priority issue in this order:
- the student has already successfully passed the course;
- the student is already enrolled in the course;
- the course is not being offered;
- the student hasn’t passed one or more of the prerequisites; or,
- there aren’t any available seats in the course.
Query-based Instructions:
The query-based instructions allow you to display information about instructors, students and courses based on the current state of the system. The responses are often multi-line, and are more verbose than the other commands to aid readability, troubleshooting, etc.
The instructor_report instruction is used to display information about an instructor during a current term. The first line of the output must contain the name of the instructor, and the following line must list the course for which the instructor is teaching during the current term.
The student_report instruction is used to display information about a student over the span of the all terms (from start_sim through stop_sim). The first line of the output must contain the name of the student, and the following lines must list the courses that the student has taken, along with the grades that they have been assigned, in the chronological order in which they were assigned. If a student has taken a course multiple times, then your listing must include all of the grades. And, if a student is currently taking a course for which the grade has not been assigned, then you should display that course with an underscore to represent the missing grade (_).
The instructor_report and student_report instructions have the formats:
- instructor_report, <instructor ID: int>
- student_report, <student ID: int>
Examples of the instructor_report instruction are given in test_case4; and, examples of the student_report instruction are given in test_case5 through test_case10.
Error-Checking, Diagnostics and Troubleshooting:
These timeline-, instructor-, student- and query-based instructions comprise the required (minimal) set of instructions that your program must implement. This is a summary listing of the different errortype messages that must be printed by the corresponding instructions as needed, in order of priority:
For the teach_course instruction:
• if the instructor has not been hired for the term:
# ERROR: instructor is not working
• if the instructor is not eligible to teach the selected course:
# ERROR: instructor is not eligible to teach this course
• if the instructor is already teaching a different course:
# ERROR: instructor is already teaching a different course
For the request_course instruction:
• if the student has already successfully passed the course:
# not enrolled: course already passed before
• if the student is already enrolled in the course:
# student already enrolled in course
• if the course is not being offered:
# not enrolled: course not being offered this term
• if the student hasn’t passed one or more of the prerequisites:
# not enrolled: missing prerequisites
• if there aren’t any available seats in the course:
# not enrolled: no available seats
However, you are welcome to implement other instructions and diagnostic messages that help you develop and test your program, as long as they do not interfere with the operation and/or display of the instructions as shown above.
Also, you are not responsible for any errors that are induced by our test cases: for example, if our test case attempts to designate a course that does not exist, then your program is welcome to ignore the instruction (null/blank output); or, preferably, display a very basic error message:
request_course,16,101
# ERROR
OR
request_course,16,101
# ERROR: course ID does not exist
Either approach is acceptable. We’re not evaluating you directly on this level of error checking during this assignment; and, any errors of this nature found in any of the test cases that we provide will be purely accidental, and corrected as quickly as possible once identified. By the same token, error messages can also be helpful for you as well, especially for situations involving incorrect course availability, faulty course request validation, etc.
Other Requirements & Relevant Points:
- Our administrative assistants did a reasonable job of hastily assembling this test data for you, along with a few other test cases to ensure that you have reasonable examples of the formats. They were a bit “overzealous” in their efforts, though – they sorted the records for many of the files in increasing order of the unique ID field. There is no guarantee that the records in the test files will be sorted in ascending ID (or any particular) order, so your program must be designed to handle records in any of the files in any order.
- All IDs (at this point) are positive integers to simplify processing, and we will let you know in a future session if this policy/format changes.
- The test cases that we’ve provided so far are all fairly small, which has the advantage of allowing you to more easily verify the correct answers by hand. More importantly, they are not comprehensive, and they don’t cover all of the requirements. We recommend that you develop your own test cases from scratch and/or by modifying the tests we’ve provided.
- To that end, you are permitted to create and share test cases with you fellow students. Strong emphasis here: you may share the test case files as described above along with a very basic statement describing the tests. However, do not include extra information about design and/or implementation specific details, etc. at the risk of sharing solution details in violation of academic conduct policies. If you are unclear if your descriptive test comments are “crossing the line”, then feel free to share them privately with the TAs on Piazza for review before sharing them with other students.
- You will not have to test for empty files – all test files will have at least one record. And though it is generally a good idea, you are not required to check for formatting errors in the test files. • We have discussed some of the expected growth rates for our program over the next few years with the school administrators and IT staff, and agree that we will probably need a more robust data storage solution for the future. For now, however, we will keep the sizes of the student, course and instructor content files under 500 records each; and, we will keep the academic records content files under 2000 records. Bottom line, you aren’t required to implement a major database or data management system, etc. at this phase of the development process.
Comments
Post a Comment