Current Version: Elaboration Iteration 2, Started 8/27/2003
Elaboration Iteration 1, Completed 11/14/2002
Inception, Completed 9/5/2002
Use Case Model
This is the use case model for the StickSync project. The following table shows the use cases we have identified. Each title links to the corresponding use case. The status column indicates the current status of the use case. The SSDs column links to System Sequence Diagrams. The IDs column links to Interaction Diagrams. A use case context diagram follows the table.
Title | Status | SSDs | IDs |
---|---|---|---|
Add File | fully dressed | Main | Main |
Propagate File Change | fully dressed | Main, Alt 2b | Main, Alt 2b |
Remove File | casual | ||
Add Directory | brief | ||
Remove Directory | brief | ||
Propagate Directory Change | brief | ||
Change File Location | casual | ||
Change Directory Location | casual | ||
Start System | fully dressed | Main | Main |
Stop System | fully dressed | Main | Main |
Select PMSD | fully dressed | Main | Main |
Select Synchronization Partner | fully dressed | Main | Main |
Manage Synchronization Partners | casual | ||
Backup PMSD | brief | ||
Restore to PMSD | brief |
Here is a partial use case context diagram, showing the fully dressed use cases.
Add File
Primary Actor
User
Stakeholders and Interests
- User: Wants to begin synchronizing a file that is not being synchronized prior to this scenario.
Preconditions
The local computer contains a file the User wants to be synchronized. User has selected a PMSD and synchronization partner. (See use cases Select PMSD and Select Synchronization Partner.)
Postconditions
System "knows" the file is to be synchronized to a particular synchronization partner via the selected PMSD.
Main Success Scenario
1. User selects a file to be synchronized.
2. System verifies that the file selected is indeed readable and writeable by the User.
3. System records that the file is to be synchronized to the selected synchronization partner via the selected PMSD.
4. System informs User of success.
Extensions
2a. System detects that user does not have permission to read file.
1. System informs user of permission problem.
2. Use case ends.
2b. System detects that user does not have permission to write file.
1. System warns user that he/she may not be able to synchronize changes made on the synchronization partner to the local computer.
Technology and Data Variations List
1a. File selected by drag-and-drop graphical user interface.
Frequency of Occurence
Sporadic. Simultaneous executions of Add File are not possible, since data structures used by the system are assumed to be locked.
Propagate File Change
Primary Actor
User
Stakeholders and Interests
- User: Wants to synchronize changes between a file on the local computer and a file on a PMSD.
Preconditions
User has selected a PMSD and synchronization partner. (See use cases Select PMSD and Select Synchronization Partner.) The PMSD contains a file to be synchronized. (See use case Add File.)
Postconditions
The selected file on the local computer is synchronized to corresponding file on the PMSD.
Main Success Scenario
1. User requests synchronization for a file that was previously added to the selected PMSD for the selected synchronization partner.
2. System determines that the local computer's version of the file has changed since it was last synchronized (with the selected PMSD and synchronization partner), and that the version of the file recorded on the PMSD has not changed since it was last synchronized with the local computer.
3. System records the contents and last modification time of the local computer's file on the PMSD.
4. System reports status of the file to User.
Extensions
2a. System determines that the local computer's version of the file has not changed since it was last synchronized (with the selected PMSD and synchronization partner), but the version of the file recorded on the PMSD has changed since it was last synchronized with the local computer.
1. System informs user that there are changes to be applied to the local computer's file.
2. User requests that changes to the file be applied.
2a. User requests that changes to the file not be applied.
1. Use case ends.
3. System applies the changes recorded on the PMSD to the local computer's file.
2b. System determines that the local computer's version of the file has changed since it was last synchronized (with the selected PMSD and synchronization partner), and that the version of the file recorded on the PMSD has also changed since it was last synchronized with the local computer.
1. System asks the user if they would like to merge the changes.
2. User requests that the changes be merged.
2a. User requests that the changes not be merged.
1. Use case ends.
3. System combines the changes into the file on the local computer.
3a. System cannot combine the changes into a single file.
1. System write the PMSD version of the file to the same directory as the local computer's file, using a different unique file name.
2. System informs the User that the files could not be merged.
2c. System determines that the local computer's version of the file has not changed since it was last synchronized (with the selected PMSD and synchronization partner), and that the version of the file recorded on the PMSD has also not changed since it was last synchronized with the local computer.
1. System informs User that there is nothing to be done for the selected file.
2d. System does not have a record of the location of the selected file on the local computer (for the given PMSD and synchronization partner).
1. System asks User to select a location on the local computer.
2. User selects a location.
2a. User cancels change propagation.
1. Use case ends.
3. System records the location on the PMSD and writes the file to the selected location on the local computer.
3a. System determines that User does not have permission to write to the selected location.
1. System informs User.
Repeat alternate scenario 2d.
3a. System determines that the file will not fit on the PMSD.
1. System informs user.
2. Use case ends.
Special Requirements
System should display synchronization status for all files on the selected PMSD for the selected synchronization partner.
Frequency of Occurence
Sporadic. Simultaneous executions of Propagate File Change are not possible, since data structures used by the system are assumed to be locked.
Remove File
Main Success Scenario
On the local computer, the User tells the System to no longer synchronize a selected file for the current synchronization partner and the current PMSD. The system verifies that the file has been recorded for synchronization with the currently selected synchronization partner and PMSD and that the version of the file recorded on the PMSD has not changed since it was last synchronized with the local computer. The System then removes the information recorded for that file and synchronization partner on the currently selected PMSD.
Alternate Scenarios
If the selected file has not been previously recorded for synchronization with the selected synchronization partner on the selected PMSD, then the System tells the user about this. The use case then ends.
If the version of the file recorded on the PMSD has changed since it was last synchronized with the local computer, then the System tells the user about the unsynchronized change. The user requests synchronization, and the the file is synchronized as in Propagate File Change. The use case ends without removing the file.
If the version of the file recorded on the PMSD has changed since it was last synchronized with the local computer, then the System tells the user about the unsynchronized change. The user confirms that they do not want synchronization for this file. The System then removes the information recorded for that file and synchronization partner on the currently selected PMSD.
Add Directory
On the local computer, the User selects a directory to be synchronized with the currently selected synchronization partner on the currently selected PMSD. The System verifies that the directory exists and is readable and writeable by the User. The System records that the directory is to be synchronized with the synchronization partner on the selected PMSD.
Remove Directory
On the local computer, the User tells the System about a directory that should no longer be synchronized with the currently selected synchronization partner on the currently selected PMSD. The system verifies that the directory has been recorded for synchronization with the currently selected synchronization partner and PMSD and that the version of the file recorded on the PMSD has not changed since it was last synchronized with the local computer. The System then removes the information recorded for that directory and synchronization partner on the currently selected PMSD.
Propagate Directory Change
On the local computer, the User asks for synchronization for a directory with the currently selected synchronization partner and PMSD. The system verifies that the directory has not changed on the local computer since it was last synchronized, and that the version of some of the files or subdirectories contained in the specified directory and recorded on the PMSD have changed since it was last synchronized with the local computer. The System synchronzies the directory by copying the changes from the PMSD to the directory on the local computer.
Change File Location
Main Success Scenario
The User selects a file that has been recorded for synchronization on the selected PMSD for the currently selected synchronization partner. The User gives a new location for this file on the local computer. The System verifies that this location exists and that the file can be read and written at this location. The System records the new location for this file for the selected synchronization partner on the selected PMSD.
Alternate Scenarios
If the new location for the file does not exist, then the System verifies that the file can be written into this location, and asks the User if they would like to create the file from the version stored on the PMSD based on the information from the remote computer. The User confirms this. The System records the new location for this file and then creates the file from the version stored on the PMSD based on the information from the remote computer.
If the new location exists and the file can be read but not written in this location, then the System asks the User if they would like to record the new location on the PMSD anyway. The User tells the System not to record the information, and the use case ends.
If the new location exists and the file can be read but not written in this location, then the System asks the User if they would like to record the new location on the PMSD anyway. The User tells the System to record the information anyway, and the System does so. (This is useful because the User may be planning to synchronize a read-only file that they do not plan on editing on either computer.)
If the new location for the file does not exist, and the file cannot be written into this location, then the System informs the User, and the use case ends.
Change Directory Location
Main Success Scenario
The User selects a directory that has been recorded for synchronization on the selected PMSD for the currently selected synchronization partner. The User gives a new location for this directory on the local computer. The System verifies that this location exists and that the directory can be read and written at this location. The System records the new location for this directory for the selected synchronization partner on the selected PMSD.
Alternate Scenarios
If the new location for the directory does not exist, then the System verifies that the directory can be written into this location, and asks the User if they would like to create the directory from the version stored on the PMSD based on the information from the remote computer. The User confirms this. The System records the new location for this directory and then creates the directory from the version stored on the PMSD based on the information from the remote computer.
If the new location exists and the directory can be read but not written in this location, then the System asks the User if they would like to record the new location on the PMSD anyway. The User tells the System not to record the information, and the use case ends.
If the new location exists and the directory can be read but not written in this location, then the System asks the User if they would like to record the new location on the PMSD anyway. The User tells the System to record the information anyway, and the System does so. (This is useful because the User may be planning to synchronize a read-only file that they do not plan on editing on either computer.)
If the new location for the directory does not exist, and the directory cannot be written into this location, then the System informs the User, and the use case ends.
Start System
Primary Actor
User
Stakeholders and Interests
- User: wants to use System
Preconditions
System is installed on the local computer.
Postconditions
System is running on the local computer.
Main Success Scenario
1. User launches application implementing System.
2. System starts.
Special Requirements
May want to have System automatically start when a PMSD storing System data is connected to the local computer.
Frequency of Occurence
Sporadic.
Stop System
Primary Actor
User
Stakeholders and Interests
- User: is finished using the System for the present time
Preconditions
System is running.
Postconditions
System is stopped.
Main Success Scenario
1. User tells System to stop.
2. System stops.
Frequency of Occurence
Once per execution of use case Start System.
Select PMSD
Primary Actor
User
Stakeholders and Interests
- User: wants to use a specific PMSD to synchronize data between the local computer and some remote computer
Preconditions
System is started (see use case Start System) and PMSD is mounted on the local computer.
Postconditions
System in state where a specific PMSD is selected.
Main Success Scenario
1. User requests selection of PMSD.
2. System reports the PMSDs mounted on the local computer.
3. User selects PMSD.
4. System records User's selection.
Extensions
2a. System does not detect any PMSDs mounted on the local computer.
1. System informs User of the problem.
2. System asks User to identify drive letter or mount point corresponding to a PMSD.
3. User identifies drive letter or mount point corresponding to a PMSD.
3a. User cancels PMSD selection.
1. Use case ends.
4. System records identification file in the root of the directory structure of the given drive letter or mount point.
Special Requirements
The System must record a special identification file in the root of the directory structure of each PMSD used by the System. This identification file allows the System to detect which mounted volumes are PMSDs. The file may also store the data structures used by the System for recording synchronization partners, files, and directories.
Select Synchronization Partner
Primary Actor
User
Stakeholders and Interests
- User: wants to synchronize files between the local computer and some remote computer
Preconditions
System is started and a PMSD has been selected (see use cases Start System and Select PMSD).
Postconditions
System in state where a particular synchronization partner is selected.
Main Success Scenario
1. User requests selection of synchronization partner.
2. System reports the configured synchronization partners for the local computer.
3. User selects a synchronization partner.
4. System records User's selection.
Extensions
2a. System detects that no synchronization partners are available for the local computer.
1. System reports problem to User.
2. Use case ends. (See use case Manage Synchronization Partners.)
Special Requirements
We need some mechanism of identifying the local computer. This is complicated by Java's OS-nostic file system API. One option is to store a properties file in some well-defined location on the local computer. This file would record the computer's name.
Manage Synchronization Partners
Main Success Scenario
The User tells the system to create a new synchronization partnership for the currently selected PMSD. The User names a remote computer that the local computer will partner with. The System verifies that this is not an existing synchronization partnership and records it on on the selected PMSD.
Alternate Scenarios
If the synchronization partnership to be created already exists, then the System informs the user of this and the use case ends.
The User tells the system to delete an existing synchronization partnership for the currently selected PMSD. The System verifies that there are no unsynchronized changes for this synchronization partnership, and removes its information from the selected PMSD.
If the synchronization partnership to be deleted has unsynchronized changes, then the System tells the user about these changes. The User cancels the deletion and the use case ends.
If the synchronization partnership to be deleted has unsynchronized changes, then the System tells the user about these changes. The User decides to delete the synchronization partnership anyway, and the System removes its information from the selected PMSD.
Backup PMSD
The User asks the sytem to do a backup operation for the currently selected PMSD. The system asks User where to put the backup files. The User tells the System the location. The System checks that this location is either a new PMSD or a new file on the local computer. The System next asks the User which synchronization partnerships and files on the current PMSD the User wants to back up. The User tells the System to back up all of them. The System successfully copies the partnership and file information to the given location, and the use case ends.
Restore to PMSD
The User tells the System they want to recover from a backup file on the local computer to the currently selected PMSD. The System asks for the location of the backup file. The User tells the System the location. The System asks what synchronization partnerships and files to restore from this backup. The User tells the system to restore all of them. The System checks that there is no synchronization information on the selected PMSD, and that it has enough room to store the information contained in the given backup location. The System copies the backup information to the selected PMSD.
Last modified Monday, October 6, 2003.
This web page is for the StickSync project, developed as an example for Com S 362 at Iowa State University. Please direct any comments or questions about this project to Gary T. Leavens at leavens@cs-DOT-iastate-DOT-edu or Curtis Clifton at cclifton@cs-DOT-iastate-DOT-edu (after replacing -DOT- with `.').