Design Document: File Manager for the PG System

CSC/ECE 517

November 20, 2002

Group members: Amit Bhatia

Rusty Buzhardt
Ajith Kallambella

Tom Norwood

1. Introduction

Purpose

Currently, the peer grading system (PG system) only permits users to submit files. Once submitted, these files cannot be deleted or renamed. Under this system, users may submit erroneous or unwanted files. The only way in which these files can be removed from the system is by asking the TA to do so. This new system will allow the user to take responsibility for the submitted files. Thus, it will allow users to copy, delete, move, and rename files from the PG system.

Scope

This new system gives the user the functionality of copy, delete, move, and rename. These functions will be implemented in the PG system by modifying the following Java files: LoginPage.java, LinkPage.java, RcvPage.java, and ReviewPage.java. These files have already been input to the system and have a base functionality. The copy, delete, move, and remove functions will simply add to the functionality of the existing program.

Background

The PG system currently works by allowing users to submit files, which will in turn be viewed, by other users. This system makes communication between peers easy as well as efficient. The file manager of this PG system will be changed. This is to allow better functionality on behalf of the users. Users would then be able to make the necessary changes to their files without having to call on the TA for assistance. The PG system itself can be found at

Documentation

This section shall identify the documents related to the products that already exist, and those that shall be generated or modified as part of the product. Documentation for the PG system can be found at the following URLs:

2. System Architecture

The system shall be altered in order to allow the following functionality: copy, delete, move, and rename of files. This functionality shall be added by modifying the existing files (LoginPage.java, LinkPage.java, RcvPage.java, and ReviewPage.java).

2.1 Summary of requirements

The modifications to the PG should encompass the following set of features:

  • Support at least deletion and renaming of files, and also "copying" of files between versions. This should be implemented by symlinks on Unix, shortcuts on Windows, so we don't waste space with multiple copies. (It should work like a shallow copy, so if the file is updated in the latest version after being "copied," the "copy" in the earlier version doesn't change.)
  • Allow files to be moved between the user's subdirectories (within a single version).
  • Allow files to be uploaded or downloaded. A version should only be able to be created via the Submit page of PG. However, once a version is created, this interface will allow users to upload or download files from it.
  • Protect the system–the submitter should not be able to go above his "home" directory (typically pg_data/public/…/<numeric-user-id>)
  • The user should not be allowed to tamper with the directories as such - should not be allowed to delete or rename the directories that were created by the system (e.g., v2, v3, etc.).

All these modifications will be integrated into the current PG system.

The classes affected by the figures below.

2.2 Summary of Product requirements

For testing purposes, the following identifiers will be used in testing the system:

Copy / Copy the specified file.
Delete / Delete the specified file from the specified directory.
Move / Move the specified file to a new directory.
Rename / Rename the specified file.

There are other aspects to the system, like users and files. These aspects will be inherent to the system, i.e., in order for the system to work, these items must be present. These identifiers will be used in the next section.

2.3 Summary of Testing Requirements

The following table describes the functions and their testing requirements.

Function / Testing requirement
Copy / A successful copy will create an exact copy of an existing file, which is specified by the user. The copy function can only be made within or on a valid directory (any directory below the user’s home directory the PG system did not create). An unsuccessful copy is when any of the preceding requirements are violated (corrupt copy of file, copy a file from an invalid directory, etc.).
Delete / A successful delete will delete the file the desired directory. The delete function can only be made within or on a valid directory (any directory below the user’s home directory the PG system did not create). An unsuccessful delete is when any of the preceding requirements are violated (corrupt delete of file, delete a file from an invalid directory, delete a file which was not specified, etc.).
Move / A successful move will move the file the desired directory, which is different from its current directory. The move function can only be made within or on a valid directory (any directory below the user’s home directory the PG system did not create). An unsuccessful move is when any of the preceding requirements are violated (corrupt file move, move a file from/to an invalid directory, move a file which was not specified, etc.).
Rename / A successful rename will name something different than its current name. The rename function can only be made within or on a valid directory (any directory below the user’s home directory the PG system did not create). An unsuccessful rename is when any of the preceding requirements are violated (corrupt file rename, rename a file invalid name, rename a file which was not specified, etc.).

2.4 Requirements - Testing

The testing shall be accomplished by using both valid and invalid test cases. All possible modifications (copy, delete, move, and rename) will all be tested using the previous section’s testing requirements for success and failure.

2.5 Interface Requirements

All the changes made to the PG system will not affect the other aspect of the system. For example, the other interfaces like submit will not be affected by changes made in the file manager. The file manager will only change the current files. All of the other aspects will remain unchanged. The external user interface will be a familiar web interface with buttons that will be clicked on to perpetuate a particular function, e.g., copy, delete, move, and rename.

3. Details of Requirements

This section shall document all the requirements identified in the earlier section in a detailed manner.

3.1 Requirement

This section is for Requirement stated in section 2.2

Inputs

The inputs for the system are the files. These files are the files submitted by the user. These files cannot be anything outside the scope of the user’s home directory. The user cannot modify those files, which were created by the system such as v2, v3, etc. The PG system as a whole contains more inputs; however the file manager is only concerned with files contained in the user space.

Processing

The previously stated modifications will be processed by the PG system. They are summarized below.

Copy / Copy the specified file.
Delete / Delete the specified file from the specified directory.
Move / Move the specified file to a new directory.
Rename / Rename the specified file.
  • If copy is clicked then a pop-up window could be displayed, with one FileMenuList showing the list of current subdirectories and files in that directory and another similar FileMenuList showing only the subdirectories. The file to be copied FROM is chosen from the first list and the subdirectory to be copied to should be chosen from the second list. This should use the linking mechanism (ln -s <filename>) to create the soft link in Unix at shell level.
  • If delete is chosen, then a pop-up window could be displayed, with just one FileMenuList showing the list of current subdirectory and files in that directory. Choosing a file should delete the file and if the subdirectory is now empty, that subdirectory should also be deleted. Choosing a subdirectory would delete both the subdirectory and the files in it. In either case, the Versioning System file would then be contacted to update it with the latest info.
  • If move is chosen, it would be similar to the copy function except that instead of using a link mechanism, the move function, at the Unix shell level (mv <source file</path/of/destination/filename >, would be used.
  • If rename is clicked, then a pop-up window should be displayed, with one the current list of files showing the list of current subdir & files in that directory and another JTextField for the new name for the file selected in the FileMenuList.

Outputs

The output of the file manager of the PG system depends on the inputs. That is, what is changed in the system is dictated by what modification the user chooses to do. The four main cases are shown below.

Copy / A copy of the selected file is output to a directory (not the current location of the file).
Delete / The selected file will be removed from the list of files in a directory. No files are output, but file listing for a directory is updated.
Move / A file is output into a specified, valid directory.
Rename / A new name is output for a specified file. The new name can be any valid name (e.g., no spaces in the name).

4. Development Environment Requirements

Hardware requirements

There are two sides to the PG system, a client (the end user) and the server (where the files for the PG system are stored). The computing power for the client side should be minimal. That is, there should be no CPU intensively work required. The computing power necessary on the server side will be much larger due to the fact that it must serve many users concurrently. The memory and storage requirements should be minimal as well. The files to be modified will be on the server; so, the server’s memory and storage requirements must be adequate to allow each user to use the file manager and their files with in the PG system. There also must be a network connection in order for the user to modify his/her files. The specification of the network is not a requirement for the file manager.

Software requirements

The file manager for the PG system should work with any modern web browser. All functionality, which is present on one browser, should also be present on any other browser.

5. Post Development Requirements

Maintenance Requirements

The maintenance for the file manager should be minimal. Once the file manager is in place, it should require very little maintenance. This is because the file manager itself should not be modified; it only creates a pathway for users change their files.