CSC/ECE 517 Spring 2013/FINAL PROJECT E736 UNDO - Revision history

Mcao2: /* Design Patterns and Designs */

2013-04-02T02:40:35Z

Design Patterns and Designs

← Older revision		Revision as of 02:40, 2 April 2013
Line 29:		Line 29:
	*Memento		*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 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.		**The Memento pattern will be followed through open-source Ruby gems leveraged by the project.

Mcao2: /* Design Patterns and Designs */

2013-04-02T02:40:18Z

Design Patterns and Designs

← Older revision		Revision as of 02:40, 2 April 2013
Line 28:		Line 28:
	**"Don't Repeat Yourself" practice will be followed.		**"Don't Repeat Yourself" practice will be followed.
	*Memento		*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 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 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.		**The Memento pattern will be followed through open-source Ruby gems leveraged by the project.

Mcao2: /* Design Patterns and Designs */

2013-04-02T02:39:41Z

Design Patterns and Designs

← Older revision		Revision as of 02:39, 2 April 2013
Line 29:		Line 29:
	*Memento		*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 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.		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.
	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.		**The Memento pattern will be followed through open-source Ruby gems leveraged by the project.

Mcao2: /* Design Patterns and Designs */

2013-04-02T02:39:16Z

Design Patterns and Designs

← Older revision		Revision as of 02:39, 2 April 2013
Line 28:		Line 28:
	**"Don't Repeat Yourself" practice will be followed.		**"Don't Repeat Yourself" practice will be followed.
	*Memento		*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.		**The Memento pattern will be followed through open-source Ruby gems leveraged by the project.

Ctsui: /* E736. Undo Functionality for Expertiza */

2013-04-02T00:57:16Z

E736. Undo Functionality for Expertiza

← Older revision		Revision as of 00:57, 2 April 2013
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)

Kbyarbor: /* Functional Testing Plans */

2013-04-02T00:44:09Z

Functional Testing Plans

← Older revision		Revision as of 00:44, 2 April 2013
Line 54:		Line 54:

	=== Functional Testing Plans ===		=== Functional Testing Plans ===
	*one		*The following functional test plans will be followed for all items enhanced with the Undo functionality:
	*~~two~~		**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.

Kbyarbor: /* Expected Functional Tests to Include */

2013-04-02T00:39:56Z

Expected Functional Tests to Include

← Older revision		Revision as of 00:39, 2 April 2013
Line 53:		Line 53:
	*All test methods shall be named with an appropriately descriptive name that is not too long.		*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~~		*one
	**User successfully undoes his/her action on various models(Course, Assignment, etc).		*two
	*Sad path
	**User is unable to undo, due to reasons as
	***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.

Kbyarbor: /* Expected Unit Tests to Include */

2013-04-02T00:37:49Z

Expected Unit Tests to Include

← Older revision		Revision as of 00:37, 2 April 2013
Line 48:		Line 48:
	*More classes may be covered as time allows.		*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 ===		=== Expected Functional Tests to Include ===

Kbyarbor: /* Expected Classes to be Modified */

2013-04-02T00:35:06Z

Expected Classes to be Modified

← Older revision		Revision as of 00:35, 2 April 2013
Line 46:		Line 46:
	*Assignment-related Classes		*Assignment-related Classes
	*Course-related Classes		*Course-related Classes
	*More classes may be ~~added~~ as time allows.		*More classes may be covered as time allows.

	=== Expected Unit Tests to Include ===		=== Expected Unit Tests to Include ===

Kbyarbor: /* Expected Classes to be Modified */

2013-04-02T00:34:45Z

Expected Classes to be Modified

← Older revision		Revision as of 00:34, 2 April 2013
Line 44:		Line 44:

	=== Expected Classes to be Modified ===		=== Expected Classes to be Modified ===
	*~~Course~~		*Assignment-related Classes
	*~~Assignment~~		*Course-related Classes
	*~~etc~~		*More classes may be added as time allows.

	=== Expected Unit Tests to Include ===		=== Expected Unit Tests to Include ===