Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-22T01:59:23Z

Kanke: /* '''''References''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by Bertrand Meyer [3][4], and later laid down in details by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. [http://en.wikipedia.org/wiki/Software_maintenance Maintainability]. There is no need to maintain reused code. This is done by the owner of the reused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several [http://en.wikipedia.org/wiki/Software_versioning versions] of the code, as well as large [http://en.wikipedia.org/wiki/Software_package_%28installation%29 packages]. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best [http://en.wikipedia.org/wiki/Software_design design] philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique describes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other principles, REP.

A "bad" example of not following REP is to reuse code by copying the source code. Just a few days after Microsoft released its Windows 7 operating system, it had to apologize to the public for violating the [http://en.wikipedia.org/wiki/Gpl GPL] license.[5] A utility tool it hired the third party to develop contains a chunk of open source code with a [http://en.wikipedia.org/wiki/Gpl GPL] license attached to it. Microsoft had to open its own source code for this utility program.

Copying source code can bring not only embarrassment, but also lawsuit. In 2003, Cisco filed a lawsuit against Huawei, its competitor in the swtich and router market, for alleged theft. Cisco said "portions of its IOS source code found its way into Huawei's operating system for its Quidway routers and switches. Cisco claimed the Huawei OS included text strings, files names and bugs that were identical with Cisco's IOS source code. The suit alleges that Huawei is infringing at least five Cisco patents".[6]

=='''''Conclusion'''''==

Code should be reused by including the released [http://en.wikipedia.org/wiki/Software_library library], not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact, the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release.

The users of the library need to know the version/signature for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system.

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author of related classes and collectively make them a large functional unit or package. The REP is targeting a wide audience who are more interested in reuse of a large functional unit or a class in that context. Keeping track of versions of individual classes would be, more often than not, burdensome to users who both use multiple classes within the same package and authors who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package.

REP not only applies to external users, but also applies within the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988 
[5] Microsoft will open source Windows 7 tool that includes GPL code: http://www.infoworld.com/d/windows/microsoft-will-open-source-windows-7-tool-includes-gpl-code-442
[6] http://www.theregister.co.uk/2003/01/24/cisco_sues_huawei_over_ip/

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-22T01:58:46Z

Kanke: /* '''''Example''''' */

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-22T01:57:31Z

Kanke: /* '''''Example''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by Bertrand Meyer [3][4], and later laid down in details by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. [http://en.wikipedia.org/wiki/Software_maintenance Maintainability]. There is no need to maintain reused code. This is done by the owner of the reused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several [http://en.wikipedia.org/wiki/Software_versioning versions] of the code, as well as large [http://en.wikipedia.org/wiki/Software_package_%28installation%29 packages]. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best [http://en.wikipedia.org/wiki/Software_design design] philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique describes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other principles, REP.

A "bad" example of not following REP is to reuse code by copying the source code. Just a few days after Microsoft released its Windows 7 operating system, it had to apologize to the public for violating the [http://en.wikipedia.org/wiki/Gpl GPL] license.[5] A utility tool it hired the third party to develop contains a chunk of open source code with a [http://en.wikipedia.org/wiki/Gpl GPL] license attached to it. Microsoft had to open its own source code for this utility program.

"Copying" can bring not only embarrassment, but also lawsuit. In 2003, Cisco filed a lawsuit against Huawei, its competitor in the swtich and router market, for alleged theft. Cisco said "portions of its IOS source code found its way into Huawei's operating system for its Quidway routers and switches. Cisco claimed the Huawei OS included text strings, files names and bugs that were identical with Cisco's IOS source code. The suit alleges that Huawei is infringing at least five Cisco patents".[6]

=='''''Conclusion'''''==

Code should be reused by including the released [http://en.wikipedia.org/wiki/Software_library library], not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact, the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release.

The users of the library need to know the version/signature for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system.

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author of related classes and collectively make them a large functional unit or package. The REP is targeting a wide audience who are more interested in reuse of a large functional unit or a class in that context. Keeping track of versions of individual classes would be, more often than not, burdensome to users who both use multiple classes within the same package and authors who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package.

REP not only applies to external users, but also applies within the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988 
[5] Microsoft will open source Windows 7 tool that includes GPL code: http://www.infoworld.com/d/windows/microsoft-will-open-source-windows-7-tool-includes-gpl-code-442

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-19T14:15:46Z

Kanke:

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by Bertrand Meyer [3][4], and later laid down in details by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. [http://en.wikipedia.org/wiki/Software_maintenance Maintainability]. There is no need to maintain reused code. This is done by the owner of the reused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several [http://en.wikipedia.org/wiki/Software_versioning versions] of the code, as well as large [http://en.wikipedia.org/wiki/Software_package_%28installation%29 packages]. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best [http://en.wikipedia.org/wiki/Software_design design] philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique describes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other principles, REP.

A "bad" example of not following REP is to reuse code by copying the source code. Just a few days after Microsoft released its Windows 7 operating system, it had to apologize to the public for violating the [http://en.wikipedia.org/wiki/Gpl GPL] license.[5] A utility tool it hired the third party to develop contains a chunk of open source code with a [http://en.wikipedia.org/wiki/Gpl GPL] license attached to it. Microsoft had to open its own source code for this utility program.

=='''''Conclusion'''''==

Code should be reused by including the released [http://en.wikipedia.org/wiki/Software_library library], not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact, the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release.

The users of the library need to know the version/signature for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system.

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author of related classes and collectively make them a large functional unit or package. The REP is targeting a wide audience who are more interested in reuse of a large functional unit or a class in that context. Keeping track of versions of individual classes would be, more often than not, burdensome to users who both use multiple classes within the same package and authors who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package.

REP not only applies to external users, but also applies within the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988 
[5] Microsoft will open source Windows 7 tool that includes GPL code: http://www.infoworld.com/d/windows/microsoft-will-open-source-windows-7-tool-includes-gpl-code-442

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-19T14:14:10Z

Kanke: /* '''''References''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. [http://en.wikipedia.org/wiki/Software_maintenance Maintainability]. There is no need to maintain reused code. This is done by the owner of the reused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several [http://en.wikipedia.org/wiki/Software_versioning versions] of the code, as well as large [http://en.wikipedia.org/wiki/Software_package_%28installation%29 packages]. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best [http://en.wikipedia.org/wiki/Software_design design] philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique describes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other principles, REP.

A "bad" example of not following REP is to reuse code by copying the source code. Just a few days after Microsoft released its Windows 7 operating system, it had to apologize to the public for violating the [http://en.wikipedia.org/wiki/Gpl GPL] license.[5] A utility tool it hired the third party to develop contains a chunk of open source code with a [http://en.wikipedia.org/wiki/Gpl GPL] license attached to it. Microsoft had to open its own source code for this utility program.

=='''''Conclusion'''''==

Code should be reused by including the released [http://en.wikipedia.org/wiki/Software_library library], not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact, the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release.

The users of the library need to know the version/signature for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system.

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author of related classes and collectively make them a large functional unit or package. The REP is targeting a wide audience who are more interested in reuse of a large functional unit or a class in that context. Keeping track of versions of individual classes would be, more often than not, burdensome to users who both use multiple classes within the same package and authors who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package.

REP not only applies to external users, but also applies within the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988
[5] Microsoft will open source Windows 7 tool that includes GPL code: http://www.infoworld.com/d/windows/microsoft-will-open-source-windows-7-tool-includes-gpl-code-442

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-19T14:13:34Z

Kanke: /* '''''Example''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. [http://en.wikipedia.org/wiki/Software_maintenance Maintainability]. There is no need to maintain reused code. This is done by the owner of the reused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several [http://en.wikipedia.org/wiki/Software_versioning versions] of the code, as well as large [http://en.wikipedia.org/wiki/Software_package_%28installation%29 packages]. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best [http://en.wikipedia.org/wiki/Software_design design] philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique describes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other principles, REP.

A "bad" example of not following REP is to reuse code by copying the source code. Just a few days after Microsoft released its Windows 7 operating system, it had to apologize to the public for violating the [http://en.wikipedia.org/wiki/Gpl GPL] license.[5] A utility tool it hired the third party to develop contains a chunk of open source code with a [http://en.wikipedia.org/wiki/Gpl GPL] license attached to it. Microsoft had to open its own source code for this utility program.

=='''''Conclusion'''''==

Code should be reused by including the released [http://en.wikipedia.org/wiki/Software_library library], not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact, the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release.

The users of the library need to know the version/signature for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system.

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author of related classes and collectively make them a large functional unit or package. The REP is targeting a wide audience who are more interested in reuse of a large functional unit or a class in that context. Keeping track of versions of individual classes would be, more often than not, burdensome to users who both use multiple classes within the same package and authors who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package.

REP not only applies to external users, but also applies within the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-19T14:11:04Z

Kanke: /* '''''Conclusion''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by Bertrand Meyer [3][4], and later laid down in details by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. Maintainability. There is no need to maintain reused code. This is done by the owner of the resused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a Cohesion Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several versions of the code, as well as large packages. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best design philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique desribes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other primciples, REP in mind.

A "bad" example of not following REP is to reuse code by copying the source code. Just a few days after Microsoft released its Windows 7 operating system, it had to apologize to the public for violating the [http://en.wikipedia.org/wiki/Gpl GPL] license.[5] A utility tool it hired the third party to develop contains a chunk of open source code with a [http://en.wikipedia.org/wiki/Gpl GPL] license attached to it. Microsoft had to open its own source code for this utility program.

=='''''Conclusion'''''==

Code should be reused by including the released [http://en.wikipedia.org/wiki/Software_library library], not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact, the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release.

The users of the library need to know the version/signature for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system.

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author of related classes and collectively make them a large functional unit or package. The REP is targeting a wide audience who are more interested in reuse of a large functional unit or a class in that context. Keeping track of versions of individual classes would be, more often than not, burdensome to users who both use multiple classes within the same package and authors who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package.

REP not only applies to external users, but also applies within the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988 
[5] Microsoft will open source Windows 7 tool that includes GPL code: http://www.infoworld.com/d/windows/microsoft-will-open-source-windows-7-tool-includes-gpl-code-442

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-17T16:39:55Z

Kanke: /* '''''Example''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by Bertrand Meyer [3][4], and later laid down in details by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. Maintainability. There is no need to maintain reused code. This is done by the owner of the resused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a Cohesion Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several versions of the code, as well as large packages. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best design philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique desribes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other primciples, REP in mind.

A "bad" example of not following REP is to reuse code by copying the source code. Just a few days after Microsoft released its Windows 7 operating system, it had to apologize to the public for violating the [http://en.wikipedia.org/wiki/Gpl GPL] license. http://www.infoworld.com/d/windows/microsoft-will-open-source-windows-7-tool-includes-gpl-code-442 A utility tool it hired the third party to develop contains a chunk of open source code with a [http://en.wikipedia.org/wiki/Gpl GPL] license attached to it. Microsoft had to endure the public humiliation and was "forced" to open its own source code for this utility program.

=='''''Conclusion'''''==

Code should be reused by including the released library, not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release

The users of the library need to know the version for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author who also authors related classes and collectively make them a large functional unit - package. The REP is targeting a broad range of audience who are more interested in reuse this large functional unit or a class in that context. Also keeping track of version of individual classes would be burdensome to both the users who, more often than not, use multiple classes within the same package, and the author who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package

REP not only applies to external users, but also applies within the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-17T16:33:32Z

Kanke: /* '''''Example''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by Bertrand Meyer [3][4], and later laid down in details by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. Maintainability. There is no need to maintain reused code. This is done by the owner of the resused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a Cohesion Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several versions of the code, as well as large packages. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best design philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique desribes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other primciples, REP in mind.

A "bad" example of not following REP is to reuse code by copying the source code. Just a few days after Microsoft released its Windows 7 operating system, it had to apologize to the public for violating the GPL license. [[http://www.infoworld.com/d/windows/microsoft-will-open-source-windows-7-tool-includes-gpl-code-442]] A utility tool it hired the third party to develop contains a chunk of open source code with a GPL license attached to it. Microsoft had to endure the public humiliation and "forced" to open its own source code for this utility program.

=='''''Conclusion'''''==

Code should be reused by including the released library, not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release

The users of the library need to know the version for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author who also authors related classes and collectively make them a large functional unit - package. The REP is targeting a broad range of audience who are more interested in reuse this large functional unit or a class in that context. Also keeping track of version of individual classes would be burdensome to both the users who, more often than not, use multiple classes within the same package, and the author who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package

REP not only applies to external users, but also applies within the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-17T16:00:57Z

Kanke: /* '''''Conclusion''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by Bertrand Meyer [3][4], and later laid down in details by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. Maintainability. There is no need to maintain reused code. This is done by the owner of the resused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a Cohesion Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several versions of the code, as well as large packages. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best design philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique desribes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other primciples, REP in mind.

=='''''Conclusion'''''==

Code should be reused by including the released library, not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release

The users of the library need to know the version for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author who also authors related classes and collectively make them a large functional unit - package. The REP is targeting a broad range of audience who are more interested in reuse this large functional unit or a class in that context. Also keeping track of version of individual classes would be burdensome to both the users who, more often than not, use multiple classes within the same package, and the author who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package

REP not only applies to external users, but also applies within the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-17T15:59:34Z

Kanke: /* '''''Conclusion''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by Bertrand Meyer [3][4], and later laid down in details by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. Maintainability. There is no need to maintain reused code. This is done by the owner of the resused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a Cohesion Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several versions of the code, as well as large packages. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best design philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique desribes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other primciples, REP in mind.

=='''''Conclusion'''''==

Code should be reused by including the released library, not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release

The users of the library need to know the version for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author who also authors related classes and collectively make them a large functional unit - package. The REP is targeting a broad range of audience who are more interested in reuse this large functional unit or a class in that context. Also keeping track of version of individual classes would be burdensome to both users who, more often than not, use multiple classes within the same package, and author who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package

REP not only applies to external users, but also applies within the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-17T15:39:00Z

Kanke: /* '''''Conclusion''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. Maintainability. There is no need to maintain reused code. This is done by the owner of the resused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a Cohesion Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several versions of the code, as well as large packages. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best design philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique desribes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other primciples, REP in mind.

=='''''Conclusion'''''==

Code should be reused by including the released library, not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release

The users of the library need to know the version/signature for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author who also authors related classes and collectively make them a large functional unit - package. The REP is targeting a broad range of audience who are more interested in reuse this large functional unit or a class in that context. Also keeping track of version of individual classes would be burdensome to both users who, more often than not, use multiple classes within the same package, and author who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package

REP not only applies to external users, but also applies within the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-17T15:00:38Z

Kanke: /* '''''Conclusion''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by Bertrand Meyer [3][4], and later laid down in details by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. Maintainability. There is no need to maintain reused code. This is done by the owner of the resused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a Cohesion Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several versions of the code, as well as large packages. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best design philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique desribes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other primciples, REP in mind.

=='''''Conclusion'''''==

Code should be reused by including the released library, not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release

The users of the library need to know the version/signature for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author who also authors related classes and collectively make them a large functional unit - package. The REP is targeting a broad range of audience who are more interested in reuse this large functional unit or a class in that context. Also keeping track of version of individual classes would be burdensome to both users who, more often than not, use multiple classes within the same package, and author who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package

REP not only applies to external users, but also applies within the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-17T14:58:44Z

Kanke: /* '''''Conclusion''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by Bertrand Meyer [3][4], and later laid down in details by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. Maintainability. There is no need to maintain reused code. This is done by the owner of the resused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a Cohesion Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several versions of the code, as well as large packages. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best design philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique desribes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other primciples, REP in mind.

=='''''Conclusion'''''==

Code should be reused by including the released library, not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release

The users of the library need to know the version/signature for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - requirement for a change control system

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author who also authors related classes and collectively make them a large functional unit - package. The REP is targeting a broad range of audience who are more interested in reuse this large functional unit or a class in that context. Also keeping track of version of individual classes would be burdensome to both users who, more often than not, use multiple classes within the same package, and author who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package

REP not only applies to external developers, but also applies within
the organization among different development groups.

=='''''References'''''==

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-17T14:28:30Z

Kanke: /* '''''Conclusion''''' */

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-17T14:24:17Z

Kanke: /* '''''Concept''''' */

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-17T14:22:14Z

Kanke: /* '''''Conclusion''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. Maintainability. There is no need to maintain reused code. This is done by the owner of the resused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a Cohesion Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several versions of the code, as well as large packages. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best design philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique desribes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other primciples, REP in mind.

=='''''Conclusion'''''==

'''''References'''''

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf 
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988

CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

2009-11-17T14:19:43Z

Kanke:

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. Maintainability. There is no need to maintain reused code. This is done by the owner of the resused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a Cohesion Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several versions of the code, as well as large packages. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best design philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique desribes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other primciples, REP in mind.

=='''''Conclusion'''''==

'''''References'''''

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-17T03:24:08Z

Kanke: /* '''The Release Reuse Equivalency Principle (REP)''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==
Components can be effectively reused only if they are released through a tracking system.

__TOC__

=='''''Concept'''''==

The Release Reuse Equivalency Principle (REP), first introduced by [http://en.wikipedia.org/wiki/Robert_Cecil_Martin Bob Martin], is described as follows:

"''The granule of reuse is the granule of release.''"

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be
reused unless it is managed by a release system of some kind. Users will be unwilling
to use the element if they are forced to upgrade every time the author changes it.
Thus. even though the author has released a new version of his reusable element, he
must be willing to support and maintain older versions while his customers go about
the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element
unless the author promises to keep track of version numbers, and maintain old
versions for awhile.
Therefore, one criterion for grouping classes into packages is reuse. Since packages
are the unit of release, they are also the unit of reuse. Therefore architects would do
well to group reusable classes together into packages." [1]

=='''''Description'''''==

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as [http://en.wikipedia.org/wiki/Version_control version control]. Some common examples of version control are [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [http://en.wikipedia.org/wiki/Cmvc CMVC].

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at
the [http://en.wikipedia.org/wiki/Source_code source code] (other than the public portions of header files). I need only link with static
[http://en.wikipedia.org/wiki/Library_%28computing%29 libraries] or include dynamic libraries. Whenever these libraries are fixed or enhanced, I
receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained
by me. It is not distributed by me. I am the customer, and the author, or some other entity,
is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something
in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant [http://en.wikipedia.org/wiki/Object_oriented_design Object-Oriented design] and therefore cannot be properly maintained without release.

=='''''Advantages'''''==

The obvious advantages of REP are:

1. Maintainability. There is no need to maintain reused code. This is done by the owner of the resused (released) code. 
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted. 
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

=='''''Disadvantages'''''==

As REP is a Cohesion Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several versions of the code, as well as large packages. 
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3] 
3. The best design philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

=='''''Example'''''==

The Java Boutique desribes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other primciples, REP in mind.

=='''''Conclusion'''''==

'''''References'''''

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple 
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf

Written Report on View (Testing)

2009-10-27T00:42:22Z

Kanke: /* Planned Fixes and Enhancement */

'''View Layer Analysis and Improvement'''

== View Analysis ==

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently, default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Hard to use mouse alone when adding new split
| The dialog does not offer an easy way to show the effect of amount change in a split
| Currently one has to shift the focus to either buttons or other source amount for the purpose
| Could be realized by a mouse click in a non-sensitive target with a large surface such as a panel.
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
|
|
|
|
| No
|}

=== Planned Fixes and Enhancement ===
# The new split amount represents the remaining balance for the total of the splits (SplitTransactionDialog)
# The dialogue information refreshes after mouse click away from the amount text box (SplitTransactionDialog)
# Fix the source selection in drop-down list, i.e. when a split source is chosen the other source should not lose its selection.
# If the above does not automatically solve the problem, find a way to enable both sources to be split type, which the model allows.

=== Changes Accomplished ===
# The new split amount represents the remaining balance for the total of the splits (SplitTransactionDialog)
# The dialogue information refreshes after mouse click away from the amount text box (SplitTransactionDialog)

Written Report on Model (Testing)

2009-10-27T00:40:04Z

Kanke: /* Pre-existing Tests */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests for Split Model ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

* There are a few method calls in SplitsTest seemed to be redundant. They were in the format of "t.setFrom(new SplitImpl());" or "t.setTo(new SplitImpl());". The later calls, "t.setFromSplits(fromSplits);" or "t.setToSplits(toSplits);", seem to always overwrite their effects.

* In the model, one can add a transaction with all "from" and "to" sources, amounts undefined. Because of the this, one can actually adds 0 split to a split source in a transaction as long as the transaction amount is 0L. Is it what author intended?

=== Added Tests ===

#public void testSplitsZeroToSplit() throws Exception {}
#public void testSplitsZeroFromSplit() throws Exception {}
#public void testSplitsToSplitZeroAmount() throws Exception {}
#public void testSplitsFromSplitZeroAmount() throws Exception {}
#public void testSplitToSplitsNullSource() throws Exception {}
#public void testSplitFromSplitsNullSource() throws Exception {}
#public void void testSplitsToSplitBCincome() throws Exception {}
#public void void testSplitsFromSplitBCincome() throws Exception {}

Written Report on Model (Testing)

2009-10-27T00:39:22Z

Kanke: /* Pre-existing Tests */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

* There are a few method calls in SplitsTest seemed to be redundant. They were in the format of "t.setFrom(new SplitImpl());" or "t.setTo(new SplitImpl());". The later calls, "t.setFromSplits(fromSplits);" or "t.setToSplits(toSplits);", seem to always overwrite their effects.

* In the model, one can add a transaction with all "from" and "to" sources, amounts undefined. Because of the this, one can actually adds 0 split to a split source in a transaction as long as the transaction amount is 0L. Is it what author intended?

=== Added Tests ===

#public void testSplitsZeroToSplit() throws Exception {}
#public void testSplitsZeroFromSplit() throws Exception {}
#public void testSplitsToSplitZeroAmount() throws Exception {}
#public void testSplitsFromSplitZeroAmount() throws Exception {}
#public void testSplitToSplitsNullSource() throws Exception {}
#public void testSplitFromSplitsNullSource() throws Exception {}
#public void void testSplitsToSplitBCincome() throws Exception {}
#public void void testSplitsFromSplitBCincome() throws Exception {}

Written Report on Model (Testing)

2009-10-27T00:37:49Z

Kanke: /* Rules for choosing From and To sources */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

There are a few method calls in SplitsTest seemed to be redundant. They were in the format of "t.setFrom(new SplitImpl());" or "t.setTo(new SplitImpl());". The later calls, "t.setFromSplits(fromSplits);" or "t.setToSplits(toSplits);", seem to always overwrite their effects.

In the model, one can add a transaction with all "from" and "to" sources, amounts undefined. Because of the this, one can actually adds 0 split to a split source in a transaction as long as the transaction amount is 0L. Is it what author intended?

=== Added Tests ===

#public void testSplitsZeroToSplit() throws Exception {}
#public void testSplitsZeroFromSplit() throws Exception {}
#public void testSplitsToSplitZeroAmount() throws Exception {}
#public void testSplitsFromSplitZeroAmount() throws Exception {}
#public void testSplitToSplitsNullSource() throws Exception {}
#public void testSplitFromSplitsNullSource() throws Exception {}
#public void void testSplitsToSplitBCincome() throws Exception {}
#public void void testSplitsFromSplitBCincome() throws Exception {}

Written Report on Model (Testing)

2009-10-27T00:37:29Z

Kanke: /* Model Limitations */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

=== Rules for choosing From and To sources ===
*Implied Rules?
*Filtered list with rules
== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

There are a few method calls in SplitsTest seemed to be redundant. They were in the format of "t.setFrom(new SplitImpl());" or "t.setTo(new SplitImpl());". The later calls, "t.setFromSplits(fromSplits);" or "t.setToSplits(toSplits);", seem to always overwrite their effects.

In the model, one can add a transaction with all "from" and "to" sources, amounts undefined. Because of the this, one can actually adds 0 split to a split source in a transaction as long as the transaction amount is 0L. Is it what author intended?

=== Added Tests ===

#public void testSplitsZeroToSplit() throws Exception {}
#public void testSplitsZeroFromSplit() throws Exception {}
#public void testSplitsToSplitZeroAmount() throws Exception {}
#public void testSplitsFromSplitZeroAmount() throws Exception {}
#public void testSplitToSplitsNullSource() throws Exception {}
#public void testSplitFromSplitsNullSource() throws Exception {}
#public void void testSplitsToSplitBCincome() throws Exception {}
#public void void testSplitsFromSplitBCincome() throws Exception {}

Written Report on Model (Testing)

2009-10-26T13:56:51Z

Kanke: /* Planned Tests */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

=== Model Limitations ===
* One split per transaction - either from or to can be a split but can not be both split within the same transaction. (may not be due to model, but rather buggy implementation.)

* The model allows duplicated data or computed data in two places - split and transaction. This incur duplicate implementations which is potentially error prone.

=== Rules for choosing From and To sources ===
*Implied Rules?
*Filtered list with rules
== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

There are a few method calls in SplitsTest seemed to be redundant. They were in the format of "t.setFrom(new SplitImpl());" or "t.setTo(new SplitImpl());". The later calls, "t.setFromSplits(fromSplits);" or "t.setToSplits(toSplits);", seem to always overwrite their effects.

In the model, one can add a transaction with all "from" and "to" sources, amounts undefined. Because of the this, one can actually adds 0 split to a split source in a transaction as long as the transaction amount is 0L. Is it what author intended?

=== Added Tests ===

#public void testSplitsZeroToSplit() throws Exception {}
#public void testSplitsZeroFromSplit() throws Exception {}
#public void testSplitsToSplitZeroAmount() throws Exception {}
#public void testSplitsFromSplitZeroAmount() throws Exception {}
#public void testSplitToSplitsNullSource() throws Exception {}
#public void testSplitFromSplitsNullSource() throws Exception {}
#public void void testSplitsToSplitBCincome() throws Exception {}
#public void void testSplitsFromSplitBCincome() throws Exception {}

Written Report on View (Testing)

2009-10-26T13:44:45Z

Kanke: /* Bugs or Undesired Behaviors */

'''View Layer Analysis and Improvement'''

== View Analysis ==

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently, default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Hard to use mouse alone when adding new split
| The dialog does not offer an easy way to show the effect of amount change in a split
| Currently one has to shift the focus to either buttons or other source amount for the purpose
| Could be realized by a mouse click in a non-sensitive target with a large surface such as a panel.
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
|
|
|
|
| No
|}

=== Planned Fixes and Enhancement ===
# The new split amount represents the remaining balance for the total of the splits (SplitTransactionDialog)
# The dialogue information refreshes after mouse click away from the amount text box (SplitTransactionDialog)
# Fix the source selection in drop-down list, i.e. when a split source is chosen the other source lose its selection.
# If the above does not automatically solve the problem, find a way to enable both sources to be split type, which the model allows.

=== Changes Accomplished ===
# The new split amount represents the remaining balance for the total of the splits (SplitTransactionDialog)
# The dialogue information refreshes after mouse click away from the amount text box (SplitTransactionDialog)

Written Report on View (Testing)

2009-10-26T13:38:26Z

Kanke: /* Planned Fixes and Enhancement */

'''View Layer Analysis and Improvement'''

== View Analysis ==

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently, default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
|
|
|
|
| No
|}

=== Planned Fixes and Enhancement ===
# The new split amount represents the remaining balance for the total of the splits (SplitTransactionDialog)
# The dialogue information refreshes after mouse click away from the amount text box (SplitTransactionDialog)
# Fix the source selection in drop-down list, i.e. when a split source is chosen the other source lose its selection.
# If the above does not automatically solve the problem, find a way to enable both sources to be split type, which the model allows.

=== Changes Accomplished ===
# The new split amount represents the remaining balance for the total of the splits (SplitTransactionDialog)
# The dialogue information refreshes after mouse click away from the amount text box (SplitTransactionDialog)

Written Report on View (Testing)

2009-10-26T13:37:08Z

Kanke: /* Changes Accomplished */

'''View Layer Analysis and Improvement'''

== View Analysis ==

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently, default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
|
|
|
|
| No
|}

=== Planned Fixes and Enhancement ===
# The new split amount represents the remaining balance for the total of the splits (SplitTransactionDialog)
# The dialogue information refreshes after mouse click away from the amount text box (SplitTransactionDialog)

=== Changes Accomplished ===
# The new split amount represents the remaining balance for the total of the splits (SplitTransactionDialog)
# The dialogue information refreshes after mouse click away from the amount text box (SplitTransactionDialog)

Written Report on View (Testing)

2009-10-26T13:36:36Z

Kanke: /* Planned Fixes and Enhancement */

'''View Layer Analysis and Improvement'''

== View Analysis ==

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently, default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
|
|
|
|
| No
|}

=== Planned Fixes and Enhancement ===
# The new split amount represents the remaining balance for the total of the splits (SplitTransactionDialog)
# The dialogue information refreshes after mouse click away from the amount text box (SplitTransactionDialog)

=== Changes Accomplished ===
# The new split amount represents the remaining balance for the total of the splits
# The dialogue information refreshes after mouse click away from the amount text box

Written Report on View (Testing)

2009-10-26T13:35:23Z

Kanke: /* Planned Fixes and Enhancement */

'''View Layer Analysis and Improvement'''

== View Analysis ==

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently, default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
|
|
|
|
| No
|}

=== Planned Fixes and Enhancement ===
# The new split amount represents the remaining balance for the total of the splits
# The dialogue information refreshes after mouse click away from the amount text box

=== Changes Accomplished ===
# The new split amount represents the remaining balance for the total of the splits
# The dialogue information refreshes after mouse click away from the amount text box

Written Report on View (Testing)

2009-10-26T13:32:01Z

Kanke:

CSC/ECE 517 Fall 2009/program2 buddi wn

2009-10-25T21:05:28Z

Kanke: /* Required Results */

'''Buddi Project'''

== Important Information ==
* Submission: October 23 (Friday)
* First Feedback: October 30 (Friday)
* Resubmission: November 6 (Friday)
* Final Review: November 9 (Monday)
* Metareview: November 11 (Wednesday)

E-mail for Buddi questions:
wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.

=== Required Results ===

This project is more about QA and usability testing, rather than pure
development. While some coding may be required to enhance the view
layer, the vast majority of the code written will be in JUnit tests.
The following is required for your results:
# A '''.zip or .tgz archive''' containing the entire Buddi project (or at a minimum, all files which have changed OR a .diff of your changes, as you desire).
# A '''written report ([[Written Report on Model %28Testing%29|Model]]) on the model testing''', indicating what your unit tests test (paying attention to edge cases where problems are more likely to occur) and the results of these tests. (The actual unit tests themselves will be included in the archive in part a)
# A w'''ritten report ([[Written Report on View %28Testing%29|View]]) on the view testing''', indicating what tests you performed, and what the results were. Screenshots taken throughout the test procedure are optional, but a very good idea to demonstrate what problems (if any) you have found.
# '''A written report on what changes''' you have made to the view (or the model) as a result of your testing. If there were failures or potential improvements discovered in either your tests, this report should include a re-run of the failed tests, showing that they are now working.

== Objectives ==

=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.

=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?

* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

== Bugs or Undesired Behaviors ==

{| class="wikitable" border="1"
|-
! Title
! Details
! Actual Behavior
! Expected Behavior
! Solved
|-valign="top"
| Default Amount for split
| The default amount is not set to the difference automatically for the new split
| Currently, default amount is set to zero
| The remaining split amount represents the remaining balance among the splits
| No
|-valign="top"
| Category drop down
| Category list not filtered
| Some items (credit, cash) are not selectable when selecting a split source.
| If it's not available for selection, then better take them off the list
| No
|-valign="top"
| Split From Source
| Transaction involves split from sources didn't show the split when selected
| It shows <From> in an unselected mode
| Should show "split" entry with "..." button surfaced
| No
|-valign="top"
| Create New menu
| Undesired behavior. Create new options shouldn't be put under ''Edit'' menu. It's not intuitive for new users.
| Under My Accounts tab, Edit -> Create Account.
Under My Budget tab, Edit -> Create Budget Category.
| Several options:
# Move to under File menu
# Create button for "New Account" and "New Budget Category"
| No
|-valign="top"
| Create Budget Category using existing category as parent
| From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".
| Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
| Parent's name should have "+" sign next to it right after child creation.
| No
|-valign="top"
|
|
|
|
| No
|}

== References ==

* [[Unit Test for Buddi]]
* [[Buddi Existing Test code]]

== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

Written Report on Model (Testing)

2009-10-25T19:41:41Z

Kanke: /* Pre-existing Tests */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

=== Model Limitations ===
* One split per transaction - either from or to can be a split but can not be both split within the same transaction. (may not be due to model, but rather buggy implementation.)

* The model allows duplicated data or computed data in two places - split and transaction. This incur duplicate implementations which is potentially error prone.

=== Rules for choosing From and To sources ===
*Implied Rules?
*Filtered list with rules
== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

There are a few method calls in SplitsTest seemed to be redundant. They were in the format of "t.setFrom(new SplitImpl());" or "t.setTo(new SplitImpl());". The later calls, "t.setFromSplits(fromSplits);" or "t.setToSplits(toSplits);", seem to always overwrite their effects.

In the model, one can add a transaction with all "from" and "to" sources, amounts undefined. Because of the this, one can actually adds 0 split to a split source in a transaction as long as the transaction amount is 0L. Is it what author intended?

=== Planned Tests ===

#public void testSplitsZeroToSplit() throws Exception {}
#public void testSplitsZeroFromSplit() throws Exception {}
#public void testSplitsToSplitZeroAmount() throws Exception {}
#public void testSplitsFromSplitZeroAmount() throws Exception {}
#public void testSplitToSplitsNullSource() throws Exception {}
#public void testSplitFromSplitsNullSource() throws Exception {}
#public void void testSplitsToSplitBCincome() throws Exception {}
#public void void testSplitsFromSplitBCincome() throws Exception {}
#public void test
#public void test

Written Report on Model (Testing)

2009-10-25T19:09:33Z

Kanke: /* Pre-existing Tests */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

=== Model Limitations ===
* One split per transaction - either from or to can be a split but can not be both split within the same transaction. (may not be due to model, but rather buggy implementation.)

* The model allows duplicated data or computed data in two places - split and transaction. This incur duplicate implementations which is potentially error prone.

=== Rules for choosing From and To sources ===
*Implied Rules?
*Filtered list with rules
== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

There are a few method calls in SplitsTest seemed to be redundant. They were in the format of "t.setFrom(new SplitImpl());" or "t.setTo(new SplitImpl());". The later calls, "t.setFromSplits(fromSplits);" or "t.setToSplits(toSplits);", seem to always overwrite their effects.

=== Planned Tests ===

#public void testSplitsZeroToSplit() throws Exception {}
#public void testSplitsZeroFromSplit() throws Exception {}
#public void testSplitsToSplitZeroAmount() throws Exception {}
#public void testSplitsFromSplitZeroAmount() throws Exception {}
#public void testSplitToSplitsNullSource() throws Exception {}
#public void testSplitFromSplitsNullSource() throws Exception {}
#public void void testSplitsToSplitBCincome() throws Exception {}
#public void void testSplitsFromSplitBCincome() throws Exception {}
#public void test
#public void test

Written Report on Model (Testing)

2009-10-25T00:14:21Z

Kanke: /* Planned Tests */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

=== Model Limitations ===
* One split per transaction - either from or to can be a split but can not be both split within the same transaction. (may not be due to model, but rather buggy implementation.)

* The model allows duplicated data or computed data in two places - split and transaction. This incur duplicate implementations which is potentially error prone.

=== Rules for choosing From and To sources ===
*Implied Rules?
*Filtered list with rules
== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

=== Planned Tests ===

#public void testSplitsZeroToSplit() throws Exception {}
#public void testSplitsZeroFromSplit() throws Exception {}
#public void testSplitsToSplitZeroAmount() throws Exception {}
#public void testSplitsFromSplitZeroAmount() throws Exception {}
#public void testSplitToSplitsNullSource() throws Exception {}
#public void testSplitFromSplitsNullSource() throws Exception {}
#public void void testSplitsToSplitBCincome() throws Exception {}
#public void void testSplitsFromSplitBCincome() throws Exception {}
#public void test
#public void test

Written Report on Model (Testing)

2009-10-24T23:53:36Z

Kanke: /* Planned Tests */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

=== Model Limitations ===
* One split per transaction - either from or to can be a split but can not be both split within the same transaction. (may not be due to model, but rather buggy implementation.)

* The model allows duplicated data or computed data in two places - split and transaction. This incur duplicate implementations which is potentially error prone.

=== Rules for choosing From and To sources ===
*Implied Rules?
*Filtered list with rules
== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

=== Planned Tests ===

#public void testSplitsZeroToSplit() throws Exception {}
#public void testSplitsZeroFromSplit() throws Exception {}
#public void testSplitsFromSplitZeroAmount() throws Exception {}
#public void testSplitFromSplitsNullSource() throws Exception {}
#public void testSplitsToSplitZeroAmount() throws Exception {}
#public void testSplitToSplitsNullSource() throws Exception {}
#public void test
#public void test
#public void test
#public void test

Written Report on Model (Testing)

2009-10-22T22:07:00Z

Kanke: /* Model Limitations */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

=== Model Limitations ===
* One split per transaction - either from or to can be a split but can not be both split within the same transaction. (may not be due to model, but rather buggy implementation.)

* The model allows duplicated data or computed data in two places - split and transaction. This incur duplicate implementations which is potentially error prone.

=== Rules for choosing From and To sources ===
*Implied Rules?
*Filtered list with rules
== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

=== Planned Tests ===

#public void testZeroSplitSplits() throws Exception {}
#public void testZeroAmountSplit() throws Exception {}
#public void testNullSourceSplit() throws Exception {}
#public void testNullAmountSplit() throws Exception {}
#public void testOutOfContextSourceSplit() throws Exception {}
#public void test
#public void test
#public void test
#public void test
#public void test

Written Report on Model (Testing)

2009-10-22T20:45:39Z

Kanke: /* Planned Tests */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

=== Model Limitations ===
* One split per transaction - either from or to can be a split but can not be both split within the same transaction.

=== Rules for choosing From and To sources ===
*Implied Rules?
*Filtered list with rules
== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

=== Planned Tests ===

#public void testZeroSplitSplits() throws Exception {}
#public void testZeroAmountSplit() throws Exception {}
#public void testNullSourceSplit() throws Exception {}
#public void testNullAmountSplit() throws Exception {}
#public void testOutOfContextSourceSplit() throws Exception {}
#public void test
#public void test
#public void test
#public void test
#public void test

Written Report on Model (Testing)

2009-10-22T19:55:41Z

Kanke: /* Planned Tests */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

=== Model Limitations ===
* One split per transaction - either from or to can be a split but can not be both split within the same transaction.

=== Rules for choosing From and To sources ===
*Implied Rules?
*Filtered list with rules
== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

=== Planned Tests ===

#public void testZeroSplit() throws Exception {}
#public void testNullSetter() throws Exception {}
#public void test
#public void test
#public void test
#public void test
#public void test
#public void test
#public void test
#public void test

Written Report on Model (Testing)

2009-10-22T17:31:03Z

Kanke: /* Planned Tests */

'''Model Analysis and Testing'''

== Model Analysis ==

=== Ubiquitousness of Split ===

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

=== Model Limitations ===
* One split per transaction - either from or to can be a split but can not be both split within the same transaction.

=== Rules for choosing From and To sources ===
*Implied Rules?
*Filtered list with rules
== Testing ==
=== Testing Strategy ===
*Conformance — Does the value conform to an expected format?
*Ordering — Is the set of values ordered or unordered as appropriate?
*Range — Is the value within reasonable minimum and maximum values?
*Reference — Does the code reference anything external that isn't under direct control of the code itself?
*Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
*Cardinality — Are there exactly enough values?
*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

=== Pre-existing Tests ===
<pre>
public void testCompare() throws Exception {
//Splitting To - all attributes are the same
//Splitting From - All attributes are the same
}

public void testWithoutSplits() throws Exception {}

public void testWithFromSplits() throws Exception {}

public void testWithToSplits() throws Exception {}

public void testWithBothSplits() throws Exception {}

public void testUnbalancedSplits() throws Exception {}

public void testWithIncorrectIncomeBCSplits() throws Exception {}

</pre>

=== Planned Tests ===

#public void test
#public void test
#public void test
#public void test
#public void test
#public void test
#public void test
#public void test
#public void test
#public void test

Written Report on Model (Testing)

2009-10-22T17:29:54Z

Kanke: /* Planned Tests */

Written Report on Model (Testing)

2009-10-22T17:27:20Z

Kanke: /* Pre-existing Tests */

Written Report on Model (Testing)

2009-10-22T01:35:48Z

Kanke: /* Model Limitations */

Written Report on Model (Testing)

2009-10-20T16:01:10Z

Kanke:

Report for View (Testing)

2009-10-20T15:50:25Z

Kanke:

'''View Analysis and Testing'''

== Testing ==
=== Testing Strategy ===
==== Testing method ====
:*Interactive (manual)
==== Testing Scenario ====
:*Complete Story
:*Split focused
:*Testing matrix

=== Planned Tests ===

=== Tests Done===

== View Analysis (Based on tests) ==

== View Changes ==
=== Planned Changes ===
#Commit Button
#"+", "-" => "Add", "Remove" or icons
#non-purpose? square in transaction dialog
=== Changes Made ===

Report for View (Testing)

2009-10-20T15:47:00Z

Kanke: /* Testing Strategy */

'''View Analysis and Testing'''

== Testing ==
=== Testing Strategy ===
#Testing method
:*Interactive (manual)
#Testing Scenario
:*Complete Story
:*Split focused
:*Testing matrix

=== Done Tests ===

=== Planned Tests ===

== View Analysis ==

== View Changes ==
=== Planned Changes ===
#Commit Button
#"+", "-" => "Add", "Remove" or icons
#non-purpose? square in transaction dialog
=== Changes Made ===

Report for View (Testing)

2009-10-20T15:45:42Z

Kanke: /* Testing Strategy */

'''View Analysis and Testing'''

== Testing ==
=== Testing Strategy ===
#Test method
*Interactive (manual)
#Test Scenario
*Complete Story
*Split focused
*Testing matrix

=== Done Tests ===

=== Planned Tests ===

== View Analysis ==

== View Changes ==
=== Planned Changes ===
#Commit Button
#"+", "-" => "Add", "Remove" or icons
#non-purpose? square in transaction dialog
=== Changes Made ===

Report for View (Testing)

2009-10-20T15:45:17Z

Kanke:

'''View Analysis and Testing'''

== Testing ==
=== Testing Strategy ===
#Test method
*Interactive (manual)
#Test SCenario
*Complete Story
*Split focused
*Testing matrix

=== Done Tests ===

=== Planned Tests ===

== View Analysis ==

== View Changes ==
=== Planned Changes ===
#Commit Button
#"+", "-" => "Add", "Remove" or icons
#non-purpose? square in transaction dialog
=== Changes Made ===

Written Report on Model (Testing)

2009-10-20T15:14:02Z

Kanke:

Written Report on Model (Testing)

2009-10-20T15:04:56Z

Kanke: /* Model Analysis */

'''Model Analysis and Testing'''

== Model Analysis ==

# Ubiquitousness of Split

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the [[Report for View (Testing)]] section.

# Rules for choosing From and To sources

== Testing ==
=== Testing Strategy ===
=== Pre-existing Testing ===
=== Planned Testing ===