CSE 3320 LAB 3 – ISAM Fall 2004

Objectives:

1. Practical experience with the problems of file structures.

2. Continued experience with the Windows XP operating system and IDEs.

3. KISS. Don't read things into the problem that aren't there.

Due: 30 Nov. 11:59 p.m.Difficulty: Moderate

Problem statement:

Implement an Indexed Sequential Access Method inside a single contiguous physical file as described in section 11.2.3 of the text. This will be an individual project in Windows XP. You may write the program in any language that is supported under any Integrated Development Environment (IDE) that runs on Windows XP. You will have to make that IDE available to demo to the TA. For an IDE other than Visual Studio you may bring a laptop to demo the program.

Details:

Your application should support only fixed length records and a maximum of 10 records. The records should have at least 5 fields, each of a fixed size. You only have to support the field sizes you choose, not arbitrary field sizes. You should store the records in the file in any convenient order except they may not be stored in order by the index fields. You should also support at least 2 sorted indexes to the records in the file. You can divide the physical file into logical sections for storing the main data records and for storing each of the sets of indexes.

You should display the records in the file in a GUI interface. You should be able to display the records in either the raw sequence in the main file or in the order of either indexed field. You should be able to add records to the file and delete records from the file. Deleted record space should be reused for later record additions.

After running the program and entering a few records you should be able to end the program and restart it, displaying the records already in the file. You should be able to show the file to the TA in some manner and explain the structure of the main file and the indexes.

Write-up:

Your write-up should include any known bugs and limitations in your programs. If you made any assumptions, document what you decided. For example, you should document the field names and sizes, whether you allow duplicate keys, etc. This write-up should be in text format and should be submitted along with your code. You should also document any code that you have copied from other sources.

Submission:

You will email your program to the class email address for submission, . You should ZIP your source files and write-up into a single file and email it. Be sure that you include everything necessary to unzip this file on another machine and compile and run it. This might include forms, modules, classes, config. files, etc. Do not include the absolute module. The name of your submitted zip file should be your campus login.

Make sure your name and your student ID are listed in your write-up, and in a comment in your source code. You may resubmit the project at any time. The submission time of the latest submission will be used for determining whether the assignment is on time or not. Late submissions will be accepted at a penalty of 10 points per day. This penalty will apply regardless of whether you have other excuses. In other words, it may pay you to do this project early on the off chance that something prohibits your submitting it in a timely way.

If your program is not working by the deadline, send it to the TA anyway and review it together for partial credit. Do not take a zero on any lab just because the program isn't working yet. If you have trouble getting started, ask the Lecturer or the TA.

Grading (subject to possible change):

points element

10 GUI raw record display

10 Display sorted by either index

10 Primary records stored

10 Add records - stop when file is full

10 Delete records

15 Restart program with existing file

10 Reuse deleted record space

10 Explain file structure to the TA

05 Comments in code

05 Program writeup

05 minimum number of fields, records, etc.

To receive full credit for comments in the code you should have headers at the start of every module/ subroutine/ function explaining the inputs, outputs and function of the module. You should have a comment on every data item explaining what it is about. (Almost) every line of code should have a comment explaining what is going on. A comment such as /* Add 1 to counter */ will not be sufficient. The comment should explain what is being counted.

Extra Credit:

05 disallow duplicate keys

10 use a grid control for record display

05 modify records

Important Note:

You may discuss the problem definition and tools with other students. You may discuss the lab requirements. All other work must be your own. You may not discuss or share project designs or implementation. You may use any book, WWW reference or other people’s programs (but not those of other students in the class) as a reference as long as you cite that reference in the comments. If you use parts of other programs YOU MUST CITE THOSE REFERENCES. If we detect that portions of your program match portions of any other student’s program it will be presumed that you have collaborated unless you both cite some other source for the code. You must not violate UTA, state of Texas or US laws or professional ethics. Any violations, however small, will not be tolerated.

Page 1 of 3