Journal

This journal provides a day-by-day account of the work done on the project. We hope that this will help to differentiate between the process used for the project and the artifacts produced. The journal is organized by time-boxed iterations and then by date within the iterations. The journal is in first-person because that seems easier to relate to. Your narrator is Curt until Oct 25, 2002, and Gary after that.

  1. Inception
  2. Elaboration, Iteration 1
  3. Elaboration, Iteration 2

Inception, Aug. 28-Sep.6, 2002

Aug. 28

Gary and I discussed the inception phase of the project and what artifacts are needed in very general terms.

Aug. 29-30

I spent these days reading the first seven chapters of Larman.

Sept. 3

Gary and I decided that the artifacts for the inception phase would include a partial set of use cases, with only a few done in the fully dressed form. Other artifacts started during inception will include a vision and business case, supplementary specification, a risk list, and a glossary.

I worked on the web page for the project. This work could be considered part of the Environment discipline in the Unified Process. The homepage of the project can also be seen as a first draft summary of the Vision artifact.

I worked on finding primary actors, goals, and use cases, following the procedure given by Larman in section 6.9.

I made some notes on the system boundary, determining that the inside of the system is just the software itself and that the primary actor is the user of the software. Supporting actors are the PC and Macintosh file systems. This information will be used to develop the vision and business case and the supplementary specification.

I also sketched out the goals of the software user. These goals will be used to define the use cases.

Sept. 4

Today I formatted the web pages for the artifacts to more closely follow the templates used by Larman. I worked on transferring the notes I made yesterday into the appropriate places in the artifacts.

When considering reliability requirements I realized I had been operating on the assumption that a single PMSD would be used repeatedly. That should not be a requirement.

I spent (too much) time futzing with the style sheet to get the fully dressed use cases to look decent.

I began writing the fully dressed use case Add File. While doing this I realized that several other supplementary use cases were needed (see Larman, p. 60, Reasonable Violations of the EBP Guideline). I added their titles to the use case table. Also while writing the fully dressed use case I identified several additional terms that I added to the glossary.

Sept. 5

Finished dressing the Add File use case. Wrote a few casual and brief use cases. Chose to leave others as title-only for inception. Roughed in most of the sections of the vision and supplementary specification.

Elaboration, Iteration 1, Sept. 17-Oct. 25, 2002

Sept. 17

Gary added some more risks based on the classroom discussion from Sept. 16.

Oct. 4

Gary fleshed out a bit of the supplementary specifications while preparing lecture notes.

Oct. 7

Gary and I (with input from the class) decided on the use cases for the first elaboration iteration. We will implement the main success scenarios for Add File, Propagate File Change, Start System, Stop System, Select PMSD, and Select Synchronization Partner. These cases cover the highest risks in the project and provide sufficient coverage to get the basic architecture of the system in place.

Oct. 9

Gary changed the "Propagate File Change" use case to follow the EBP guidelines, and to not have conditionals within a scenario. These correspond to changes discussed in class. Gary also took out of the use cases "Select PMSD" and "Select Synchronization Partner" events that happen before the use case starts and events that are outside the system boundary (mount PMSD, start system). He added a "CRUD" use case for managing synchronization partners, which is needed because these have to be tracked on the PMSD.

Oct. 11

Gary made various changes that arose from looking at the documents more carefully in the course of grading student projects. He changed the vision to be more complete, and to recognize the interests of the manufacturers. He separated out the identification of the stakeholders from their goals. He added a context diagram. He changed the supplementary specification, so that it moved the Java requirement to development constraints, and tried to give more detail.

Oct. 14

Gary and I revised the Propagate File Change use case to clarify some items. The original inception phase version had an error. We were considering a sequence of actions that were spread over two physical locations as a single use case. This violated the elementary business processes guideline discussed by Larman in chapter 6. The revision now make clear that Propagate File Change happens at a single location.

Because StickSync is intended as an example project we decided to revise the inception version of the use case model to include the updated Propagate File Change use case. Normally the change would just be made to the current version of the artifact. However, before the first elaboration iteration is completed we will be fully dressing this use case. We thought it was important for students to have access to a correct example of a casual format use case. By revising the inception version of the use case model artifact we can provide such an example.

We decided that this iteration would only include the command-line interface to the system. The GUI will wait until a later iteration.

I added the domain model and improved the context diagram. I dressed the use cases that are part of this iteration.

Oct. 15

Gary wrote initial drafts of the casual and brief format use cases for this iteration. These are the use cases we don't plan to implement in this iteration. They represent requirements elaboration work for the iteration.

Gary and I decided to add an alternative scenario (Propagate File Change, alternative 2b) to this iteration. This gives us a system sequence diagram with more than one message in each direction, pursuant to our goal that StickSync be a good example. Adding this alternative scenario also allows us to address the file merge risk in this early iteration.

Gary and I discussed the domain model and decided that, given the additional fully dressed use cases, there are probably some conceptual classes missing. We plan to discuss this with the class on Wednesday.

I added system sequence diagrams for the use cases to be implemented in this iteration. I also added a partial use case context diagram.

We extended the iteration until Oct. 25. Normally breaking a time box in this way is not allowed. However, if we cut the scope of the iteration sufficiently to complete it on time, then we would be left with an example that wasn't useful to students when completing homeworks 4 and 5.

Oct. 16

I updated the use case context diagram based on a suggestion from Gary. It was a bit of a stretch to call the Synchronization Partnership an actor. Considering the PMSD and computer as actors is also slightly suspect, since they are not active participants. But we decided to keep them in the diagram as it makes the system boundary clearer.

I revised the domain model per our discussion in class today, but with a few changes. A student (sorry, I don't know your name) questioned the association I had drawn from 1 FilePairing to 2 Files. This reflects a common confusion between File and Location. I decided it was clearer to separate these concepts. I also realized that a PMSD itself has a directory associated with it, since it behaves just like a hard drive. Finally, I noted that a FilePairing actually should be accompanied by an actual File so that the PMSD can transport the changes.

Also based on the class discussion I added a new risk regarding time stamps on directories.

I cleaned up the use cases Remove File, Remove Directory, and Propagate Directory Change that referred to the status of the remote computer. This cannot be determined accurately by the System but can only be inferred based on information stored on the PMSD. I also corrected a problem with the Change File Location use case to eliminate a potential source of confusion.

I added a table of synchronization rules to the supplemental specification that describes the appropriate action for synchronizing a file based on time stamps. I also added a state diagram and discussion to demonstrate how the rules were calculated (and perhaps a reason why Com S 330 is valuable -grin-).

Oct. 21

Gary and I decided to add an association between Computer and PMSD on the domain model. We decided on the directory structure and tools for testing and coding and a plan for completing the first elaboration iteration.

Oct. 22

Gary and I worked out the interaction diagrams for the main success scenario and alternate scenario 2b of Propagate File Changed. We made some progress on the design class diagram.

I completed the interaction diagrams for this iteration (see links from the use case model). I also added significant detail to the design class diagram, which is now linked from the sidebar.

Oct. 25, 2002

We began coding today. In the process we realized that the distinction between File and Location is false. We can just use location. However, the contents of a given location may not be accessible since the location may refer to a file on the remote computer.

Oct. 26 to November 14, 2002

Coding continued. We learned several things about serialization. Started to use the flyweight pattern in Computer. Testing proves difficult and is not completed.

January 2003

Gary takes over maintenance of the web pages.

April 8, 2003

Gary fixes up the web pages so that they will print nicely, by using Curt's earlier work (elsewhere) on XHTML formatting and style sheets.

Elaboration, Iteration 2, started Aug. 27, 2003

August 27, 2003

Gary finally is able to get Omondo's EclipseUML reverse engineering feature to work with the 2.1.1 version of Eclipse. This allows him to generate a UML class diagram from the source code, for use in further iterations.

September 16, 2003

Dalei Li sent Gary some new use cases dealing with recovery from faulty PMSDs. These were the result of some work by Dalei Li, and conversations between him and Gary about what to do with faulty PMSDs. It was decided that the simpliest course of action is to provide a way to backup PMSDs and restore the backups. Today Dalei Li, Brett Graves, and Gary sat down and edited these new use cases, as well as a new use case (in casual format) for Change Directory Location. Gary also does the work needed to archive elaboration 1, and edits the vision page (hoping to stop students from copying various features of the vision page that he has grown tired of...). He hopes it's not too late for that. He makes some other small revisions as well to various pages.

October 6, 2003

Gary makes a few minor revisions to the use cases.

October 19, 2003

Gary corrects the version dates in the style files, and performance requirements to the supplementary specification, and draws a new startSystem system sequence diagram.

October 23, 2003

Gary updates the jar files, and a small correction to the TestComputer class which had a copy/paste error. There is still one test case that is failing.

October 8, 2004

Gary removes material on "sticksync as an example" from the vision, after getting yet more tired of seeing students saying similar things in their visions. Now the vision is more straightforward as an example, and all meta content is moved to the index page.

Return to top

Last modified Friday, October 8, 2004.

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 `.').