CSC/ECE 517 Spring 2013/FINAL PROJECT E736 UNDO: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(16 intermediate revisions by 3 users not shown)
Line 5: Line 5:
**Suppose an instructor is trying to roll back and a TA is editing the same assignment?  How can conflicts be presented?
**Suppose an instructor is trying to roll back and a TA is editing the same assignment?  How can conflicts be presented?
**Do rollbacks affect only what's in the db, or do they also affect submitted files?
**Do rollbacks affect only what's in the db, or do they also affect submitted files?
 
*[https://docs.google.com/a/ncsu.edu/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/ Project Description Doc]
== Team Members ==
== Team Members ==
*Chun Sing Tsui (ctsui@ncsu.edu)
*Chun Sing Tsui (ctsui@ncsu.edu)
*Kenny Yarboro (kbyarbor@ncsu.edu)
*Kenny Yarboro (kbyarbor@ncsu.edu)
*Meng Cao (mcao2Wncsu.edu)
*Meng Cao (mcao2@ncsu.edu)
*Travis Folsom (twfolsom@ncsu.edu)
*Travis Folsom (twfolsom@ncsu.edu)


Line 22: Line 22:
*Assignments
*Assignments
*Courses
*Courses
*etc...
*More items may be covered if time allows.


=== Design Patterns and Designs ===
=== Design Patterns and Designs ===
*DRY
*DRY
**don't repeat code...
**"Don't Repeat Yourself" practice will be followed.  
*Memento
*Memento
**reason one...
**The memento pattern is a software design pattern that provides the ability to restore an object to its previous state (undo via rollback). The memento pattern is implemented with two objects: the originator and a caretaker. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation (or sequence of operations) it was going to do. To roll back to the state before the operations, it returns the memento object to the originator. The memento object itself is an opaque object (one which the caretaker cannot, or should not, change). When using this pattern, care should be taken if the originator may change other objects or resources - the memento pattern operates on a single object. Classic examples of the memento pattern include the seed of a pseudorandom number generator (it will always produce the same sequence thereafter when initialized with the seed state) and the state in a finite state machine.
**The Memento pattern will be followed through open-source Ruby gems leveraged by the project.


=== Frameworks to Leverage ===
=== Frameworks to Leverage ===
*Paper Trail(https://github.com/airblade/paper_trail)
*Paper Trail(https://github.com/airblade/paper_trail)
**PaperTrail lets you track changes to your models' data. It's good for auditing or versioning. You can see how a model looked at any stage in its lifecycle, revert it to any version, and even undelete it after it's been destroyed.
**PaperTrail allows for tracking changes to model data.  
**There is a Railscast shows how to implement undo feature with Paper Trail
***Good for auditing or versioning.  
**It is ranked as the most popular framework for Active Record versioning feature in [https://www.ruby-toolbox.com/categories/Active_Record_Versioning here]
**Offers many functionalities including:
*Alternative Frameworks are listed [https://www.ruby-toolbox.com/categories/Active_Record_Versioning here].
****Viewing a model at any stage in its lifecycle.
****Reverting a model to any version.
****Undeleting items after they have been destroyed.
**Compatible with Rails-2.3.15, which is the version Expertiza uses.  
**There is a [http://railscasts.com/episodes/255-undo-with-paper-trail Railscast] showing how to implement the undo feature with Paper Trail.
**Ranked as the most popular framework for Active Record versioning feature in [https://www.ruby-toolbox.com/categories/Active_Record_Versioning here]
**Alternative Frameworks are listed [https://www.ruby-toolbox.com/categories/Active_Record_Versioning here].


=== Expected Classes to be Modified ===
=== Expected Classes to be Modified ===
*class one...
*Assignment-related Classes
*Course-related Classes
*More classes may be covered as time allows.


=== Expected Unit Tests to Include ===
=== Unit Testing Plans ===
*at least one per method...
*Every class method modified will be tested via unit test.
*Every new method added will be tested via at least one unit test.  
*All test methods shall be named with an appropriately descriptive name that is not too long.


=== Expected Functional Tests to Include ===
=== Functional Testing Plans ===
*Happy Path
*The following functional test plans will be followed for all items enhanced with the Undo functionality:
**User successfully undoes his/her action on various models(Course, Assignment, etc).
**Test that an item may be changed, then undo performed successfully.
*Sad path
**Test that a sequence of changes may be performed by one user, then undo performed successfully for each action from the sequence.  
**User is unable to undo, due to reasons as
**Test that an item may be changed by one user, changed again by another user, then undo performed by the original user will display a failure message with description.
***user has no privilege to the undo action: a student can't undo his/her submission after due date.
***some other user is editing the same item at the same time.

Latest revision as of 02:40, 2 April 2013

E736. Undo Functionality for Expertiza

  • Contacts: Ed Gehringer (efg@ncsu.edu) and Andrew Kofink (ajkofink@ncsu.edu)
  • Begin implementing SQL transactions (ActiveRecord:Transactions). This should let the user "roll back" any creation or update of a SQL table (assignments, rubrics, etc.) Several issues arise, that you should discuss with me.
    • Should students be able to roll back, e.g., submissions or reviews?
    • Suppose an instructor is trying to roll back and a TA is editing the same assignment? How can conflicts be presented?
    • Do rollbacks affect only what's in the db, or do they also affect submitted files?
  • Project Description Doc

Team Members

  • Chun Sing Tsui (ctsui@ncsu.edu)
  • Kenny Yarboro (kbyarbor@ncsu.edu)
  • Meng Cao (mcao2@ncsu.edu)
  • Travis Folsom (twfolsom@ncsu.edu)

Design Document

Overview of Undo Functionality

  • Undo should cover any edit functionalities and any submissions of links. File submissions do not need to be included for the scope of this project.
  • User should be able to undo any changes to an item (such as course or assignment) as long as no other user has edited that same item within the user's current session.
  • If undo is attempted on an item already modified by another user, display a message stating why undo cannot be done.

List of Items to be Supported by Undo Functionality

  • Assignments
  • Courses
  • More items may be covered if time allows.

Design Patterns and Designs

  • DRY
    • "Don't Repeat Yourself" practice will be followed.
  • Memento
    • The memento pattern is a software design pattern that provides the ability to restore an object to its previous state (undo via rollback). The memento pattern is implemented with two objects: the originator and a caretaker. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation (or sequence of operations) it was going to do. To roll back to the state before the operations, it returns the memento object to the originator. The memento object itself is an opaque object (one which the caretaker cannot, or should not, change). When using this pattern, care should be taken if the originator may change other objects or resources - the memento pattern operates on a single object. Classic examples of the memento pattern include the seed of a pseudorandom number generator (it will always produce the same sequence thereafter when initialized with the seed state) and the state in a finite state machine.
    • The Memento pattern will be followed through open-source Ruby gems leveraged by the project.

Frameworks to Leverage

  • Paper Trail(https://github.com/airblade/paper_trail)
    • PaperTrail allows for tracking changes to model data.
      • Good for auditing or versioning.
    • Offers many functionalities including:
        • Viewing a model at any stage in its lifecycle.
        • Reverting a model to any version.
        • Undeleting items after they have been destroyed.
    • Compatible with Rails-2.3.15, which is the version Expertiza uses.
    • There is a Railscast showing how to implement the undo feature with Paper Trail.
    • Ranked as the most popular framework for Active Record versioning feature in here
    • Alternative Frameworks are listed here.

Expected Classes to be Modified

  • Assignment-related Classes
  • Course-related Classes
  • More classes may be covered as time allows.

Unit Testing Plans

  • Every class method modified will be tested via unit test.
  • Every new method added will be tested via at least one unit test.
  • All test methods shall be named with an appropriately descriptive name that is not too long.

Functional Testing Plans

  • The following functional test plans will be followed for all items enhanced with the Undo functionality:
    • Test that an item may be changed, then undo performed successfully.
    • Test that a sequence of changes may be performed by one user, then undo performed successfully for each action from the sequence.
    • Test that an item may be changed by one user, changed again by another user, then undo performed by the original user will display a failure message with description.