REMINDER: Your midterm is in class on Thursday, 3/11. Bring your J-card. It will cover everything we've done in class & lab through the first week of March (all of C). Lab sections on 3/4 and 3/5 will serve as midterm review sessions.
The goal for this assignment is to work with structs, linked lists, text files, and random access files to create and update a database of courses, as well as semester course listings. You have 1.5 weeks to complete it, and you will need all that time so start early.
Create two input files to use for testing program 4. The first file [5 pts], named courses.txt, can be used to read course information into the database (per the first operation in Part C). The second file [10 pts], named transactions.txt, can be used with input redirection to give operations and their related data to the main program. Make sure that you include a full test suite (multiple good and bad transactions for each operations, in any order) in this file!! One partner (not both) should submit both plain text files on webCT for p4a. You do not have to turn-in a printout at all.
Create a well-written document that explains how you will approach writing the code for part C. Include a description of the various files you will create to modularize the solution. Include details as to which partner will be primarily responsible for each file or program feature and deadlines for when they will be completed. Include all the times when you plan to meet to put your code together. Budget for a total of at least 40 man hours. I would hope it could be done in 30 or less (15/person), but we all know projects always take longer than expected. One partner (not both) should submit your work plan document on webCT for p4b. You do not have to turn-in a printout at all.
Your main program will provide a simplified database application for course listings. The program will create a databank of courses if none exists, or update an existing database with a small set of operations as described below. It will also dynamically create a listing of courses for two semesters, and keep a record of all transactions attempted. Each course in the database will have a unique two part number in accordance with the JHU system: ddd.nnn where ddd is the department number ranging from 001 to 700 and nnn is the course number ranging from 100 to 899, inclusive. Each course will also have a set of area designators (any combination of HSNEQW, including none at all), a number of credits which is a multiple of .5 between 0.5 and 4.5 inclusive, and a title which is at most 30 characters.
[8 pts] When the program is run it must be given a command-line argument that specifies the name of the database file. This must be a random access storage file, not a plain text file. (Generally it is good to call this *.dat so it is not confused with plain text files.) If the file already exists, then it should be opened for reading and writing. Otherwise your program should create it with 560,000 blank course records (because that's how many possible course numbers there are). A blank record has an empty string for its name field, 0 credits, and no area designators. The course number must be initialized to 000.000, making it obvious that this is a blank record (ie, the course does not yet exist). Because these files are very large, you should not store them in your account. See below for instructions on storing them in a temporary directory instead.
[5 pts] Below is the list of database operations which will be controlled by an interactive menu. Design your user interface so that the operation and it's related data can be input on one line. That way you can use a plain text file with unix input redirection to run the program later. (However, for small tests it is useful to run it interactively.) All updates to a course record or the database (adding/deleting courses) must be done directly to the database file (*.dat).
[12 pts] As you are processing each transaction, you must keep track of whether it is successful or whether it has failed (as detailed below for each transaction type). At the end of each program run, you must update two plain text transaction logs - one for successful transactions named "transGOOD.txt", and one for failed transactions named "transFAIL.txt". For each file your program must append to the end: the current date and time, followed by all relevant transactions for that program run, ordered by course number. Each transaction item should consist of the course number and a brief description of what occurred. In other words, these files will log information about all the transactions over time, grouped by program run and within each run, ordered by course number.
600.107 [E] Intro to Programming in Java (3.0)If there are no area designators for a course, there will still be [] in the input. Use the course number to determine in which record to store the data. For example, the first record should hold course number 001.100 and the last record is reserved for course number 700.899. If the course number is not already in use, the request should be satisfied and constitutes a succesful transaction. Otherwise, it is a failed transaction. Any input errors (file, format or invalid data) also result in a failed transaction. You must error check the course number, area designators and credits for validity. Process the entire file. [8 pts]
Implementation Details: [2 pts] Don't forget to use good style, including named constants for literal values that are part of the problem definition. You should also use a consistent comment format to explain function purposes. Other comments should be used to clarify the processing. Any violation of the STRICT requirements below will result in a 0 for the assignment:
Very Important: Do not run your program in your own unix account with a full database size. (You should test it with smaller sizes anyway.) The .dat files will be very big and must be saved to a temporary directory instead. Here are instructions from support on how to do this securely. Note that the tmp directory on each ugradx linux machine is different, so you make sure you are always working on the same machine.
prompt> mkdir /tmp/username (where "username" is your own username) prompt> chown username /tmp/username prompt> chmod 700 /tmp/username Those commands only need to be done once to create a temporary directory for your use only, on the machine you have logged into. Others will not have read or write permissions. You can only access it from that particular machine. Once you've created the directory, use a full path name to store your database file there when you run your program, such as prompt> ./a.out /tmp/username/courses.dat A few things... 1) If /tmp gets filled, it gets filled. 2) /tmp contents are never guaranteed, as the directory is... temporary, and not backed up. 3) Student needs to remember which computer they logged into, as /tmp on one machine is different than /tmp on another machine. 4) And finally, once they are finished with their /tmp/username directory, they need to remove it. Please make sure they don't forget to do that. They can use: prompt> rm -rf /tmp/username
Submission: [3 pts] You must continue to use tar/gzip to group together all the files you are submitting, which must include all *.h, *.c, your makefile, and your *.txt input files (updated if necessary from part A) into one compressed file. Do not submit your database record file or *.o executable files in any form! Submit your tar file electronically on webCT as p4c. Remember to turn-in printouts of your source code files (all *.h and *.c) in class. Please print double-sided to conserve paper.
Grading: 115 total = 3 points for submission, 17 style & efficiency, 95 functionality. -5 points if there are any warnings using the required compilation options. 0 points if the files don't all compile together (ie, any file has errors, no a.out created). Keep working on incremental coding development and ruthless testing!!
Download and complete the partner evaluation. This must be done individually! Your partner will not see your responses, so be brutally honest if necessary. If you report any serious problems here, then I expect to have heard about them much earlier in the hopes of helping to resolve them. Just submit your evaluation as a plain text document on webCT for p4d. You do not have to submit a printout at all.