Theory of Operations

School of Engineering Phone 503 943 7314 5000 N. Willamette Blvd. Fax 503 943 7316 University of Portland Portland, OR 97203-5798

Project Breitenbush: An Internet- Based Backup System

Contributors:

Toby Scherf

Dustin Digmann

Philip Johnston

Approvals

Name Date Name Date Dr. Vegdahl Mr. Van Dresser Insert checkmark (√) next to name when approved.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE II PROJECT BREITENBUSH. . Revision. History

Rev. Date Author Reason for Changes 0.1 12/1/05 Team Initial draft 0.2 12/3/05 Tobias Scherf Updated GUI mockups and added GUI descriptions. 0.3 12/4/05 Phil Johnston Filled in various sections and added descriptions for diagrams. 0.4 12/5/05 Dustin Digmann, Added further descriptions for the Tobias Scherf class diagram. Filled in missing descriptions, and wrote conclusion. Fixed some of the diagrams, as we found issues. 0.5 12/7/05 Team Corrections and additions of missing GUI class diagrams. Also added key descriptions for DB, frequency of use for queries, expected system load, preconditions, post conditions, exceptions and more. 0.7 1/22/06 Dustin Digmann, Updated to final GUI drawings, Tobias Scherf read through for grammar and logic errors 0.8 1/26/06 Philip Johnston Made changes (Non-GUI) based on feedback from Dr. Ward, and Dr. Vegdahl 0.85 1/30/06 Tobias Scherf Made changes (GUI-based) on feedback from Dr. Ward, and Dr. Vegdahl. 0.86 2/1/06 Philip Johnston Inserted : Overwrite GUI, and procedure for dealing with Accounts (See Login section) 0.94 2/706 Dustin Digmann Fixed errors suggested during review meeting. 0.95 2/9/06 Philip Johnston, Fixing small edits that Dr. Dustin Digmann Vegdahl recommened. We also made some more recommendations given to us in the review meeting.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE III PROJECT BREITENBUSH. . Table of .Contents

Summary...... 1

Introduction...... 2

Background...... 3

Technologies...... 3

MySQL – v4.0.25-max...... 3

Java – v1.5...... 4

FreeBSD UNIX – v5.4...... 4

Architecture...... 5

General Description...... 5

Design Overview...... 6

Graphical User Interfaces...... 6

Login:...... 6

Backup / Upload:...... 9

Restore/Download:...... 16

Data Model...... 27

Data Flow...... 29

Class Diagram...... 33

Conclusions...... 40

Appendices...... A

Traceability Table...... A

Functional Requirements...... C

Client Software...... C

Server Software...... C

Communication Security...... D

Use Cases...... D

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE IV PROJECT BREITENBUSH. . Login...... D Logout...... F

Upload...... G

Download...... H

Diagram Appendix:...... I

Glossary...... L

Links...... M

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE V PROJECT BREITENBUSH. . List of Figures.

Figure 1: High Level Architecture Diagram...... 5

Figure 2: GUI Welcome Screen...... 7

Figure 3: Login Internet Connection Error...... 8

Figure 4: Login Invalid User Information...... 9

Figure 5: GUI Backup Screen...... 10

Figure 6: GUI Backup Transfer Screen...... 11

Figure 7: GUI Backup File Transmission Failed...... 12

Figure 8: Backup File Transmission Failed...... 13

Figure 9: Backup Internet Connection Error...... 14

Figure 10: Backup Inadequate Storage Space...... 15

Figure 11: GUI Backup File Transfer Successful...... 16

Figure 12: GUI Restore Screen...... 18

Figure 13: GUI Restore File Selection Screen...... 19

Figure 14: GUI Restore Transfer Screen...... 20

Figure 15 : Overwrite File Dialog...... 21

Figure 16: Restore File Transmission Failed...... 22

Figure 17: Restore Internet Connection Error...... 23

Figure 18: Restore Inadequate Storage Space...... 24

Figure 19: GUI Restore File Transmission Failed...... 25

Figure 20: GUI Restore File Transfer Successful...... 26

Figure 21: Data Model Diagram...... 27

Figure 22: Data Flow Level 0 Diagram...... 29

Figure 23: Data Flow Level 1 Diagram...... 30

Figure 24: User Verification Data Flow Level 2 Diagram...... 31

Figure 25: Upload Data Flow Level 2 Diagram...... 31

Figure 26: Download Data Flow Level 2 Diagram...... 32

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE VI PROJECT BREITENBUSH. . Figure 27: System. Class Diagram...... 33 Figure 28: GUI Class Diagram...... 34

Figure 29: Login Swimlane Diagram...... I

Figure 30: Logout Swimlane Diagram...... J

Figure 31: Upload Swimlane Diagram...... J

Figure 32: Download Swimlane Diagram...... K

Figure 33: State Diagram...... K

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE VII PROJECT BREITENBUSH. . List of Tables.

Table 1: Traceability Table...... A

Table 2: Client Software Specifications...... C

Table 3: Server Software Specifications...... C

Table 4: Communication Security Specifications...... D

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 1 PROJECT BREITENBUSH. . Chapter . 1 Summary

Breitenbush’s Theory of Operations document provides a detailed technical summary of the project, including Graphical User Interface mockups and class-design of the database communications module.

Project Breitenbush is an implementation of an Internet backup system. This system will allow everyday computer users to backup and restore their personal files from any location that offers an Internet connection. File backup to the system will be made possible through the Breitenbush client application.

The implementation of this system will replace traditional file backup systems, such as Floppy disks, CD ROMs, DVDs, Flash Memory and similar devices. No longer will users have to fear that their vital data is in jeopardy of a failing backup device, such as the ones mentioned before.

The Breitenbush Internet Backup System will allow users to:

 Backup important personal files to our server using the internet.

 Backup files using any computer that has access to the Breitenbush client.

 Restore important personal files from our server using the internet.

 Restore files to any computer that has access to the Breitenbush client.

This document will show the design details necessary to implement the Breitenbush Internet Backup System. Detailed information regarding the chosen architecture, necessary graphical user interfaces, the data model, data flow diagrams, class diagrams, a traceability table, use cases, swimlane diagrams outlining system behavior, and a state diagrams are given below.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 2 PROJECT BREITENBUSH. . Chapter . 2 Introduction

Breitenbush’s theory of operations is intended to provide a detailed technical description of Project Breitenbush as documentation of our current design and reference for any future use or modification thereof. Team Breitenbush is implementing an Internet backup system to allow everyday computer users to backup their important personal files using the internet. The entire system consists of a server, client, and communications library. The server consists of a database holding the files of various users. The client application, which all users of the Breitenbush Internet backup system, will be used to backup and restore their files. A communications library will be used by the client application to access the Breitenbush system.

The information contained herein is a technical description of our current product, limited to a description of how Breitenbush works. There will be no references in regards to marketing plans or other information regarding marketing questions. This document has been divided into three major sections as follows:

- The Background describes the uses and market for the finished product.

- The Architecture section describes the software architecture with graphical user interface mockups, data model, data flow, state, and class diagrams.

- The Design Overview gives detailed technical descriptions of the manner in which the architecture is implemented.

The Conclusions section gives a short recap of the entire Breitenbush project.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 3 PROJECT BREITENBUSH. . Chapter . 3 Background

Currently, personal media backup devices such as CD-ROMs, DVDs, hard disk drives, floppies, and any other type of media do not guarantee indefinite persistence. There exists a need to store information remotely just as corporations do currently with offsite data archival. The proposed system will enable everyday users to save important information, just as corporations do, with the ease of use and accessibility of the Internet.

The Breitenbush Project will implement a system that will allow multiple users to have the ability to backup and restore files remotely. Access will be made with the use of a client application, the Internet, and a storage server. It will include a software package that will be distributed to clients and a server package that will not be distributed. Functionality that the Breitenbush system includes is:

 Provide the user with the ability to:

o Upload user specified files from the user’s machine to the Breitenbush server

o Download files that have previously been uploaded by the user, onto the user’s machine.

o Isolate the user’s files from all other user files.

o Provide password-protected security of user files.

Prior to this document a Functional Specification and Project Plan were generated. The Functional Specification describes from a managerial perspective what the overall expectations of what the Breitenbush Project needs to succeed. The Project Plan gave a timeline and estimated component breakdown of the workload that is required to accomplish our goal. This document provides a detailed description of what is necessary for each component work and how each data object, component, super-system, and subsystem interact to bring the Breitenbush Project to completion.

Technologies

MySQL – v4.0.25-max

MySQL is an open source database that allows for inexpensive and reliable implementation of database functionality. This database will allow the user information and user files to be stored in a secure manner while also allowing for the retrieval of the data over the Internet. A key utility that the MySQL project provides is a library allowing Java to communicate with the MySQL database.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 4 PROJECT BREITENBUSH. . Java – v1.5 .

Java allows for the rapid development of the user application while at the same time allowing for the communication between the user application and the database where the information is stored. This application enables the user to utilize the functionality of the Breitenbush system.

FreeBSD UNIX – v5.4

FreeBSD provides the Operating System (OS) for the Breitenbush Project. FreeBSD is an open source OS which is provided at no fee by the University of California at Berkeley. FreeBSD provides inherent stability and a platform for MySQL to run on.

Technology Note: The manufacturers at no charge provide all of these technologies to the educational user.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 5 PROJECT BREITENBUSH. . Chapter . 4 Architecture

General Description

Client Client Application 1 Application 2

DB Server Client Client Application 3 Application 4

Client Application 5

Figure 1: High Level Architecture Diagram

The architecture used for the Breitenbush project is based on a Data-Centered Architecture. The database is in the center of the system and holds various user information items including the files of the individual users (see Data model). Each client application depicted in Figure 1: High Level Architecture Diagram represents a unique user connecting to the central database. These client applications will hold the Breitenbush communications library, which will be developed in this project (see Class diagrams).

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 6 PROJECT BREITENBUSH. . Chapter . 4 Design Overview

Graphical User Interfaces

Login:

After the user starts the application, the user is presented with a login screen (Figure 2: GUI Welcome Screen) prompting for login information (Login Use case, scenario 1). The user will enter username and password into presented fields, with the restrictions that a username must be between 1 and 255 characters, and the password must be between 6 and 255 characters (Login Use case, scenario 1.1). The password will also be hidden from being read with the use of asterisks (*) – one for every character typed.

Once the user has entered the appropriate login information, he/she clicks on the Login button, which starts the login procedure (Login Use case, scenario 1.1). If an Internet connection is not established, the GUI will inform the user with an error message (Figure 3: Login Internet Connection Error). If the login information was invalid, the user is again prompted with the same screen to provide appropriate login information (Figure 4: Login Invalid User Information). The user has three chances to enter valid login information (Login Use case, scenario 1.3). After a third attempt with invalid login information, the application quits and has to be restarted to repeat the login procedure.

If at any time, the user wants to close the application, he/she can click on the button labeled “Cancel”, or click on the Windows “close” ‘X’ button in the upper right hand corner of the window (Login Use case, scenario 2).

After a successful login procedure, the application advances to the next screen with tabs labeled “Backup” and “Restore”, and the “Backup” tab will be active (Login Use case, scenario 1.2).

Note: New Account, Password Change, Remove Account, and Username and Password Retrieval : In order to obtain a valid login the user must contact the system administrator for the Breitenbush system. The administrator will create a user login entry in the database. The administrator will then notify the user of their account access, and inform them of the correct username and password to use. If the user forgets their username, or password the user must contact the system administrator for said information. If the user wishes to remove their access to the Breitenbush system the user will contact the system administrator for such an action. If the user wishes to change their password the user will again contact the system administrator for said action.

For all future GUI diagrams, window sizes will be static and will not be able to be resized. All forms containing file names will not be resized if the file name is too large for the current sized box.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 7 PROJECT BREITENBUSH. . . Breitenbush Backup. Tool v. 1.0

Breitenbush Backup Tool v. 1.0

User Name: Java Dude

Password: ******

Login Cancel

Figure 2: GUI Welcome Screen

Breitenbush Backup Tool v. 1.0 Internet ConnectionConnection ErrorError

User Name: Internet ConnectionJava Dude Error

Password: ****** An Internet connection error has occurred. Please check your Internet connection and try again. Cancel Login

Figure 3: Login Internet Connection Error

Breitenbush Backup Tool v. 1.0 InvalidInvalid UsernameUsername oror PasswordPassword ErrorError

Invalid Username or Password User Name: Error Java Dude

Password: ****** The username or password specified are invalid please try again. Cancel Login

Figure 4: Login Invalid User Information

Backup / Upload:

After a successful login, the user is presented with the Backup / Restore screen and the Backup tab is activated (Figure 5: GUI Backup Screen). From here, the user can select a file on the local hard drive in the file selection window to the left and back it up (Upload use case, scenario 1.1). The two fields on the right hand side labeled “File Name” and “File Size” show the name and the size of the file selected in the file selection window to the left. The field labeled “Last Backup” shows the status of the last file transfer, which can be any of the following: “No file backup attempted”, “File transmission failed” and “Successful”. These three options for “Last Backup” are session based and will not log past backups except during the current session. After the user has selected a file, he/she clicks on the button labeled “Backup” (Upload use case, scenario 1.2). After clicking on the button labeled “Backup” a window is displayed indicating the file transfer.

If the user wishes to logout and close the application, he/she can click on the button labeled “Cancel” or simply close the application with the Windows “close” button in the upper right hand corner of the window.

Backup Restore

C:\ My Documents File Name: Filexyz.doc Filexyz.doc Fileyzx File Size: 624 KB

Last Backup: No file backup attempted

Backup Cancel

Figure 5: GUI Backup Screen

When a backup was initiated by the user, a popup window is displayed showing the user that the file transfer is in progress (Upload use case, scenario 1.3 and 1.4). When the “File Transfer” popup is displayed the application is deactivated and the user can only interact with the popup window. Note that this will not generally affect windows of other applications, or other applications.

If the user wishes to cancel the file transfer, then he/she can click on the button labeled “Cancel” on the “File Transfer” popup window, or click on the Windows “close” button located in the upper right hand corner of the “File Transfer” popup window. If the user cancels the file transfer, then the file will not be saved remotely, and the field “Last Backup” will show the status “File transmission failed” (Figure 7: GUI Backup File Transmission Failed).

Backup Restore

File Transfer

C:\ My Documents FilenameFile :TransferFilenameFilexyz in .docProgress: Filexyz.doc Fileyzx Filesize: Filesize624 KB :

Last Backup: In Progress

Cancel

Backup Cancel

Figure 6: GUI Backup Transfer Screen

There are three possible errors which may occur while backing up a file. The errors are:

 “File Transmission failed” (Figure 8: Backup File Transmission Failed)

 “Internet Connection Error” (Figure 9: Backup Internet Connection Error)

 “Inadequate Storage Space” (Figure 10: Backup Inadequate Storage Space)

In order to proceed, the user will have to click the “OK” button or the Windows “close” button in the top right hand corner of the “File Transfer Error” popup. In order to backup the file successfully the user will have to attempt the backup again.

After the “File Transfer Error” popup has been acknowledged by the user, the application will display the Backup/Restore window with the “Backup” tab activated. The field “Last Backup” will now read the status message “File transmission failed” (Figure 7: GUI Backup File Transmission Failed).

Backup Restore

Last Backup: File transmission failed

Backup Cancel

Figure 7: GUI Backup File Transmission Failed

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 13 PROJECT BREITENBUSH. . . Breitenbush Backup. Tool v.. 1..0

Backup Restore

Transmission failed

C:\ My Documents FilenameTransmission: Filename Filexyzfailed.doc: Filexyz.doc Fileyzx Filesize: Filesize624 KB :

Last Backup: Failed The transmission failed due to corruption. Please try again.

Backup Cancel

Figure 8: Backup File Transmission Failed

Backup Restore

InternetInternet ConnectionConnection ErrorError

C:\ My Documents FilenameInternet: ConnectionFilenameFilexyz. docError: Filexyz.doc Fileyzx Filesize: Filesize624 KB :

LastAn Internet Backup connection: Failed error has occurred. Please check your Internet connection and try again.

Backup Cancel

Figure 9: Backup Internet Connection Error

Backup Restore

InadequateInadequate storagestorage spacespace

C:\ My Documents FilenameInadequate: Filename storageFilexyz .spacedoc: Filexyz.doc Fileyzx Filesize: Filesize624 KB :

Last Backup: Failed Inadequate storage space available on server, please contact the server admin.

Backup Cancel

Figure 10: Backup Inadequate Storage Space

If the file transmission succeeds, then the “File Transfer” popup closes and the application becomes active again. The field “Last Backup” will now read the status message “Successful”, indicating that the last backup procedure was successful and the file was saved to the server (Figure 11: GUI Backup File Transfer Successful Use Case, Scenario 1.4.1).

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 16 PROJECT BREITENBUSH. . . Breitenbush. Backup Tool v .. 1..0

Backup Restore

Last Backup: Successful

Backup Cancel

Figure 11: GUI Backup File Transfer Successful

Restore/Download:

After a successful login, the user is presented with the Backup / Restore screen and the Backup tab is activated (Figure 5: GUI Backup Screen). If the user wishes to restore a file from the server, then he/she will click on the tab labeled “Restore”. After clicking the “Restore” tab will become active and the user is presented with a file listing showing all files available for restore (Figure 12: GUI Restore Screen and Download use case, scenario 1). The two fields on the right hand side labeled “File Name” and “File Size” show the name and the size of the file selected in the file selection window to the left. The field labeled “Last Restore” shows the status of the last file transfer, which can be any of the following: “No file Restore attempted”, “File transmission failed” and “Successful”. After the user has selected a file, he/she clicks on the button labeled “Restore” (Download use case, scenario 1.1 and 1.2). After clicking on the button labeled “Restore” a window is displayed prompting the user to select a restore- destination for the file (Figure 13: GUI Restore File Selection Screen and Download use case, scenario 1.3).

If the user wishes to logout and close the application, he/she can click on the button labeled “Cancel” or simply close the application with the Windows “close” button in the upper right hand corner of the window (Download use case, scenario 1.2.1).

Backup Restore

Last Backup: No file backup attempted

Backup Cancel

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 18 PROJECT BREITENBUSH. . .

Backup Restore

Remote Server Filexyz.doc File Name: Filexyz.doc Fileyzx File Size: 624 KB

Last Restore: No file restore attempted

Restore Cancel

Figure 12: GUI Restore Screen

With the “Pick Restore – Destination” popup window open, all other application windows become inactive and the user can only operate in the popup window. Note that all other windows and applications that are not part of the Breitenbush backup system are not affected. The user has to select a destination and acknowledge with the button labeled “OK” to proceed with the file restore. If the user wishes to cancel the restore procedure, he/she can click on the button labeled “Cancel” or click on the Windows “close” button in the upper right hand corner of the “Pick Restore – Destination” popup window.

Backup Restore

Pick Restore - Destination

Remote Server C:\ Filexyz.doc Filexyz.doc My DocumentsFilename: Fileyzx Filexyz.doc Filesize: 624 KB Fileyzx Last Backup: File selected

Cancel OK

Restore Cancel

Figure 13: GUI Restore File Selection Screen

If the user cancels the restore procedure, the “Pick Restore – Destination” popup window is closed and the application is active again. From here, the user can, as usual, close the application using the “Cancel” or Windows “close” button, attempt another restore or switch to the backup procedure by clicking on the tab labeled “Backup”.

If the user acknowledges the restore – destination by selecting an appropriate destination in the “Pick Restore – Destination” popup and clicking on the button labeled “OK”, then the application proceeds with the file transfer (restore) and displays a “File Transfer” popup dialog ( Figure 14: GUI Restore Transfer Screen and Download use case, scenario 1.4 and 1.5).

During the file transfer, the application window is deactivated and the only window remaining active is the “File Transfer” popup. Note this does not affect any other applications running on the user’s computer. If the user wishes to cancel the file transfer, he/she can click on the button labeled “Cancel” or click on the Windows “close” button in the upper right hand corner of the “File Transfer” popup dialog. Canceling the file transfer does not save any portions of the file to the client.

Backup Restore

File Transfer

Remote Server Filexyz.doc Filename: Filexyz.doc Fileyzx File Transfer in Progress Filesize: 624 KB

Last Backup: Transmission in Progress

Cancel

Restore Cancel

Figure 14: GUI Restore Transfer Screen

There are three possible errors which may occur while restoring a file. The errors are:

 “File Transmission failed” (Figure 16: Restore File Transmission Failed)

 “Internet Connection Error” (Figure 17: Restore Internet Connection Error)

 “Inadequate Storage Space” ()

In order to proceed, the user will have to click the “OK” button, or the Windows “close” button in the top right hand corner of the “File Transfer Error” popup (Download use case, scenario 1.5.2). In order to restore the file successfully, the user will have to attempt the file restore again. After the “File Transfer Error” popup has been acknowledged by the user, the application will display the Backup/Restore window with the “Restore” tab activated. The field “Last Restore” will now read the status message “File transmission failed” (Figure 19: GUI Restore File Transmission Failed).

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 21 PROJECT BREITENBUSH. . . Breitenbush. Backup Tool v. 11.0

Backup Restore

Pick Restore - Destination

Remote Server Overwrite Destination? C:\ Filexyz.doc Filexyz.doc My DocumentsFilename: Fileyzx Filexyz.doc Filesize: 624 KB Fileyzx Last Backup: File selected The file “FILENAME” already exists in the destination directory. Do you wish to overwrite?

Yes No Cancel OK

Restore Cancel

Figure 15 : Overwrite File Dialog

When a user attempts to restore a file and the file with the same name exists in the selected destination directory, a warning dialog will display and prompt the user for permission to override the existing file. The text reads, “The file “FILENAME” already exists in the destination directory. Do you wish to overwrite?” (Figure 15)

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 22 PROJECT BREITENBUSH. . . Breitenbush Backup. Tool v.. 1..0

Backup Restore

Transmission failed

Remote Server Filexyz.doc TransmissionFilename failed : Filexyz.doc Fileyzx Filesize: 624 KB

Last Backup: Restore failed The transmission failed due to corruption. Please try again.

Restore Cancel

Figure 16: Restore File Transmission Failed

Backup Restore

InternetInternet Connection ErrorError

Remote Server Filexyz.doc Internet ConnectionFilename Error: Filexyz.doc Fileyzx Filesize: 624 KB

An Internet connectionLast errorBackup has : Restore failed occurred. Please check your Internet connection and try again.

Restore Cancel

Figure 17: Restore Internet Connection Error

Backup Restore

InadequateInadequate storagestorage spacespace

Remote Server Filexyz.doc InadequateFilename storage space: Filexyz.doc Fileyzx Filesize: 624 KB

There is not enoughLast storage Backup : Restore failed available on the system for file storage, please specify a location that can store this file.

Restore Cancel

Figure 18: Restore Inadequate Storage Space

Backup Restore

Last Restore: File transmission failed

Restore Cancel

Figure 19: GUI Restore File Transmission Failed

If the file transmission succeeds, then the “File Transfer” popup closes and the application becomes active again. The field “Last Restore” will now show the status message “Successful”, indicating that the last restore procedure was successful and the file was saved to the local computer in the specified destination (Figure 20: GUI Restore File Transfer Successful and Download use case, scenario 1.5.1).

Backup Restore

Last Restore: Successful

Restore Cancel

Figure 20: GUI Restore File Transfer Successful

Data Model

User -userName:varchar -password:varchar

File -fileID:int(15) -fileName:varchar -fileData:longblob -#userName:varchar

Figure 21: Data Model Diagram

Database Notes

The Data Model Diagram above represents all data being moved between the Breitenbush Database and individual clients. There is a one – to – many relationship between the User and File tables. This will allow each user to store as many files as the system allows.

User Table

Expected Size = 3 simultaneous users and 20 total system users.

Insert Frequency = 1 time per user creation

Update Frequency = Never. Users are unable to update information because function is out of scope.

Delete Frequency = Never. There is no functionality to remove users from the system.

Select Frequency = 1 time per login session, expected 3 sessions per hour (72 per day)

Usage: The User table will be queried to find a user with a specified user name and password in a manner that counts the number of users with such information. The reason for such a query querying is due to security issues. A result of a 1 on this query will be considered a success; otherwise a failure will be issued. To lower queries across the Internet, this information will be stored in instance variables in the Breitenbush Library for later user. This will make it so this information is not required to be queried on that session again.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 28 PROJECT BREITENBUSH. . . Users for this prototype will be manually added to the system. Toby, Phil, and Dustin . will be at least three of these users. All other users will be added as necessary, determined by the Breitenbush Team.

Passwords will be encrypted with a 16-bit DES encryption algorithm. This encryption will be done before transmission of any kind to ensure the privacy of the users. The database will also hold the values for the password in such a format.

File Table

Expected Size = 200 rows per users * 20 users = 4000 rows

Update Frequency = Never. Users are unable to update file information because this functionality is out of scope.

Delete Frequency = Never. There is no functionality to remove files from the system.

Insert Frequency = Every time a file is uploaded, expected 3 uploads per session per user. This equates to 3 files * 3 users * 1 hour or 9 inserts per hour (216 per day). At these rates, the Breitenbush system will be at capacity in approximately one month.

Select Frequency = Every time a file is downloaded. This should occur at the same rate as upload or 3 files * 3 users * 1 hour (9 selects per day or 216 per day).

Usage: The File table will be queried on many other items, making it a high use and risk table. First this table will need to be queried to find the file size of a given file. It will also need to be able to show if the database can hold more information. The File table is used primarily in this case because file sizes in this table will make it much larger then the User table. The table will also need to insert new files as well as select the file and pass it to the application. The table will also need to be able to get a remote file listing.

Primary and Foreign Keys

The User table will have one primary key and zero foreign or secondary keys. The username attribute will be that key. This key will distinguish any user from another user and thus will need to be unique.

The File table on the other hand will have one primary and one foreign key. The primary key is the fileID. This will be an identifier associated to any file and will need to be unique from all the other entries in the table. The username will be the same username that is in the User table and is the foreign key. With these two keys Breitenbush will be able to isolate files from users as well as distinguish files from other files for a given user.

High Use Queries

Query of file listing for a particular user.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 29 PROJECT BREITENBUSH. . . To lower bandwidth usage when the user requests a remote file listing, the file data . will not be received from the database but just the existing file information. The query to receive a remote file listing will occur on every login and after every upload to the server. This frequency will be the same as the insert frequency in the File table (or 216 per day).

High Volume

Query for requesting a file.

Query to insert a file.

Limitations

The current server setup imposes the following limitations:

- The cumulative space requirements of all files stored on the server cannot exceed the hard drive capacity.

- The number of users is restricted to available hard drive space on the server. In the event that the hard drive space is exhausted, no new users may be accepted into the system.

Data Flow

Sent Files File Information Data Storage System User User User Information Receive Files

Figure 22: Data Flow Level 0 Diagram

From Figure 22: Data Flow Level 0 Diagram the user is the sole provider of data that flows into the Data Storage System. The user is also the sole recipient of the data as well. With this system it is not limited to a single user, but for the purposes of this diagram a single user is represented.

Types of information that flow into and out of the system are defined by the Use Cases and Design documents. Information that is part of the User Information path includes ‘userName’ and ‘password’ for authentication purposes, ‘fileName’ and ‘fileData’. These data objects are defined in Figure 27: System Class Diagram. The process of interaction is defined by figures Figure 29: Login Swimlane Diagram, Figure 30: Logout Swimlane Diagram, Figure 31: Upload Swimlane Diagram, and Figure 32: Download Swimlane Diagram. For a more detailed description of the system please see Figure 23: Data Flow Level 1 Diagram.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 30 PROJECT BREITENBUSH. . . User User Login. Information Verification User Verification User Login Information

Connection/ Verification Status Connection/ Verification Status Database File User File Upload

File Request File Download File

Figure 23: Data Flow Level 1 Diagram

Figure 23: Data Flow Level 1 Diagram explodes the ‘Data Storage System’ from Figure 22: Data Flow Level 0 Diagram. With this the ‘User Verification System’ (UVS), ‘Upload System’ (US), ‘Download System’ (DS) and ‘File Listing System’ (FLS) are created.

The purpose of the UVS is to provide a utility for the system to verify a user is connected to the Breitenbush Database and has the ability to access the database with the user provided ‘userName’ and ‘password’. The other systems will query the UVS for user validity before each action.

The UVS will maintain a communication link between the database and client application as well. The US will provide the functionality allowing for the user to upload files to the database. This system will receive a file for upload; query the UVS for permission to commence this action, and the upload the file. The flow for the functionality is described in Figure 31: Upload Swimlane Diagram.

The DS will receive a ‘File Request’ from the user to download a file, query the UVS for permission to commence this action, and then download the file and return the file to the user. This action is exemplified in the Figure 32: Download Swimlane Diagram.

The FLS provides functionality for the system to return a remote file listing from the database to the user application. This will intern allow the user to request a file to download. The FLS checks to see if the user is valid and connected, and then queries the database for a file listing. The flow for this action is described in the Figure 32: Download Swimlane Diagram.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 31 PROJECT BREITENBUSH. . . Database

User Information Count

User User Information Verify User Success/Fail Notify User

Listing

User Name File Listing

Figure 24: User Verification Data Flow Level 2 Diagram

The User Verification Process in the Data Flow Level 1 Diagram breaks up into the Level 2 diagram as demonstrated in Figure 24: User Verification Data Flow Level 2 Diagram. The User will give user information to a verification process. This process will verify that user information by querying the database and get a count of those users with such information (This will be 0 or 1). A notification of success or failure is then passed to a notification process. The user verification process will also spawn the process to get a remote file listing.

File Verify Storage File Push File File Database User Notify (fail) Availibility

File Name Query Availability

Verify File Available Storage User Name File Listing Push Database Listing

Notification / File Listing User

Figure 25: Upload Data Flow Level 2 Diagram

The Upload Process in the Data Flow Level 1 Datagram breaks up into the Level 2 diagram as demonstrated in Figure 25: Upload Data Flow Level 2 Diagram. The user will pass a file to a storage availability process which will verify that there is enough space for the file to upload to the server. If the there is not enough space, the user will be notified of the failure. If there is enough space, the requested file will be given to a push file process which will be pushed to the database. The push process will then try to verify that the file was uploaded successfully. This verification will do so with a new remote file listing and notify the user of success as well as make the new listing available.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 32 PROJECT BREITENBUSH. . . Local System

User File Name Get File Size File Name, Size File User Available Storage

Query AvailibilityAvailable Storage

Verify Local Notify (failed) Storage Database Query File Notify File Information Store File Success / Failure File Download File Data Request File Verify

Figure 26: Download Data Flow Level 2 Diagram

The Download Process in the Data Flow Level 1 Diagram breaks up into the Level 2 diagram as demonstrated in Figure 26: Download Data Flow Level 2 Diagram. The user will first need to get the file size of that file from the database. The file name and its size will then be past to a verification process for determining if the local machine can store the given file. If not, the user is notified. If there is enough space, the file is requested for download. This download request then needs to get the file from the database and get the actual file data. A storage system then tries to save this file to the local machine. A verification process is taken to make sure the file was saved properly and the user is notified of the success or failure of the save.

Class Diagram

GUI Package

1 1 Connection BreitenBush -connectionToDB -connection -dbUserName -userPassword -dbPassword -userName -userName -failedLoginCount -userPassword +BreitenBush() -databaseLocation +Boolean login(in userName, in password) 1 1 +Connection(inout userName : string, in userPassword : string) +Boolean push(in file) +Boolean push(in file) +File pull(in fileName) +File pull(in fileName) +String[] getFileListing() +String[] getFileListing() +Boolean logout() +Boolean logout() +long getFileSize(in fileName)

Figure 27: System Class Diagram

Client Controller -Login login -Backup backup The classes listed here are -Restore restore part of the client package -BreitenBush breitenBush +Controller() +login_init() +restore_init() 1 +backup_init() 1 +main()

Login Backup Restore -String pageTitle -String tabTitle -String tabTitle -JLabel nameLabel -JFileChooser fileListing -JFileChooser FileListing -JLabel passwordLabel -JLabel fileName -JLabel fileName -JTextField userName -JLabel fileSize -JLabel fileSize -JTextField password -JLabel lastBackup -JLabel lastRestore -JButton cancel -JTextField fielNameField -JTextField fileNameField -JButton login -JTextField fileSizeField -JTextField fileSizeField +Login() -JTextField lastBackupField -JTextField lastRestoreField -JButton cancel -JButton cancel -JButton backup -JButton restore +Backup() +Restore()

Figure 28: GUI Class Diagram

Instance Variable Invariants

Breitenbush

connection (Instance – Connection)

userPassword (Instance – String, 5 < Length <= 255)

userName (Instance – String, 0 < Length <= 255)

failedLoginCount( Instance – Int, 0 <= Length < 3, incremented on connection failure, =0 on connection success)

Connection ( The connection takes the inputs from the Breitenbush class. The connection class acts as an interface to the Breitenbush class.)

connectionToDB (Instance – JDBC)

dbUserName (Instance – static final String, not null)

dbPassword (Instance – static final String, not null)

userName (Instance – String, not null)

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 35 PROJECT BREITENBUSH. . . userPassword (Instance – String, not null) databaseLocation (Static Final – InetAddress, not null)

Controller

breitenBush (Instance – Breitenbush, not null)

All other instance variables are for GUI-management and demonstrate no logical algorithms.

Method Descriptions

Each method within the library is invoked from the GUI, such that the GUI calls on the Breitenbush class, which calls on the Connection class and the Connection class in turn calls on the Database.

Breitenbush Class:

login(in userName, in password) - Public

Preconditions:

Username(String): must be an alphanumeric and special characters string of length 1 to 255.

Password(String, encrypted): must be an alphanumeric and special characters string of length 6 to 255.

Not currently logged in.

Has ability to access Breitenbush system (e.g. Internet connection).

Post conditions:

A connection has been established if valid userName and password have been provided.

If an invalid userName and password were provided, no connection will be established.

For every failure the failedLoginCount will be incremented.

Exceptions:

Internet Connection Error: When an Internet connection is not available this error will be thrown to the GUI. Text for this error will read, “An Internet connection error has occurred. Please check your Internet connection and try again.”

Invalid Username or Password Error: If a username and/or password do/does not match a specific user record this error will be thrown to the GUI. The text for this error will

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 36 PROJECT BREITENBUSH. . . read, “The username or password specified are invalid . please try again.”

Results:

This method takes a username and password from the GUI and creates an instance of the Connection class with those parameters. A handle to the Connection class instantiation, as well as the password and the username are stored within the Breitenbush Class. The Connection class will store the username and password upon successful instantiation.

Upon a failed login in Breitenbush, the failedLoginCount will increment by one. If there have been three failed logins, before a successful login, then the client application will close.

On successful login, the failedLoginCount is set to zero (reset).

push(in file) - Public

Preconditions:

File(File): Is a valid file that the user wishes to upload to the server, non-null.

A valid connection to the database must be available.

Post conditions:

Upon completion a file will have been inserted into the system.

Exceptions:

If an Internet connection is not present or is lost during a transmission, an exception will be thrown to the calling method. Text for this error will read, “An Internet connection error has occurred. Please check your Internet connection and try again.”

If the server cannot accept the file for lack of available storage space, then an exception will be thrown to the calling method. Text for this error will read, “Inadequate storage space available on server, please contact the server admin.”

If the file is corrupted during transit an exception will be thrown to the calling method. Text for this error will read, “The file transmission failed due to corruption please try again.”

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 37 PROJECT BREITENBUSH. . . Results: Upon a request from the GUI package to upload a file to the server, a file is passed through this method to the Connection class’ push method. The Connection class push method will then upload the file to the server (database). Boolean values are returned to indicate successful or failed file transfer.

pull(in fileName) - Public

Preconditions:

fileName(String): Is a valid file name of a file in the Breitenbush system that the user wishes to download, non- null.

A valid connection to the system must be available.

Post conditions:

Upon completion a file will have been downloaded from the system.

Exceptions

If the client cannot accept the file for lack of available storage space, then an exception will be thrown to the calling method. Text for this message will read, “There is not enough storage available on the system for file storage, please specify a location that can store this file.”

If the file is corrupted during transit an exception will be thrown to the calling method. Text for this error will read, “The file transmission failed due to corruption please try again.”

Results:

Upon a request from the GUI package to download a file from the server, a filename is passed through this method to the Connection class’ pull method. The Connection class’ pull method will then download the file from the server (database) to the client. The requested file is passed as a return value throughout these method calls.

getFileListing() - Public

Preconditions:

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 38 PROJECT BREITENBUSH. . . A valid connection to the database must be available. Post conditions:

A file listing will be returned to the calling method.

Exceptions:

If the listing is corrupted during transit an exception will be thrown to the calling method. Text for this error will read, “The file transmission failed due to corruption please try again.”

Results:

Upon a request from the GUI package to get a listing of the files stored on the server (database), the method calls on the Connection class’ getFileListing() method, which then queries the server (database) in order to return an appropriate listing. All methods incorporated in this transaction will return an array of Strings to the caller.

logout() – Public

Preconditions:

A connection has been established at some point during the operation of the client application.

Post conditions:

Upon completion a client will be logged out of the Breitenbush system. A Boolean will be returned to the client.

Exceptions:

Results:

When the client application is closed, the GUI package sends a method call to logout from the system. The Breitenbush class’ logout method then calls on the connection class which closes the open connection to the server. Notice this also ends the instantiation of both, the Breitenbush class and the Connection class.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 39 PROJECT BREITENBUSH. . . Connection Class: See descriptions in the Breitenbush class.

Controller Class:

This class and other classes within the GUI Package have no logical algorithms.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE 40 PROJECT BREITENBUSH. . Chapter . 5 Conclusions

Project Breitenbush provides the everyday computer user with an Internet based backup tool. Breitenbush is a software project that could be further refined and marketed to the general public. The Breitenbush system will allow users to backup and restore their personal files at any location that has access to the Internet. Users can therefore use the service from a variety of places such as their office, their home, an internet café, and the airport.

The system will be accessible through the Breitenbush client application. In this design we have extracted the communications module, which is the connection-bridge between client and server (database). The extraction of the communications module allows incorporating access to the server system through other solutions, as long as they comply with the requirements of the communications class. This is not planned at this stage, but the design was made to accommodate a high degree of flexibility to adjust to future demands.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE A PROJECT BREITENBUSH. . . Appendices

Traceability Table

Table 1: Traceability Table

Req. Login Logout Upload Download GUI

100 X Client Login

101 X X Client Logout

102 X X Client Upload

103 X X Client Download

104 X X Remote File Selection

105 X X Local File Selection(UL ) 106 X X Local File Destination (DL) 200 X Server Login

201 X X Server Logout

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE B PROJECT BREITENBUSH. . . Req. . Login Logout Upload Download GUI

202 X X Upload File to Server

203 X X Download File from Server 204 X X X Remote File Listing (Server side) 205 X X File Size Limitations

206 X X X X File Isolation

300 X Login Encryption

Table 1: Traceability Table demonstrates which components of the Breitenbush system implement the functional requirements specified in the Functional Specification document. The ‘Req.’ column a list of the requirements in that document, while the other columns show which function in the Breitenbush system satisfy this requirement.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE C PROJECT BREITENBUSH. . . Functional. Requirements

Client Software

Table 2: Client Software Specification contains a list of the system software specifications and their required values.

Table 2: Client Software Specifications

Req. # Requirement 100 Login: The user shall login to the system with an assigned username and password. The user will not have the option to change their password. 101 Logout: The user shall logout when closing the application. There will be no auto logout function because the server will implement this. The client will only know that it lost connection after a certain period of time. 102 Upload: The user shall have the ability to transfer files from their own computer to the server computer. 103 Download: The user shall have the ability to transfer files from the server to their computer. 104 Remote File Choice for Download: The user shall have the ability to view a listing of the files that are stored on the server. 105 Local File Choice for Upload: The user shall have the ability to choose a file from their computer to upload. 106 Local File Download Destination: The user shall have the ability to designate the destination for a file to download to using a file chooser.

Server Software

Table 3: Server Software Specification contains a listing of requirements for the server software package.

Table 3: Server Software Specifications

Req. # Requirement 200 Login: The server will allow the client to login to the system. 201 Logout: The server shall allow the client to logout when

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE D PROJECT BREITENBUSH. . . closing the client application. 202 Upload to Server: The server shall have the ability to receive files from the client computer. 203 Download from Server: The server shall allow the client to transfer files from the server to their computer. 204 File Choice for Download from Server: The server shall allow the client to request a file listing. The listing will be a flat structure (e.g. no directories). If the file exists then the user will be warned and it will be overwritten if the user allows. 205 File Size Limit: File sizes uploaded to the server will be limited to 4 GB. 206 File Isolation: The user will only be allowed to access his/her own files.

Communication Security

Table 4: Communication Security Specifications contains a list of the security requirements, for the client and server communication.

Table 4: Communication Security Specifications

Req. # Requirement 300 Login: The username and password will be encrypted during communication.

Use Cases

Primary Actor: User (novice). Goal in context: The User requests access to files (establish connections between Client and server). Preconditions: Internet connection and the server are accessible, Client application is opened, and a supported platform (Microsoft Windows) is being used. Trigger: Client application is opened.

Scenario: 1. Client application is opened and user is prompted to enter user name and password. 1.1. - The User types in its user name and password and clicks on the ‘Ok’ button.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE E PROJECT BREITENBUSH. . 1.2. - If access. is granted (correct user name and password was entered), further functionality will be available.. 1.3. - If access is not granted (incorrect user information was entered), then request user name and password again (this will continue 3 times, until user clicks on ‘Cancel’ button, or login is successful). 2. ‘Cancel’ button is clicked and application closes.

Exceptions: 1. The Login information (user name and password) is corrupted in transit Internet connection is lost. This works like failed login (see scenario 1.3). 2. Server is unavailable. User is informed using an error dialog. 3. User account does not exist. User is prompted for correct login information (see scenario 1.3).

Priority: High When available: 1.0 Frequency of use: Every time the client is opened or a session needs to be established. Channel to actor: Mouse, Keyboard and graphical user interface of the client application. Secondary actors: Server Channels to secondary actors: The Internet Open issues: Time limitations of open sessions, security of data in transit, encryption of login information and preventing multiple logins of one user.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE F PROJECT BREITENBUSH. . Logout .

Primary Actor: User Goal in context: Close all open connections to the server and close the client application. Preconditions: Client is not uploading or downloading during logout. The client application is open. Trigger: The user closes the client application, or the connection to the server was lost.

Scenario: 1. The User selects close button (Windows red X button) 1.1. - The connection to the server is closed 1.2. – The client application is closed

Exceptions: 1. If no open connection is present, the client application still closes.

Priority: High When available: 1.0 Frequency of use: Every time the client application is closed. Channel to actor: Mouse and graphical user interface of the client application. Secondary actors: Server Channels to secondary actors: The Internet Open issues: JVM problems or failures, client computer or server crashes.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE G PROJECT BREITENBUSH. . Upload .

Primary Actor: User Goal in context: The user wants to save a selected file on the remote server. Preconditions: The user has successfully logged into the system, and the Server has space available. Trigger: The user wants to save a file to a remote server.

Scenario: 1. The user is presented with a local directory structure view. 1.1. - The user selects a file from directory structure. 1.2. - The user clicks on the ‘Backup’ button. 1.3. - Clicking the button initiates the file transfer to the remote server (choosing a destination directory path is not an option for the user). Note that existing files with the same name are overwritten without warning. 1.4. - A dialog, which disables other functions of the client application, displays during the file transmission and is titled ‘File Transfer’. 1.4.1. - Upon failed completion, a dialog with an “Ok” button appears indicating the a transmission error. A successful transmission is indicated in the field “Last Backup” with a status message reading “Successful”. 1.4.2. – If an error is displayed, the user clicks the ‘Ok’ button, which closes the dialog box and re-enables the client application for further use.

Exceptions: 1. The ‘Backup’ button is disabled until a file is selected. 2. A File cannot be added to the selection list if one is already selected (i.e. only one file may be selected at a time). 3. If no connection exists, a login is attempted using existing login information, after two login failures the system errors and returns to the login screen.

Priority: High When available: 1.0 Frequency of use: Every time the user uploads a file. Channel to Actor: Mouse and graphical user interface of the client application. Secondary Actors: None. Channels to secondary actors: None. Open issues: Encryption of files, transmission errors, and storage space availability. Other issues include the ability to choose a file from the remote server.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE H PROJECT BREITENBUSH. . Download .

Primary Actor: User Goal in context: The user requests a file from a remote server. Preconditions: The user has successfully logged into the system. Trigger: The user tries to download a file from a remote server

Scenario: 1. The user is presented with a remote file listing view 1.1. - The user selects a file from the listing. 1.2. – The user clicks on the ‘Restore’ button 1.2.1. – The user also has the option to cancel the operation with the use of a button labeled, “Cancel.” 1.3. - The user is asked where on the local directory structure to save the file. This is presented in the form of a file chooser. 1.4. - Once the destination is selected, the file transfer begins. 1.5. - A dialog, which disables other functions of the client application, displays during the file transmission and shows the message ‘File Downloading’. In this dialog there is a “Cancel” button to terminate the transmission. 1.5.1. - Upon failed completion, a dialog with an “Ok” button appears indicating the failed transmission status. A successful transmission is indicated in the field “Last Restore” with a status message reading “Successful”. 1.5.2. - If an error is displayed, the user clicks the ‘Ok’ button, which closes the dialog box and re-enables the client application for further use. Exceptions: 1. The ‘Restore’ button is disabled until a file is selected 2. A file cannot be added to the selection list if one is already selected (i.e. only one file may be selected at a time). 3. An error is presented (through dialog) to the user if there is a hard drive or memory limitation. 4. If the selected file already exists in the destination directory, then the user is presented with a warning dialog asking to confirm whether it is okay to overwrite the existing file. 5. If no connection exists, a login is attempted using existing login information after two login failures the client application displays an e error and returns to the login screen.

Priority: High When available: 1.0 Frequency of use: Every time the user requests a download, Channel to actor: Mouse and graphical user interface of the client application. Secondary actors: None Channels to Secondary actors: None Open issues: Encryption of files and transmission errors.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE I PROJECT BREITENBUSH. . . Diagram .Appendix:

Login r e s Decides to Use System U

Provides Login Information n o

i Allow Further Execution t

a Login Process Denied Access Access Denied Access Granted c i l p p

A Provides Login Information Denied Granted

e m g Determine Access e a t

r Verify Login Information s o y t S S

Figure 29: Login Swimlane Diagram

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE J PROJECT BREITENBUSH. . . Logout.

Quit r

e Decides to Quit / Logout s U

Quit Request n o i t

a Application Quits c i l p p A

e m g e a t r s o y t S S

Figure 30: Logout Swimlane Diagram

Upload File

Login System Upload System r

e User Receives Notification s Decides to Upload File Login Chooses File U

File Listing File Name Notification File Upload Request Not Connected n o i

t Status Request Connected

a Detect Connection Status Request File Upload File Notify User c i l p p A File Success Failure

m File Transmissions Status g e a t Receive File r s o y t S S

Figure 31: Upload Swimlane Diagram

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE K PROJECT BREITENBUSH. . Download .

Login System Download System

r Chooses File

e Decides to Download File s Login User Receives Notification U

File Name File Download Request File Listing with Display Not Connected Notification

n Success o i Status Request Connected t File Transmissions Status Error

a Notify User

c Detect Connection Status Request File Listing Request File Request Download File Receive File i l p p

A File Listing Request File Listing File Name File Data

e m g e a t

r Returns File Listing Send File s o y t S S

Figure 32: Download Swimlane Diagram

Figure 33: State Diagram

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE L PROJECT BREITENBUSH. . .

Glossary

Word Definition Backup Backup refers to the copying of data for the purpose of having an additional copy of an original source.

Client Client (computing), a piece of software that accesses remote services from another piece of software called a server. Often (although not always) the client software and server software reside on two separate computers. Download The transfer of data (usually a file) from a server to a client. Encryption In cryptography, encryption is the process of obscuring information to make it unreadable without special knowledge. File A file in a computer system is a stream (sequence) of bits stored as a single unit, typically in a file system on disk or magnetic tape. Isolation Isolation is to store a file in a way where another user does not have access to it Login A login (also log in, log on, sign in, sign on) is the process of accessing a computer by identification of the user in order to obtain credentials to permit access. It is an integral part of computer security procedure. Logout To logout (also: log out, log out, sign out, sign out) refers to the process of ceasing use of a computer system by removing the user credentials. It is the opposite of login. MTBF Mean Time Between Failure is a failure rate expressing the average frequency with which something fails. Server A computer software application that carries out some task (i.e. provides a service) on behalf of yet another piece of software called a client.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON . THEORY OF OPERATIONS. REV. 1.0 PAGE M PROJECT BREITENBUSH. . . Links .

For our design document please follow this link.

http://lewis.up.edu/EGR/SRDesign06/breitenbush/documents.htm

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: P JOHNSTON