Current Version: 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.

A List of Use Cases for the StickSync Project
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 title only
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
Replace Faulty PMSD title only

Here is a partial use case context diagram, showing the fully dressed use cases.

Use Case Context Diagram

Return to top

Add File

Primary Actor

User

Stakeholders and Interests

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.

Return to top

Propagate File Change

Primary Actor

User

Stakeholders and Interests

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

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 via use case Add File.

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.

Return to top

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.

Return to top

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.

Return to top

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.

Return to top

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.

Return to top

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.

Return to top

Change Directory Location

Return to top

Start System

Primary Actor

User

Stakeholders and Interests

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.

Return to top

Stop System

Primary Actor

User

Stakeholders and Interests

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.

Return to top

Select PMSD

Primary Actor

User

Stakeholders and Interests

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.

Return to top

Select Synchronization Partner

Primary Actor

User

Stakeholders and Interests

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.

Return to top

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.

Return to top

Replace Faulty PMSD

Return to top

Last modified Tuesday, September 16, 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 `.').