Contract II
Computer Science 145
University of North Carolina at Chapel Hill
Boss: Professor Greg Welch
Client: Professor Russell Taylor
February 13, 2001
Client:
Russell Taylor
Team Members:
Jeff Adams
Brian Boyd
Glenn Jessup
Jeff Townsend
_________________
2
This document – Contract II – is the “final” version of the nanoManipulator Index
contract, to be submitted to the Client – Professor Russell Taylor. Its purpose is to set
product and personnel requirements for both the Client and the programming Team –
consisting of Jeff Adams, Brian Boyd, Glenn Jessup, and Jeff Townsend. This “final”
version consists of the compromises between the Team’s ideas and concepts – including
User-Level Requirements, System-Level Specifics, Hardware and Software Resource
Requirements, and Preliminary Schedule – and the Client’s ideas and concepts. This
document will be delivered to the Client on February 13, 2001, to be signed, and a final
copy will be delivered to the Boss – Professor Greg Welch – on the same day. A fully
signed copy will be delivered to the Boss, Client, and each Team member upon earliest
convenience. If needed, a Contract III will be created for further compromises.
Document Change History
 February 12, 2001
o Added Section 5: Verification and Validation, moving Scheduling to
o
o
o
o
o
Section 6
Rewrite of Section 3: System Requirement Specification
Deletion of un-needed Glossary Section
Amended Section 1: Introduction, Second Paragraph
Sizing changes to Figure 2
Added nanoManipulator Index Data Model to Appendix
1. Introduction
The Client, Professor Russell Taylor, works on the nanoManipulator Project, a joint
project between the University of North Carolina’s Physics and Computer Science
Departments. This project uses a very sharp needle to manipulate objects on a
microscopic scale for various experiments needed on such a scale. Each experiment is
recorded and stored with relevant information to be played back at any given time.
However, over the years, these files have been haphazardly placed in the existing
directories with various styles used in naming the files for a more short-term recollection
instead of long-term recognition. Normally, this would not have been an issue, but the
only way to see the content of a miscellaneous file was to open it up, and run it until the
user recognized the video stream. Thus the idea of the nanoManipulator Index was
created as a method of creating thumbnail JPEGs of each experiment, to be placed in the
same directory format as the original file directory for ease of searching and
identification. These JPEGs will be converted from Tiffs, an image file format that the
nanoManipulator Program is already able to create.
To facilitate this nanoManipulator Index, two other parts of the project must also be
created and implemented: an AutoIndexer and a shell script that runs the AutoIndexer at a
chosen interval with user-decided options, both further explained later in this document.
3
2. User-Level Requirement Specification
B. Web Interface
A. AutoIndexer
nanoManipulator
Index
C. Script
Figure 1 - Context Model Diagram
User Interface:
A. Indexer: The indexer program will convert the snapshots taken by the viewer
to jpegs, and store them in a directory.
B. Web Interface: The web interface will allow a user to view the JPEG
snapshots for any compatible VRPN video we have indexed.
C. Script: The script will tell the indexer when to run, and with what user
specified options.
Process:
A. User IO
B. Web Index
G. User IO
C. Nano AFS
D. Viewer
E. Indexer
F. Script
Figure 2 – Process Model Diagram
4
A. The user interacts with the interface.
B. The web interface sends and receives data from the server.
C. The server sends data to the interface and the indexer program. It receives data
from the interface, indexer program, and the current VRPN viewer.
D. The viewer interacts with the indexer, and writes data to the server.
E. The indexer interacts with the viewer, and also sends and receives data from
the server.
F. The script takes data from the user, and kicks off the indexer.
G. The user provides options for the script.
3. System-Level Requirement Specification
3.1 Functional Requirements
3.1-A. User Interface
3.1-A.1 Browse nanoManipulator File System
The user will be able to browse the nanoManipulator directories
and view HTML pages associated with each experiment data file.
3.1-A.1.1 View Snapshots
The HTML file associated with each experiment will
contain JPEG thumbprint images taken from the
experiment’s video.
3.1-A.1.2 View ReadMe File
The contents of the ReadMe text file associated with each
experiment will also be included in each HTML file.
3.1-B. AutoIndexer
3.1-B.1 Create Snapshots
The AutoIndexer will use the nanoManipulator viewer along with
the command-line option provided by the client and/or his
colleagues to create periodic Tiff snapshots of each experiment
video file.
3.1-B.2 Convert to JPEG
Each Tiff snapshot will be converted to a thumbnail JPEG image
that can be viewed with a web browser through the HTML pages.
3.1-B.3 Delete Tiffs
All Tiff files will be deleted after being converted to JPEG.
5
Start AutoIndexer Script
Execute Indexer
With Options
Indexer
Options
INDEXER
Determine which
Experiments to
Index
Experiment
File Names
NANO
FILESYSTEM
Run Experiment
Videos, Creating
Tiff Snapshots
Tiff Files
Convert Tiffs to
JPEGs
Tiff Files
Delete Tiffs
JPEG Files
Create HTML
Files
Figure 3 – AutoIndexer Data Flow
6
3.1-C. AutoIndexer Executer
3.1-C.1 Directory
The directory option will specify the top-level directory to be
indexed.
3.1-C.2 Recurse
The Recurse option will tell the indexer whether to recurse through
the subdirectories of the specified directory or to only index those
files in the immediate directory.
3.1-C.3 ReIndex
The ReIndex option will tell the indexer whether to skip over or
reindex any experiments that have already been indexed on a
previous indexing session.
3.2 Non-Functional Requirements
3.2-A. User Interface
The user interface will be web-based using HTML pages, therefore it must
be accessible via any Netscape or Internet Explorer browser.
3.2-B. AutoIndexer
n/a
3.2-C. AutoIndexer Executer
n/a
3.3 Domain Requirements
3.3-A. User Interface
n/a
3.3-B. AutoIndexer
3.3-B.1 Execution Domain
The AutoIndexer will run on an SGI machine that has access to the
nanoManipulator directories in AFS.
3.3-B.2 Storage Domain
The AutoIndexer and any supplemental data files will be stored in
the top level of the nanoManipulator directory tree.
3.3-C. AutoIndexer Executer
The script that periodically runs the AutoIndexer has the same
domain constraints as the AutoIndexer (see 3.3-B.1, 3.3-B.2).
7
3.4 Interface Requirements
3.4-A. Web User Interface
The web user interface will interface with the AutoIndexer through the
structure of the nanoManipulator directory tree.
3.4-B. AutoIndexer
3.4-B.1 NanoManipulator Viewer
The AutoIndexer will interface with the nanoManipulator viewing
software in order to run the experiments and create Tiffs.
3.4-B.2 Image Converter
The AutoIndexer will use command line functions of an image
converter program to convert Tiffs to Jpegs.
3.4-C. AutoIndex Executer
The AutoIndexer will provide the operator of the nanoManipulator Index
system with a command line interface to specify with which options to
execute the command that runs the AutoIndexer.
3.5 Goals
The goal of this product is to make it easier for the user to browse the
nanoManipulator video file directories. Therefore, no extraneous maintenance will be
required in order to sustain the operation of nanoManipulator Index system.
4. Hardware and Software Resource Requirements
The nanoManipulator Index project has one obvious hardware requirement, which
is for a small amount of disk space to store the required files. These files include the
HTML files, the AutoIndexer program, the Script, and the Image Converter Program. We
have estimated this need at approximately 20 megabytes. Additional space will be
required for temporary storage of the Tiff files and permanent storage of all indexer
created files – HTML files and JPEGs.
The nanoManipulator Index project also has one software requirement – a small
program that will convert our Tiff files to JPEG files.
5. Verification and Validation
5.1 Strategy
Testing will be done using a top-down approach. As each component is
implemented, it will be tested using white-box methods. Sample input will be
8
used to test the specific system-level requirements of each component. This
sample input will ensure that all execution paths of the component are tested. A
structured system will be designed from the start with stub routines for
subcomponents. Black box methods will be used to test the entire system as each
stub is replaced with a fully tested and functioning component. The sample input
for the system will test the interfaces between components and verify that the
output correctly matches the user requirements. This process will continue until
all stubs have been replaced and the entire system has been built.
5.2 Test Cases
5.2-A. Tiff Generator
The program provided by the client to create Tiff snapshots of an
experiment file will be tested for correctly creating, naming, and saving
the Tiff snapshots.
5.2-B. Disk Full
The indexer should exit with an error message as soon as the
disk/directory it is writing to runs out of space.
5.2-C. Invalid Directory
The indexer should report an error if it is run on a non-existent directory or
on a directory that the operator of the indexer does not have permission to
access.
5.2-D. Previously Indexed Experiments
The indexer should recognize and skip over experiments that have already
been indexed (experiments that already have HTML files) on previous
runs of the indexer.
5.2-E. JPEG Conversion
The component that converts the Tiffs to JPEGs should be tested to make
sure it correctly converts and saves all of and only the Tiffs associated
with the experiment currently being indexed.
5.2-F. Tiff Deletion
All Tiff files created by the indexer and only those Tiff files created by the
indexer should be deleted upon completion of the indexing session.
5.2-G. HTML File Creation
The component that creates HTML files will be tested using sample
JPEGs and ReadMe texts. This will test the writing of files and also the
layout of the objects on the HTML page.
9
6. Preliminary Schedule
6.1 Development Items
6.1 – 1 Phases
6.1 – 1.1 Design
6.1 – 1.1a Write specifications
6.1 – 1.1b Write AutoIndexer prototype
6.1 – 1.1c Write Interface prototype
6.1 – 1.2 Implementation
6.1 – 1.2a Write User Manual
6.1 – 1.2b Code Interface
6.1 – 1.2c Code AutoIndexer
6.1 – 1.2d Test Interface
6.1 – 1.2e Test AutoIndexer
6.1 – 1.3 Integration
6.1 – 1.3a Test compiled Project
6.1 – 1.4 Delivery
6.1 – 1.4a Write Implementation Manual
6.1 – 1.4b Install & test on Client system
6.1 – 2 Milestones
6.1 – 2a Contract signed
6.1 – 2b Specifications approved
6.1 – 2c User Manual delivered
6.1 – 2d Prototypes approved
6.1 – 2e Interface passes test
6.1 – 2f AutoIndexer passes test
6.1 – 2g Project passes integration test
6.1 – 2h Implementation Manual delivered
6.1 – 2i Project installed & tested
6.1 – 3 Deliverables
6.1 – 3a Contract I
6.1 – 3b Contract II
6.1 – 3c Design Specifications
6.1 – 3d User Manual
6.1 – 3e Prototypes
6.1 – 3f Implementation Manual
6.1 – 3g Web Site
6.1 – 3h Project Package
6.1 – 3i Team Report
6.1 – 3j Individual Reports
10
6.2 Scheduling Charts
6.2 – 1 GANTT Chart
ID
1
2/4
Task Name
De sign
2
cont ract signed
3
write specificat ions
4
specificat ions approved
5
writ e aut oIndex prot ot ype
6
writ e interface prot ot ype
7
8
write user manual
user manual delivered
11
code interface
12
code aut oIndex
13
t est interface
14
interface passes test
15
test aut oIndex
4/1
4/15
4/29
2/19
2/19
3/5
3/29
aut oIndex passes test
3/29
t est system
19
system passes int egrat ion test
4/19
De l ive ry
21
write implem entat ion manual
22
implement ation manual delivered
23
inst all & test on client system
5/3
6.2 – 2 PERT Chart – critical path: 3-4-8-17-18-19-20-21-22
1
5/13
In te gration
18
20
3/18
2/13
protot ypes approved
9
17
3/4
Im ple m e n tation
10
16
2/18
2
3
5
6
4
8
9
10
11
13
14
12
15
16
17
18
19
20
21
22
23
24
7
11
6.3 Risk Analysis
6.3 – 1 Identified Risks
6.3 –1a Integration depends on client nanoManipulator software providing
snapshots.
6.3 – 2 Plans
6.3 – 2a Responsibility for providing snapshot capability has been assigned to
client group.
12
Appendix
13
nanoIndex Data Model
1
has subdirectories
D
irectory
Name
n
1
has experiments
n
Experiment
name
1
has an HTML file
1
HTML File
name
has a ReadMe file
1
1
ReadMe File
name
has sn apshots
1
n
JPEG Snapshots
name
14
Preliminary Report version 1.1
Computer Science 145
University of North Carolina at Chapel Hill
Boss: Professor Greg Welch
Client: Professor Russell Taylor
January 24, 2001
Team Members:
Jeff Adams
Brian Boyd
Glenn Jessup
Jeff Townsend
15
Overall Goals:
Our goal for this project is to provide an easier means of browsing through
experiments conducted using the nanoManipulator. In order to accomplish this we aim to
build a product that will, in coordination with the Unix viewing software, save periodic
snapshots of all compatible recorded experiments. These tiff images will be converted to
smaller JPEG files, and will be stored in an easily identifiable index directory.
Previously, the user would have to load the entire video into the viewing software, which
requires an excessive amount of time. Instead, we will implement a web-based interface.
We may also include a keyword search function with the interface, which would allow
the user to scan the readme.txt files that are included with each recorded video. We
intend to include options which will allow for color images versus grayscale, and any
other useful options which we may decide upon after having some time to experiment
with the viewing software first hand. Our basic design has three parts: the web interface,
an indexing program, and a simple script to kick off our indexer.
Product Features:
Our project requires a new feature to be added to the current viewing software
used in the nanoManipulator Lab. It is necessary that the viewer be able to take multiple
snapshots of a video at our request. This is to be completed by someone in the
department.
Feature Importance Description
Label
Rating
A
10
Converts the tiff files to jpeg files.
B
10
Decrease the size of the jpeg files.
C
10
Delete the tiff files.
D
10
E
10
Searches the Unix file system for compatible recorded
experiments.
Move the jpeg files to the desired directory.
F
10
G
10
H
8
Provide a web interface that shows the Unix file system
containing the recorded videos.
Interface allows user to click on a given experiment, and
provides the user with the jpeg thumbnail images from that
experiment.
Allow the user to specify the desired directory.
16
I
8
Allow the user to specify color image versus grayscale.
J
6
K
6
L
5
Interface allows the user to enter keywords into a search field.
This searches the readme.txt files for all compatible experiments.
The matches are returned as a list, and can be clicked to bring up
the experiment thumbnails.
Enable the user to edit a project’s readme.txt file while browsing
the thumbnail images.
List those experiments that have not yet been indexed.
M
3
Return error code if incompatible video type found
Interface:
Our web interface will be clean and easy to use. It will show the user the file
system of indexed experiments by file name and date. The user can click on a given
experiment, bringing up thumbnail jpegs of snapshots taken from the experiment video.
From there, the user may be able to edit the ReadMe file accompanying the images. We
strive to add a search form allowing the user to perform a keyword search on the included
readme files. As far as the indexing program itself, we anticipate to stick to a simple
command line interface.
Sample Web Interface:
nanoManipulator Index
UNC-CH Dept. of Computer Science
Filesystem:
+alabasterVRPNs
-buckyballVRPNs
buckminster1VRPN
buckminster2VRPN
+zygoteVRPNs
17
Sample image interface:
buckminster1VRPN:
View/Edit ReadMe
Go Back
Package Options:
Package A: This includes features a through g.
Package B: This includes all features a-i.
Package C: This includes features a-k.
Package D: This includes all features a-m.
Critical Path Items:
Show Stoppers
-It is absolutely imperative that the department itself provides the ability to
take snapshots within the viewing software at the given interval.
Things to Learn
-Our team must learn how to interface with the graphical software
currently being used by our client.
-It may be necessary for us to learn the scripting language or development
languages we decide to use for our project.
Things to get
-We must find a simple product that will help perform the file type
conversion from tiff to jpeg.
-We would like to be able to get a reservation for a room in Sitterson to be
used for our group meetings.
Things to understand
18
-Our team must understand how the graphical software mentioned above
functions.
Fall Back Options:
-Obviously, we hope to achieve Package D explained above. If this turns
out to be impossible, our fall back options include Packages a-c.
Schedules:
-Our team meets every Wednesday at 3 pm.
-We will meet every other Monday at 8:30 am with our client.
Document Updates:
Feb. 1, 2001
 Updated Cover Sheet: WordArt, Document Name, Boss name, Art
 Grammar corrections – i.e. products which to products that
 Changed spelling – nanomanipulator to nanoManipulator, unix to
Unix, etc.
 Lined up Features Table