Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-19T03:24:23Z

Discostu: /* '''''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. [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.

=='''''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 teamhelm

2009-11-19T03:19:10Z

Discostu: /* '''''Disadvantages''''' */

== '''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.

=='''''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 teamhelm

2009-11-19T03:04:41Z

Discostu: /* '''''Advantages''''' */

== '''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 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 describes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other principles, REP.

=='''''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 teamhelm

2009-11-19T03:01:08Z

Discostu: /* '''''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. 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 describes a [http://javaboutique.internet.com/Case_Study/ tutorial] for designing a system with, among other principles, REP.

=='''''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-18T00:31:10Z

Discostu: /* '''''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.[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 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 
[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-18T00:30:28Z

Discostu: /* '''''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. 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 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 
[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-18T00:26:25Z

Discostu: /* '''''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.[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 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/wiki3teamhelm

2009-11-17T12:49:34Z

Discostu: CSC/ECE 517 Fall 2009/wiki3teamhelm moved to CSC/ECE 517 Fall 2009/wiki3 teamhelm: conform to dr gehringer's naming conventions

#REDIRECT [[CSC/ECE 517 Fall 2009/wiki3 teamhelm]]

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-17T12:49:34Z

Discostu: CSC/ECE 517 Fall 2009/wiki3teamhelm moved to CSC/ECE 517 Fall 2009/wiki3 teamhelm: conform to dr gehringer's naming conventions

== '''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-17T02:26:56Z

Discostu: /* '''''Example''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__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-17T02:26:14Z

Discostu: /* '''''Example''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__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/image014.gif 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-17T02:19:49Z

Discostu: /* '''''Disadvantages''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__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'''''==

=='''''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-17T02:14:16Z

Discostu: /* '''''Disadvantages''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__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]

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

=='''''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-17T02:13:59Z

Discostu: /* '''''Disadvantages''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__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. [2]

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

=='''''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-15T16:07:24Z

Discostu: /* '''''Concept''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__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'''''==

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

=='''''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-14T16:25:24Z

Discostu: /* '''''Advantages''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__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.''"

"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'''''==

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

=='''''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-14T16:24:57Z

Discostu: /* '''''Description''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__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.''"

"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'''''==

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

=='''''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-14T16:21:03Z

Discostu: /* '''''Advantages''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__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.''"

"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 source code (other than the public portions of header files). I need only link with static
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 OO 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'''''==

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

=='''''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-14T16:15:58Z

Discostu: /* '''''Description''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__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.''"

"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 source code (other than the public portions of header files). I need only link with static
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 OO design and therefore cannot be properly maintained without release.

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

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

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

=='''''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-14T16:13:28Z

Discostu: /* '''''Conclusion''''' */

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T16:12:54Z

Discostu: /* '''''Description''''' */

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T16:06:09Z

Discostu: /* '''''Conclusion''''' */

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T16:05:05Z

Discostu: /* '''''Description''''' */

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:58:57Z

Discostu:

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:57:44Z

Discostu:

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:56:25Z

Discostu: /* '''''Description''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__TOC__

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

The Release Reuse Equivalency Principle (REP), first introduced by Bob Martin, is described as follows:

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

"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 "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.

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

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

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

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

'''''References'''''

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:48:25Z

Discostu: /* '''''Description''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__TOC__

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

The Release Reuse Equivalency Principle (REP), first introduced by Bob Martin, is described as follows:

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

"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 "version control". Some common examples of version control are SVN, CVS and 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.

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

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

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

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

'''''References'''''

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:45:32Z

Discostu: /* '''''Description''''' */

== '''The Release Reuse Equivalency Principle (REP)''' ==

__TOC__

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

The Release Reuse Equivalency Principle (REP), first introduced by Bob Martin, is described as follows:

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

"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 "version control". Some common examples of version control are SVN, CVS and 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.

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

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

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

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

'''''References'''''

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:43:07Z

Discostu: /* '''''Description''''' */

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:37:09Z

Discostu:

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:33:53Z

Discostu:

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:33:40Z

Discostu:

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:30:03Z

Discostu:

== '''The Release Reuse Equivalency Principle (REP)''' ==

__TOC__

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

The Release Reuse Equivalency Principle (REP), first introduced by Bob Martin, is described as follows:

"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]

'''''References'''''

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:29:37Z

Discostu:

== '''The Release Reuse Equivalency Principle (REP)''' ==

__TOC__

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

The Release Reuse Equivalency Principle (REP), first introduced by Bob Martin, is described as follows:

"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]

'''''References'''''

[1] Design Principles and Patterns: (http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf)

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:26:46Z

Discostu:

== '''The Release Reuse Equivalency Principle (REP)''' ==

__TOC__

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

The Release Reuse Equivalency Principle (REP), first introduced by Bob Martin, is described as follows:

"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." (http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf)

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:26:12Z

Discostu:

== '''The Release Reuse Equivalency Principle (REP)''' ==

__TOC__

The Release Reuse Equivalency Principle (REP), first introduced by Bob Martin, is described as follows:

"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." (http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf)

CSC/ECE 517 Fall 2009/wiki3 teamhelm

2009-11-14T15:23:54Z

Discostu:

The Release Reuse Equivalency Principle (REP)

The Release Reuse Equivalency Principle (REP), first introduced by Bob Martin, is described as follows:

"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." (http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf)

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-13T19:14:04Z

Discostu:

== '''Reflection-Oriented Programming''' ==

__TOC__

'''Reflection-Oriented Programming''' (ROP), or "reflective programming", is defined as a programming model design with the intent to analyze and improve it's structure, performance or other implementation aspects during runtime (implying no prior knowledge of the [http://en.wikipedia.org/wiki/Source_code source code]), as opposed to compile time. ROP is a natural extension to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming].

=='''''Concepts'''''==

Two key concepts of ROP are [http://en.wikipedia.org/wiki/Metadata meta-information], which is the state of the program at execution time, and [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming], which is the idea that a language can act as it's own [http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 reflection]. In other words, a language can reflect (modify) itself. More precisely, we define reflection-oriented programming to be a programming style that uses any means available (reflection or otherwise) to extend the meta-information in order to avoid situations in which a local program's requirements leads to non-local rewriting of said program [4]. Additionally, the ROP concepts extends reflection, in that it can make decisions on the [http://en.wikipedia.org/wiki/Software_architecture architecture] of the system, rather than just [http://en.wikipedia.org/wiki/Method_%28computer_science%29 methods] and [http://en.wikipedia.org/wiki/Variable_%28programming%29 variables].

=='''''Reflection vs. ROP'''''==

Reflection is the process by which a computer program can observe and modify it's own structure and behavior[1]. It allows an executing program to examine or "introspect" upon itself, and manipulate internal properties of the program[2]. [http://en.wikipedia.org/wiki/Java_%28software_platform%29 Java], [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] and [http://en.wikipedia.org/wiki/.NET_Framework .NET] are among the most popular reflective languages, however there are many others[3]. Although reflection is the primary concept behind ROP, it does not necessarily preclude the existence of ROP. ROP is a concept of design; as with most designs, it is not necessarily dependent on the implementation. As an example, computational programming can also be used to implement the concepts of ROP, and does not assume the presence of source code at runtime, something that is essential to the concept of reflection[4].

The ROP metaprogramming model sequences are defined as either atomic (simple) or compound (multi-atomic). These sequences take advantage of meta-information that retains knowledge of program structure, which is different than a classic object-oriented program that can lose said structure after [http://en.wikipedia.org/wiki/Compiler compilation].

=='''''Meta-Information'''''==

Meta-Information, or metadata, is the state of the program at execution time. Phrased another way, Meta-information is information about information. For example, a if a document is considered to be information, its title, location, and subject are examples of meta-information[5]. Meta-Information is essential not only for reflection but for the concepts of ROP to be implemented correctly.

=='''''Metaprogramming'''''==

Metaprogramming introduces the concept of "programs that write programs". Reflection is one type of metaprogramming, and therefore can be considered as an option when attempting to design a system or program based on the concepts defined by ROP. Metaprograms are written in [http://en.wikipedia.org/wiki/Metalanguage Metalanguage][6], which to be considered for ROP would be defined as the same or alternate language as the system or program to be implemented.

=='''''Examples'''''==

''Simple Reflection''

As an example, first let us review what reflection looks like as an implementation. To see how reflection works, consider this simple example, taken from [http://java.sun.com/developer/technicalArticles/ALT/Reflection/ Using Java Reflection]:

import java.lang.reflect.*;

public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}

For an invocation of:

java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)

That is, the method names of class java.util.Stack are listed, along with their fully qualified parameter and return types.

This program loads the specified class using class.forName, and then calls getDeclaredMethods to retrieve the list of methods defined in the class. java.lang.reflect.Method is a class representing a single class method. Reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing program[2].

''ROP''

ROP is more than just simple reflection (although technically, it can be reflection alone), it is also analyzation or improvement at runtime without prior knowledge of source code. A good example of this concept is Measuring Computational Expense from the document [http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf An Introduction to Reflection-Oriented Programming]. To implement such behavior, we need only these definitions:

define reflective <runtime> (<simple-reflective>)
slot ticks, init-value: 0;
end;

define method atomic (v, outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

define method compound-initial (outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

It is convenient to have default behaviors for [http://en.wikipedia.org/wiki/Atomic_operation atomic], compound-initial (specifies what transition should take place upon entering the initial part of a compound computation), and compound-rest (specifies what meta-information gets passed on to the rest of a compound computation) that simply "thread" meta-information through the computations. The inherited definition of compound-rest suffices. Now suppose we want to evaluate some [http://en.wikipedia.org/wiki/Expression_%28programming%29 expression] E without counting its cost. We could use the reify and reflect operations like this:

let r = reify(<runtime>);
let result = E;
reflect(<runtime>, r, result);

Here we capture the expense meta-information before evaluating E and save it as r. After evaluating E, we restore the old meta-information. The result from evaluating E is returned. Of course, any time we want to know the cumulative expense for the program, we can examine reify(<runtime>).ticks[4].

Java and Ruby are two examples of popular programming languages that are inherently reflective, and therefore could be used to implement an ROP paradigm.

'''''References'''''

[1] Reflection (Computer Science), Wikipedia: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 
[2] Using Java Reflection, Sun: http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
[3] List of reflective programming languages and platforms, Wikipedia: http://en.wikipedia.org/wiki/List_of_reflective_programming_languages_and_platforms 
[4] An Introduction to Reflection-Oriented Programming, Sobel & Friedman: http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf 
[5] What is Metainformation?: http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci900705,00.html 
[6] Metaprogramming, Wikipedia: http://en.wikipedia.org/wiki/Metaprogramming

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-13T19:02:59Z

Discostu:

== '''Reflection-Oriented Programming''' ==

__TOC__

'''Reflection-Oriented Programming''' (ROP), or "reflective programming", is defined as a programming model design with the intent to analyze and improve it's structure, performance or other implementation aspects during runtime (implying no prior knowledge of the [http://en.wikipedia.org/wiki/Source_code source code]), as opposed to compile time. ROP is a natural extension to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming].

=='''''Concepts'''''==

Two key concepts of ROP are [http://en.wikipedia.org/wiki/Metadata meta-information], which is the state of the program at execution time, and [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming], which is the idea that a language can act as it's own [http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 reflection]. In other words, a language can reflect (modify) itself. More precisely, we define reflection-oriented programming to be a programming style that uses any means available (reflection or otherwise) to extend the meta-information in order to avoid situations in which a local program's requirements leads to non-local rewriting of said program [4]. Additionally, the ROP concepts extends reflection, in that it can make decisions on the [http://en.wikipedia.org/wiki/Software_architecture architecture] of the system, rather than just [http://en.wikipedia.org/wiki/Method_%28computer_science%29 methods] and [http://en.wikipedia.org/wiki/Variable_%28programming%29 variables].

=='''''Reflection vs. ROP'''''==

Reflection is the process by which a computer program can observe and modify it's own structure and behavior[1]. It allows an executing program to examine or "introspect" upon itself, and manipulate internal properties of the program[2]. [http://en.wikipedia.org/wiki/Java_%28software_platform%29 Java], [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] and [http://en.wikipedia.org/wiki/.NET_Framework .NET] are among the most popular reflective languages, however there are many others[3]. Although reflection is the primary concept behind ROP, it does not necessarily preclude the existence of ROP. ROP is a concept of design; as with most designs, it is not necessarily dependent on the implementation. As an example, computational programming can also be used to implement the concepts of ROP, and does not assume the presence of source code at runtime, something that is essential to the concept of reflection[4].

The ROP metaprogramming model sequences are defined as either atomic (simple) or compound (multi-atomic). These sequences take advantage of meta-information that retains knowledge of program structure, which is different than a classic object-oriented program that can lose said structure after [http://en.wikipedia.org/wiki/Compiler compilation].

=='''''Meta-Information'''''==

Meta-Information, or metadata, is the state of the program at execution time. Phrased another way, Meta-information is information about information. For example, a if a document is considered to be information, its title, location, and subject are examples of meta-information[5]. Meta-Information is essential not only for reflection but for the concepts of ROP to be implemented correctly.

=='''''Metaprogramming'''''==

Metaprogramming introduces the concept of "programs that write programs". Reflection is one type of metaprogramming, and therefore can be considered as an option when attempting to design a system or program based on the concepts defined by ROP. Metaprograms are written in [http://en.wikipedia.org/wiki/Metalanguage Metalanguage][6], which to be considered for ROP would be defined as the same or alternate language as the system or program to be implemented.

=='''''Examples'''''==

''Simple Reflection''

As an example, first let us review what reflection looks like as an implementation. To see how reflection works, consider this simple example, taken from [http://java.sun.com/developer/technicalArticles/ALT/Reflection/ Using Java Reflection]:

import java.lang.reflect.*;

public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}

For an invocation of:

java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)

That is, the method names of class java.util.Stack are listed, along with their fully qualified parameter and return types.

This program loads the specified class using class.forName, and then calls getDeclaredMethods to retrieve the list of methods defined in the class. java.lang.reflect.Method is a class representing a single class method. Reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing program[2].

''ROP''

ROP is more than just simple reflection (although technically, it can be reflection alone), it is also analyzation or improvement at runtime without prior knowledge of source code. A good example of this concept is Measuring Computational Expense from the document [http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf An Introduction to Reflection-Oriented Programming]. To implement such behavior, we need only these definitions:

define reflective <runtime> (<simple-reflective>)
slot ticks, init-value: 0;
end;

define method atomic (v, outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

define method compound-initial (outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

It is convenient to have default behaviors for atomic, compound-initial, and compound-rest that simply "thread" meta-information through the computations. The inherited definition of compound-rest suffices. Now suppose we want to evaluate some [http://en.wikipedia.org/wiki/Expression_%28programming%29 expression] E without counting its cost. We could use the reify and reflect operations like this:

let r = reify(<runtime>);
let result = E;
reflect(<runtime>, r, result);

Here we capture the expense meta-information before evaluating E and save it as r. After evaluating E, we restore the old meta-information. The result from evaluating E is returned. Of course, any time we want to know the cumulative expense for the program, we can examine reify(<runtime>).ticks[4].

Java and Ruby are two examples of popular programming languages that are inherently reflective, and therefore could be used to implement an ROP paradigm.

'''''References'''''

[1] Reflection (Computer Science), Wikipedia: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 
[2] Using Java Reflection, Sun: http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
[3] List of reflective programming languages and platforms, Wikipedia: http://en.wikipedia.org/wiki/List_of_reflective_programming_languages_and_platforms 
[4] An Introduction to Reflection-Oriented Programming, Sobel & Friedman: http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf 
[5] What is Metainformation?: http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci900705,00.html 
[6] Metaprogramming, Wikipedia: http://en.wikipedia.org/wiki/Metaprogramming

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-13T18:47:42Z

Discostu:

== '''Reflection-Oriented Programming''' ==

__TOC__

'''Reflection-Oriented Programming''' (ROP), or "reflective programming", is defined as a programming model design with the intent to analyze and improve it's structure, performance or other implementation aspects during runtime (implying no prior knowledge of the source), as opposed to compile time. ROP is a natural extension to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming].

=='''''Concepts'''''==

Two key concepts of ROP are meta-information, which is the state of the program at execution time, and metaprogramming, which is the idea that a language can act as it's own reflection. In other words, a language can reflect (modify) itself. More precisely, we define reflection-oriented programming to be a programming style that uses any means available (reflection or otherwise) to extend the meta-information in order to avoid situations in which a local program's requirements leads to non-local rewriting of said program [4]. Additionally, the ROP concepts extends reflection, in that it can make decisions on the architecture of the system, rather than just methods and variables.

=='''''Reflection vs. ROP'''''==

Reflection is the process by which a computer program can observe and modify it's own structure and behavior[1]. It allows an executing program to examine or "introspect" upon itself, and manipulate internal properties of the program[2]. Java, Ruby and .NET are among the most popular reflective languages, however there are many others[3]. Although reflection is the primary concept behind ROP, it does not necessarily preclude the existence of ROP. ROP is a concept of design; as with most designs, it is not necessarily dependent on the implementation. As an example, computational programming can also be used to implement the concepts of ROP, and does not assume the presence of source code at runtime, something that is essential to the concept of reflection[4].

The ROP metaprogramming model sequences are defined as either atomic (simple) or compound (multi-atomic). These sequences take advantage of meta-information that retains knowledge of program structure, which is different than a classic object-oriented program that can lose said structure after compilation.

=='''''Meta-Information'''''==

Meta-Information, or metadata, is the state of the program at execution time. Phrased another way, Meta-information is information about information. For example, a if a document is considered to be information, its title, location, and subject are examples of meta-information[5]. Meta-Information is essential not only for reflection but for the concepts of ROP to be implemented correctly.

=='''''Metaprogramming'''''==

Metaprogramming introduces the concept of "programs that write programs". Reflection is one type of metaprogramming, and therefore can be considered as an option when attempting to design a system or program based on the concepts defined by ROP. Metaprograms are written in Metalanguage[6], which to be considered for ROP would be defined as the same or alternate language as the system or program to be implemented.

=='''''Examples'''''==

''Simple Reflection''

As an example, first let us review what reflection looks like as an implementation. To see how reflection works, consider this simple example, taken from [http://java.sun.com/developer/technicalArticles/ALT/Reflection/ Using Java Reflection]:

import java.lang.reflect.*;

public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}

For an invocation of:

java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)

That is, the method names of class java.util.Stack are listed, along with their fully qualified parameter and return types.

This program loads the specified class using class.forName, and then calls getDeclaredMethods to retrieve the list of methods defined in the class. java.lang.reflect.Method is a class representing a single class method. Reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing program[2].

''ROP''

ROP is more than just simple reflection (although technically, it can be reflection alone), it is also analyzation or improvement at runtime without prior knowledge of source. A good example of this concept is Measuring Computational Expense from the document [http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf An Introduction to Reflection-Oriented Programming]. To implement such behavior, we need only these definitions:

define reflective <runtime> (<simple-reflective>)
slot ticks, init-value: 0;
end;

define method atomic (v, outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

define method compound-initial (outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

It is convenient to have default behaviors for atomic, compound-initial, and compound-rest that simply "thread" meta-information through the computations. The inherited definition of compound-rest suffices. Now suppose we want to evaluate some expression E without counting its cost. We could use the reify and reflect operations like this:

let r = reify(<runtime>);
let result = E;
reflect(<runtime>, r, result);

Here we capture the expense meta-information before evaluating E and save it as r. After evaluating E, we restore the old meta-information. The result from evaluating E is returned. Of course, any time we want to know the cumulative expense for the program, we can examine reify(<runtime>).ticks[4].

Java and Ruby are two examples of popular programming languages that are inherently reflective, and therefore could be used to implement an ROP paradigm.

'''''References'''''

[1] Reflection (Computer Science), Wikipedia: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 
[2] Using Java Reflection, Sun: http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
[3] List of reflective programming languages and platforms, Wikipedia: http://en.wikipedia.org/wiki/List_of_reflective_programming_languages_and_platforms 
[4] An Introduction to Reflection-Oriented Programming, Sobel & Friedman: http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf 
[5] What is Metainformation?: http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci900705,00.html 
[6] Metaprogramming, Wikipedia: http://en.wikipedia.org/wiki/Metaprogramming

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-13T18:44:25Z

Discostu:

== '''Reflection-Oriented Programming''' ==

__TOC__

'''Reflection-Oriented Programming''' (ROP), or "reflective programming", is defined as a programming model design with the intent to analyze and improve it's structure, performance or other implementation aspects during runtime (implying no prior knowledge of the source), as opposed to compile time. ROP is a natural extension to object-oriented programming.

=='''''Concepts'''''==

Two key concepts of ROP are meta-information, which is the state of the program at execution time, and metaprogramming, which is the idea that a language can act as it's own reflection. In other words, a language can reflect (modify) itself. More precisely, we define reflection-oriented programming to be a programming style that uses any means available (reflection or otherwise) to extend the meta-information in order to avoid situations in which a local program's requirements leads to non-local rewriting of said program [4]. Additionally, the ROP concepts extends reflection, in that it can make decisions on the architecture of the system, rather than just methods and variables.

=='''''Reflection vs. ROP'''''==

Reflection is the process by which a computer program can observe and modify it's own structure and behavior[1]. It allows an executing program to examine or "introspect" upon itself, and manipulate internal properties of the program[2]. Java, Ruby and .NET are among the most popular reflective languages, however there are many others[3]. Although reflection is the primary concept behind ROP, it does not necessarily preclude the existence of ROP. ROP is a concept of design; as with most designs, it is not necessarily dependent on the implementation. As an example, computational programming can also be used to implement the concepts of ROP, and does not assume the presence of source code at runtime, something that is essential to the concept of reflection[4].

The ROP metaprogramming model sequences are defined as either atomic (simple) or compound (multi-atomic). These sequences take advantage of meta-information that retains knowledge of program structure, which is different than a classic object-oriented program that can lose said structure after compilation.

=='''''Meta-Information'''''==

Meta-Information, or metadata, is the state of the program at execution time. Phrased another way, Meta-information is information about information. For example, a if a document is considered to be information, its title, location, and subject are examples of meta-information[5]. Meta-Information is essential not only for reflection but for the concepts of ROP to be implemented correctly.

=='''''Metaprogramming'''''==

Metaprogramming introduces the concept of "programs that write programs". Reflection is one type of metaprogramming, and therefore can be considered as an option when attempting to design a system or program based on the concepts defined by ROP. Metaprograms are written in Metalanguage[6], which to be considered for ROP would be defined as the same or alternate language as the system or program to be implemented.

=='''''Examples'''''==

''Simple Reflection''

As an example, first let us review what reflection looks like as an implementation. To see how reflection works, consider this simple example, taken from [http://java.sun.com/developer/technicalArticles/ALT/Reflection/ Using Java Reflection]:

import java.lang.reflect.*;

public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}

For an invocation of:

java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)

That is, the method names of class java.util.Stack are listed, along with their fully qualified parameter and return types.

This program loads the specified class using class.forName, and then calls getDeclaredMethods to retrieve the list of methods defined in the class. java.lang.reflect.Method is a class representing a single class method. Reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing program[2].

''ROP''

ROP is more than just simple reflection (although technically, it can be reflection alone), it is also analyzation or improvement at runtime without prior knowledge of source. A good example of this concept is Measuring Computational Expense from the document [http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf An Introduction to Reflection-Oriented Programming]. To implement such behavior, we need only these definitions:

define reflective <runtime> (<simple-reflective>)
slot ticks, init-value: 0;
end;

define method atomic (v, outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

define method compound-initial (outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

It is convenient to have default behaviors for atomic, compound-initial, and compound-rest that simply "thread" meta-information through the computations. The inherited definition of compound-rest suffices. Now suppose we want to evaluate some expression E without counting its cost. We could use the reify and reflect operations like this:

let r = reify(<runtime>);
let result = E;
reflect(<runtime>, r, result);

Here we capture the expense meta-information before evaluating E and save it as r. After evaluating E, we restore the old meta-information. The result from evaluating E is returned. Of course, any time we want to know the cumulative expense for the program, we can examine reify(<runtime>).ticks[4].

Java and Ruby are two examples of popular programming languages that are inherently reflective, and therefore could be used to implement an ROP paradigm.

'''''References'''''

[1] Reflection (Computer Science), Wikipedia: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 
[2] Using Java Reflection, Sun: http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
[3] List of reflective programming languages and platforms, Wikipedia: http://en.wikipedia.org/wiki/List_of_reflective_programming_languages_and_platforms 
[4] An Introduction to Reflection-Oriented Programming, Sobel & Friedman: http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf 
[5] What is Metainformation?: http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci900705,00.html 
[6] Metaprogramming, Wikipedia: http://en.wikipedia.org/wiki/Metaprogramming

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-13T18:41:38Z

Discostu:

== '''Reflection-Oriented Programming''' ==

__TOC__

'''Reflection-Oriented Programming''' (ROP), or "reflective programming", is defined as a programming model design with the intent to analyze and improve it's structure, performance or other implementation aspects during runtime (implying no prior knowledge of the source), as opposed to compile time. ROP is a natural extension to object-oriented programming.

=='''''Concepts'''''==

Two key concepts of ROP are meta-information, which is the state of the program at execution time, and metaprogramming, which is the idea that a language can act as it's own reflection. In other words, a language can reflect (modify) itself. More precisely, we define reflection-oriented programming to be a programming style that uses any means available (reflection or otherwise) to extend the meta-information in order to avoid situations in which a local program's requirements leads to non-local rewriting of said program [4]. Additionally, the ROP concepts extends reflection, in that it can make decisions on the architecture of the system, rather than just methods and variables.

=='''''Reflection vs. ROP'''''==

Reflection is the process by which a computer program can observe and modify it's own structure and behavior[1]. It allows an executing program to examine or "introspect" upon itself, and manipulate internal properties of the program[2]. Java, Ruby and .NET are among the most popular reflective languages, however there are many others[3]. Although reflection is the primary concept behind ROP, it does not necessarily preclude the existence of ROP. ROP is a concept of design; as with most designs, it is not necessarily dependent on the implementation. As an example, computational programming can also be used to implement the concepts of ROP, and does not assume the presence of source code at runtime, something that is essential to the concept of reflection[4].

The ROP metaprogramming model sequences are defined as either atomic (simple) or compound (multi-atomic). These sequences take advantage of meta-information that retains knowledge of program structure, which is different than a classic object-oriented program that can lose said structure after compilation.

=='''''Meta-Information'''''==

Meta-Information, or metadata, is the state of the program at execution time. Phrased another way, Meta-information is information about information. For example, a if a document is considered to be information, its title, location, and subject are examples of meta-information[5]. Meta-Information is essential not only for reflection but for the concepts of ROP to be implemented correctly.

=='''''Metaprogramming'''''==

Metaprogramming introduces the concept of "programs that write programs". Reflection is one type of metaprogramming, and therefore can be considered as an option when attempting to design a system or program based on the concepts defined by ROP. Metaprograms are written in Metalanguage[6], which to be considered for ROP would be defined as the same or alternate language as the system or program to be implemented.

=='''''Examples'''''==

''Simple Reflection''

As an example, first let us review what reflection looks like as an implementation. To see how reflection works, consider this simple example, taken from [http://java.sun.com/developer/technicalArticles/ALT/Reflection/ Using Java Reflection]:

import java.lang.reflect.*;

public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}

For an invocation of:

java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)

That is, the method names of class java.util.Stack are listed, along with their fully qualified parameter and return types.

This program loads the specified class using class.forName, and then calls getDeclaredMethods to retrieve the list of methods defined in the class. java.lang.reflect.Method is a class representing a single class method. Reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing program[2].

''ROP''

ROP is more than just simple reflection (although technically, it can be reflection alone), it is also analyzation or improvement at runtime without prior knowledge of source. A good example of this concept is Measuring Computational Expense. To implement such behavior, we need only these definitions:

define reflective <runtime> (<simple-reflective>)
slot ticks, init-value: 0;
end;

define method atomic (v, outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

define method compound-initial (outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

It is convenient to have default behaviors for atomic, compound-initial, and compound-rest that simply "thread" meta-information through the computations. The inherited definition of compound-rest suffices. Now suppose we want to evaluate some expression E without counting its cost. We could use the reify and reflect operations like this:

let r = reify(<runtime>);
let result = E;
reflect(<runtime>, r, result);

Here we capture the expense meta-information before evaluating E and save it as r. After evaluating E, we restore the old meta-information. The result from evaluating E is returned. Of course, any time we want to know the cumulative expense for the program, we can examine reify(<runtime>).ticks[4].

Java and Ruby are two examples of popular programming languages that are inherently reflective, and therefore could be used to implement an ROP paradigm.

'''''References'''''

[1] Reflection (Computer Science), Wikipedia: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 
[2] Using Java Reflection, Sun: http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
[3] List of reflective programming languages and platforms, Wikipedia: http://en.wikipedia.org/wiki/List_of_reflective_programming_languages_and_platforms 
[4] An Introduction to Reflection-Oriented Programming, Sobel & Friedman: http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf 
[5] What is Metainformation?: http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci900705,00.html 
[6] Metaprogramming, Wikipedia: http://en.wikipedia.org/wiki/Metaprogramming

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-13T18:39:36Z

Discostu:

== '''Reflection-Oriented Programming''' ==

__TOC__

'''Reflection-Oriented Programming''' (ROP), or "reflective programming", is defined as a programming model design with the intent to analyze and improve it's structure, performance or other implementation aspects during runtime (implying no prior knowledge of the source), as opposed to compile time. ROP is a natural extension to object-oriented programming.

=='''''Concepts'''''==

Two key concepts of ROP are meta-information, which is the state of the program at execution time, and metaprogramming, which is the idea that a language can act as it's own reflection. In other words, a language can reflect (modify) itself. More precisely, we define reflection-oriented programming to be a programming style that uses any means available (reflection or otherwise) to extend the meta-information in order to avoid situations in which a local program's requirements leads to non-local rewriting of said program [4]. Additionally, the ROP concepts extends reflection, in that it can make decisions on the architecture of the system, rather than just methods and variables.

=='''''Reflection vs. ROP'''''==

Reflection is the process by which a computer program can observe and modify it's own structure and behavior[1]. It allows an executing program to examine or "introspect" upon itself, and manipulate internal properties of the program[2]. Java, Ruby and .NET are among the most popular reflective languages, however there are many others[3]. Although reflection is the primary concept behind ROP, it does not necessarily preclude the existence of ROP. ROP is a concept of design; as with most designs, it is not necessarily dependent on the implementation. As an example, computational programming can also be used to implement the concepts of ROP, and does not assume the presence of source code at runtime, something that is essential to the concept of reflection[4].

The ROP metaprogramming model sequences are defined as either atomic (simple) or compound (multi-atomic). These sequences take advantage of meta-information that retains knowledge of program structure, which is different than a classic object-oriented program that can lose said structure after compilation.

=='''''Meta-Information'''''==

Meta-Information, or metadata, is the state of the program at execution time. Phrased another way, Meta-information is information about information. For example, a if a document is considered to be information, its title, location, and subject are examples of meta-information[5]. Meta-Information is essential not only for reflection but for the concepts of ROP to be implemented correctly.

=='''''Metaprogramming'''''==

Metaprogramming introduces the concept of "programs that write programs". Reflection is one type of metaprogramming, and therefore can be considered as an option when attempting to design a system or program based on the concepts defined by ROP. Metaprograms are written in Metalanguage[6], which to be considered for ROP would be defined as the same or alternate language as the system or program to be implemented.

=='''''Examples'''''==

''Simple Reflection''

As an example, first let us review what reflection looks like as an implementation. To see how reflection works, consider this simple example, taken from <a href="http://java.sun.com/developer/technicalArticles/ALT/Reflection/">Using Java Reflection</a>:

import java.lang.reflect.*;

public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}

For an invocation of:

java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)

That is, the method names of class java.util.Stack are listed, along with their fully qualified parameter and return types.

This program loads the specified class using class.forName, and then calls getDeclaredMethods to retrieve the list of methods defined in the class. java.lang.reflect.Method is a class representing a single class method. Reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing program[2].

''ROP''

ROP is more than just simple reflection (although technically, it can be reflection alone), it is also analyzation or improvement at runtime without prior knowledge of source. A good example of this concept is Measuring Computational Expense. To implement such behavior, we need only these definitions:

define reflective <runtime> (<simple-reflective>)
slot ticks, init-value: 0;
end;

define method atomic (v, outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

define method compound-initial (outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

It is convenient to have default behaviors for atomic, compound-initial, and compound-rest that simply "thread" meta-information through the computations. The inherited definition of compound-rest suffices. Now suppose we want to evaluate some expression E without counting its cost. We could use the reify and reflect operations like this:

let r = reify(<runtime>);
let result = E;
reflect(<runtime>, r, result);

Here we capture the expense meta-information before evaluating E and save it as r. After evaluating E, we restore the old meta-information. The result from evaluating E is returned. Of course, any time we want to know the cumulative expense for the program, we can examine reify(<runtime>).ticks[4].

Java and Ruby are two examples of popular programming languages that are inherently reflective, and therefore could be used to implement an ROP paradigm.

'''''References'''''

[1] Reflection (Computer Science), Wikipedia: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 
[2] Using Java Reflection, Sun: http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
[3] List of reflective programming languages and platforms, Wikipedia: http://en.wikipedia.org/wiki/List_of_reflective_programming_languages_and_platforms 
[4] An Introduction to Reflection-Oriented Programming, Sobel & Friedman: http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf 
[5] What is Metainformation?: http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci900705,00.html 
[6] Metaprogramming, Wikipedia: http://en.wikipedia.org/wiki/Metaprogramming

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-13T18:38:00Z

Discostu:

== '''Reflection-Oriented Programming''' ==

__TOC__

'''Reflection-Oriented Programming''' (ROP), or "reflective programming", is defined as a programming model design with the intent to analyze and improve it's structure, performance or other implementation aspects during runtime (implying no prior knowledge of the source), as opposed to compile time. ROP is a natural extension to object-oriented programming.

=='''''Concepts'''''==

Two key concepts of ROP are meta-information, which is the state of the program at execution time, and metaprogramming, which is the idea that a language can act as it's own reflection. In other words, a language can reflect (modify) itself. More precisely, we define reflection-oriented programming to be a programming style that uses any means available (reflection or otherwise) to extend the meta-information in order to avoid situations in which a local program's requirements leads to non-local rewriting of said program [4]. Additionally, the ROP concepts extends reflection, in that it can make decisions on the architecture of the system, rather than just methods and variables.

'''''Reflection vs. ROP'''''

Reflection is the process by which a computer program can observe and modify it's own structure and behavior[1]. It allows an executing program to examine or "introspect" upon itself, and manipulate internal properties of the program[2]. Java, Ruby and .NET are among the most popular reflective languages, however there are many others[3]. Although reflection is the primary concept behind ROP, it does not necessarily preclude the existence of ROP. ROP is a concept of design; as with most designs, it is not necessarily dependent on the implementation. As an example, computational programming can also be used to implement the concepts of ROP, and does not assume the presence of source code at runtime, something that is essential to the concept of reflection[4].

The ROP metaprogramming model sequences are defined as either atomic (simple) or compound (multi-atomic). These sequences take advantage of meta-information that retains knowledge of program structure, which is different than a classic object-oriented program that can lose said structure after compilation.

'''''Meta-Information'''''

Meta-Information, or metadata, is the state of the program at execution time. Phrased another way, Meta-information is information about information. For example, a if a document is considered to be information, its title, location, and subject are examples of meta-information[5]. Meta-Information is essential not only for reflection but for the concepts of ROP to be implemented correctly.

'''''Metaprogramming'''''

Metaprogramming introduces the concept of "programs that write programs". Reflection is one type of metaprogramming, and therefore can be considered as an option when attempting to design a system or program based on the concepts defined by ROP. Metaprograms are written in Metalanguage[6], which to be considered for ROP would be defined as the same or alternate language as the system or program to be implemented.

'''''Examples'''''

''Simple Reflection''

As an example, first let us review what reflection looks like as an implementation. To see how reflection works, consider this simple example:

import java.lang.reflect.*;

public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}

For an invocation of:

java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)

That is, the method names of class java.util.Stack are listed, along with their fully qualified parameter and return types.

This program loads the specified class using class.forName, and then calls getDeclaredMethods to retrieve the list of methods defined in the class. java.lang.reflect.Method is a class representing a single class method. Reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing program[2].

''ROP''

ROP is more than just simple reflection (although technically, it can be reflection alone), it is also analyzation or improvement at runtime without prior knowledge of source. A good example of this concept is Measuring Computational Expense. To implement such behavior, we need only these definitions:

define reflective <runtime> (<simple-reflective>)
slot ticks, init-value: 0;
end;

define method atomic (v, outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

define method compound-initial (outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

It is convenient to have default behaviors for atomic, compound-initial, and compound-rest that simply "thread" meta-information through the computations. The inherited definition of compound-rest suffices. Now suppose we want to evaluate some expression E without counting its cost. We could use the reify and reflect operations like this:

let r = reify(<runtime>);
let result = E;
reflect(<runtime>, r, result);

Here we capture the expense meta-information before evaluating E and save it as r. After evaluating E, we restore the old meta-information. The result from evaluating E is returned. Of course, any time we want to know the cumulative expense for the program, we can examine reify(<runtime>).ticks[4].

Java and Ruby are two examples of popular programming languages that are inherently reflective, and therefore could be used to implement an ROP paradigm.

'''''References'''''

[1] Reflection (Computer Science), Wikipedia: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 
[2] Using Java Reflection, Sun: http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
[3] List of reflective programming languages and platforms, Wikipedia: http://en.wikipedia.org/wiki/List_of_reflective_programming_languages_and_platforms 
[4] An Introduction to Reflection-Oriented Programming, Sobel & Friedman: http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf 
[5] What is Metainformation?: http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci900705,00.html 
[6] Metaprogramming, Wikipedia: http://en.wikipedia.org/wiki/Metaprogramming

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-13T18:37:45Z

Discostu:

== '''Reflection-Oriented Programming''' ==

__TOC__

=='''Reflection-Oriented Programming'''== (ROP), or "reflective programming", is defined as a programming model design with the intent to analyze and improve it's structure, performance or other implementation aspects during runtime (implying no prior knowledge of the source), as opposed to compile time. ROP is a natural extension to object-oriented programming.

'''''Concepts'''''

Two key concepts of ROP are meta-information, which is the state of the program at execution time, and metaprogramming, which is the idea that a language can act as it's own reflection. In other words, a language can reflect (modify) itself. More precisely, we define reflection-oriented programming to be a programming style that uses any means available (reflection or otherwise) to extend the meta-information in order to avoid situations in which a local program's requirements leads to non-local rewriting of said program [4]. Additionally, the ROP concepts extends reflection, in that it can make decisions on the architecture of the system, rather than just methods and variables.

'''''Reflection vs. ROP'''''

Reflection is the process by which a computer program can observe and modify it's own structure and behavior[1]. It allows an executing program to examine or "introspect" upon itself, and manipulate internal properties of the program[2]. Java, Ruby and .NET are among the most popular reflective languages, however there are many others[3]. Although reflection is the primary concept behind ROP, it does not necessarily preclude the existence of ROP. ROP is a concept of design; as with most designs, it is not necessarily dependent on the implementation. As an example, computational programming can also be used to implement the concepts of ROP, and does not assume the presence of source code at runtime, something that is essential to the concept of reflection[4].

The ROP metaprogramming model sequences are defined as either atomic (simple) or compound (multi-atomic). These sequences take advantage of meta-information that retains knowledge of program structure, which is different than a classic object-oriented program that can lose said structure after compilation.

'''''Meta-Information'''''

Meta-Information, or metadata, is the state of the program at execution time. Phrased another way, Meta-information is information about information. For example, a if a document is considered to be information, its title, location, and subject are examples of meta-information[5]. Meta-Information is essential not only for reflection but for the concepts of ROP to be implemented correctly.

'''''Metaprogramming'''''

Metaprogramming introduces the concept of "programs that write programs". Reflection is one type of metaprogramming, and therefore can be considered as an option when attempting to design a system or program based on the concepts defined by ROP. Metaprograms are written in Metalanguage[6], which to be considered for ROP would be defined as the same or alternate language as the system or program to be implemented.

'''''Examples'''''

''Simple Reflection''

As an example, first let us review what reflection looks like as an implementation. To see how reflection works, consider this simple example:

import java.lang.reflect.*;

public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}

For an invocation of:

java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)

That is, the method names of class java.util.Stack are listed, along with their fully qualified parameter and return types.

This program loads the specified class using class.forName, and then calls getDeclaredMethods to retrieve the list of methods defined in the class. java.lang.reflect.Method is a class representing a single class method. Reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing program[2].

''ROP''

ROP is more than just simple reflection (although technically, it can be reflection alone), it is also analyzation or improvement at runtime without prior knowledge of source. A good example of this concept is Measuring Computational Expense. To implement such behavior, we need only these definitions:

define reflective <runtime> (<simple-reflective>)
slot ticks, init-value: 0;
end;

define method atomic (v, outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

define method compound-initial (outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

It is convenient to have default behaviors for atomic, compound-initial, and compound-rest that simply "thread" meta-information through the computations. The inherited definition of compound-rest suffices. Now suppose we want to evaluate some expression E without counting its cost. We could use the reify and reflect operations like this:

let r = reify(<runtime>);
let result = E;
reflect(<runtime>, r, result);

Here we capture the expense meta-information before evaluating E and save it as r. After evaluating E, we restore the old meta-information. The result from evaluating E is returned. Of course, any time we want to know the cumulative expense for the program, we can examine reify(<runtime>).ticks[4].

Java and Ruby are two examples of popular programming languages that are inherently reflective, and therefore could be used to implement an ROP paradigm.

'''''References'''''

[1] Reflection (Computer Science), Wikipedia: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 
[2] Using Java Reflection, Sun: http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
[3] List of reflective programming languages and platforms, Wikipedia: http://en.wikipedia.org/wiki/List_of_reflective_programming_languages_and_platforms 
[4] An Introduction to Reflection-Oriented Programming, Sobel & Friedman: http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf 
[5] What is Metainformation?: http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci900705,00.html 
[6] Metaprogramming, Wikipedia: http://en.wikipedia.org/wiki/Metaprogramming

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-13T18:34:38Z

Discostu:

== '''Reflection-Oriented Programming''' ==

'''Reflection-Oriented Programming''' (ROP), or "reflective programming", is defined as a programming model design with the intent to analyze and improve it's structure, performance or other implementation aspects during runtime (implying no prior knowledge of the source), as opposed to compile time. ROP is a natural extension to object-oriented programming.

'''''Concepts'''''

Two key concepts of ROP are meta-information, which is the state of the program at execution time, and metaprogramming, which is the idea that a language can act as it's own reflection. In other words, a language can reflect (modify) itself. More precisely, we define reflection-oriented programming to be a programming style that uses any means available (reflection or otherwise) to extend the meta-information in order to avoid situations in which a local program's requirements leads to non-local rewriting of said program [4]. Additionally, the ROP concepts extends reflection, in that it can make decisions on the architecture of the system, rather than just methods and variables.

'''''Reflection vs. ROP'''''

Reflection is the process by which a computer program can observe and modify it's own structure and behavior[1]. It allows an executing program to examine or "introspect" upon itself, and manipulate internal properties of the program[2]. Java, Ruby and .NET are among the most popular reflective languages, however there are many others[3]. Although reflection is the primary concept behind ROP, it does not necessarily preclude the existence of ROP. ROP is a concept of design; as with most designs, it is not necessarily dependent on the implementation. As an example, computational programming can also be used to implement the concepts of ROP, and does not assume the presence of source code at runtime, something that is essential to the concept of reflection[4].

The ROP metaprogramming model sequences are defined as either atomic (simple) or compound (multi-atomic). These sequences take advantage of meta-information that retains knowledge of program structure, which is different than a classic object-oriented program that can lose said structure after compilation.

'''''Meta-Information'''''

Meta-Information, or metadata, is the state of the program at execution time. Phrased another way, Meta-information is information about information. For example, a if a document is considered to be information, its title, location, and subject are examples of meta-information[5]. Meta-Information is essential not only for reflection but for the concepts of ROP to be implemented correctly.

'''''Metaprogramming'''''

Metaprogramming introduces the concept of "programs that write programs". Reflection is one type of metaprogramming, and therefore can be considered as an option when attempting to design a system or program based on the concepts defined by ROP. Metaprograms are written in Metalanguage[6], which to be considered for ROP would be defined as the same or alternate language as the system or program to be implemented.

'''''Examples'''''

''Simple Reflection''

As an example, first let us review what reflection looks like as an implementation. To see how reflection works, consider this simple example:

import java.lang.reflect.*;

public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}

For an invocation of:

java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)

That is, the method names of class java.util.Stack are listed, along with their fully qualified parameter and return types.

This program loads the specified class using class.forName, and then calls getDeclaredMethods to retrieve the list of methods defined in the class. java.lang.reflect.Method is a class representing a single class method. Reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing program[2].

''ROP''

ROP is more than just simple reflection (although technically, it can be reflection alone), it is also analyzation or improvement at runtime without prior knowledge of source. A good example of this concept is Measuring Computational Expense. To implement such behavior, we need only these definitions:

define reflective <runtime> (<simple-reflective>)
slot ticks, init-value: 0;
end;

define method atomic (v, outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

define method compound-initial (outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

It is convenient to have default behaviors for atomic, compound-initial, and compound-rest that simply "thread" meta-information through the computations. The inherited definition of compound-rest suffices. Now suppose we want to evaluate some expression E without counting its cost. We could use the reify and reflect operations like this:

let r = reify(<runtime>);
let result = E;
reflect(<runtime>, r, result);

Here we capture the expense meta-information before evaluating E and save it as r. After evaluating E, we restore the old meta-information. The result from evaluating E is returned. Of course, any time we want to know the cumulative expense for the program, we can examine reify(<runtime>).ticks[4].

Java and Ruby are two examples of popular programming languages that are inherently reflective, and therefore could be used to implement an ROP paradigm.

'''''References'''''

[1] Reflection (Computer Science), Wikipedia: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 
[2] Using Java Reflection, Sun: http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
[3] List of reflective programming languages and platforms, Wikipedia: http://en.wikipedia.org/wiki/List_of_reflective_programming_languages_and_platforms 
[4] An Introduction to Reflection-Oriented Programming, Sobel & Friedman: http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf 
[5] What is Metainformation?: http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci900705,00.html 
[6] Metaprogramming, Wikipedia: http://en.wikipedia.org/wiki/Metaprogramming

__TOC__

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-13T18:34:04Z

Discostu:

== '''Reflection-Oriented Programming''' ==

__TOC__ Concepts

'''Reflection-Oriented Programming''' (ROP), or "reflective programming", is defined as a programming model design with the intent to analyze and improve it's structure, performance or other implementation aspects during runtime (implying no prior knowledge of the source), as opposed to compile time. ROP is a natural extension to object-oriented programming.

'''''Concepts'''''

Two key concepts of ROP are meta-information, which is the state of the program at execution time, and metaprogramming, which is the idea that a language can act as it's own reflection. In other words, a language can reflect (modify) itself. More precisely, we define reflection-oriented programming to be a programming style that uses any means available (reflection or otherwise) to extend the meta-information in order to avoid situations in which a local program's requirements leads to non-local rewriting of said program [4]. Additionally, the ROP concepts extends reflection, in that it can make decisions on the architecture of the system, rather than just methods and variables.

'''''Reflection vs. ROP'''''

Reflection is the process by which a computer program can observe and modify it's own structure and behavior[1]. It allows an executing program to examine or "introspect" upon itself, and manipulate internal properties of the program[2]. Java, Ruby and .NET are among the most popular reflective languages, however there are many others[3]. Although reflection is the primary concept behind ROP, it does not necessarily preclude the existence of ROP. ROP is a concept of design; as with most designs, it is not necessarily dependent on the implementation. As an example, computational programming can also be used to implement the concepts of ROP, and does not assume the presence of source code at runtime, something that is essential to the concept of reflection[4].

The ROP metaprogramming model sequences are defined as either atomic (simple) or compound (multi-atomic). These sequences take advantage of meta-information that retains knowledge of program structure, which is different than a classic object-oriented program that can lose said structure after compilation.

'''''Meta-Information'''''

Meta-Information, or metadata, is the state of the program at execution time. Phrased another way, Meta-information is information about information. For example, a if a document is considered to be information, its title, location, and subject are examples of meta-information[5]. Meta-Information is essential not only for reflection but for the concepts of ROP to be implemented correctly.

'''''Metaprogramming'''''

Metaprogramming introduces the concept of "programs that write programs". Reflection is one type of metaprogramming, and therefore can be considered as an option when attempting to design a system or program based on the concepts defined by ROP. Metaprograms are written in Metalanguage[6], which to be considered for ROP would be defined as the same or alternate language as the system or program to be implemented.

'''''Examples'''''

''Simple Reflection''

As an example, first let us review what reflection looks like as an implementation. To see how reflection works, consider this simple example:

import java.lang.reflect.*;

public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}

For an invocation of:

java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)

That is, the method names of class java.util.Stack are listed, along with their fully qualified parameter and return types.

This program loads the specified class using class.forName, and then calls getDeclaredMethods to retrieve the list of methods defined in the class. java.lang.reflect.Method is a class representing a single class method. Reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing program[2].

''ROP''

ROP is more than just simple reflection (although technically, it can be reflection alone), it is also analyzation or improvement at runtime without prior knowledge of source. A good example of this concept is Measuring Computational Expense. To implement such behavior, we need only these definitions:

define reflective <runtime> (<simple-reflective>)
slot ticks, init-value: 0;
end;

define method atomic (v, outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

define method compound-initial (outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

It is convenient to have default behaviors for atomic, compound-initial, and compound-rest that simply "thread" meta-information through the computations. The inherited definition of compound-rest suffices. Now suppose we want to evaluate some expression E without counting its cost. We could use the reify and reflect operations like this:

let r = reify(<runtime>);
let result = E;
reflect(<runtime>, r, result);

Here we capture the expense meta-information before evaluating E and save it as r. After evaluating E, we restore the old meta-information. The result from evaluating E is returned. Of course, any time we want to know the cumulative expense for the program, we can examine reify(<runtime>).ticks[4].

Java and Ruby are two examples of popular programming languages that are inherently reflective, and therefore could be used to implement an ROP paradigm.

'''''References'''''

[1] Reflection (Computer Science), Wikipedia: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 
[2] Using Java Reflection, Sun: http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
[3] List of reflective programming languages and platforms, Wikipedia: http://en.wikipedia.org/wiki/List_of_reflective_programming_languages_and_platforms 
[4] An Introduction to Reflection-Oriented Programming, Sobel & Friedman: http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf 
[5] What is Metainformation?: http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci900705,00.html 
[6] Metaprogramming, Wikipedia: http://en.wikipedia.org/wiki/Metaprogramming

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-13T18:33:41Z

Discostu:

== '''Reflection-Oriented Programming''' ==

__TOC__
Concepts

'''Reflection-Oriented Programming''' (ROP), or "reflective programming", is defined as a programming model design with the intent to analyze and improve it's structure, performance or other implementation aspects during runtime (implying no prior knowledge of the source), as opposed to compile time. ROP is a natural extension to object-oriented programming.

'''''Concepts'''''

Two key concepts of ROP are meta-information, which is the state of the program at execution time, and metaprogramming, which is the idea that a language can act as it's own reflection. In other words, a language can reflect (modify) itself. More precisely, we define reflection-oriented programming to be a programming style that uses any means available (reflection or otherwise) to extend the meta-information in order to avoid situations in which a local program's requirements leads to non-local rewriting of said program [4]. Additionally, the ROP concepts extends reflection, in that it can make decisions on the architecture of the system, rather than just methods and variables.

'''''Reflection vs. ROP'''''

Reflection is the process by which a computer program can observe and modify it's own structure and behavior[1]. It allows an executing program to examine or "introspect" upon itself, and manipulate internal properties of the program[2]. Java, Ruby and .NET are among the most popular reflective languages, however there are many others[3]. Although reflection is the primary concept behind ROP, it does not necessarily preclude the existence of ROP. ROP is a concept of design; as with most designs, it is not necessarily dependent on the implementation. As an example, computational programming can also be used to implement the concepts of ROP, and does not assume the presence of source code at runtime, something that is essential to the concept of reflection[4].

The ROP metaprogramming model sequences are defined as either atomic (simple) or compound (multi-atomic). These sequences take advantage of meta-information that retains knowledge of program structure, which is different than a classic object-oriented program that can lose said structure after compilation.

'''''Meta-Information'''''

Meta-Information, or metadata, is the state of the program at execution time. Phrased another way, Meta-information is information about information. For example, a if a document is considered to be information, its title, location, and subject are examples of meta-information[5]. Meta-Information is essential not only for reflection but for the concepts of ROP to be implemented correctly.

'''''Metaprogramming'''''

Metaprogramming introduces the concept of "programs that write programs". Reflection is one type of metaprogramming, and therefore can be considered as an option when attempting to design a system or program based on the concepts defined by ROP. Metaprograms are written in Metalanguage[6], which to be considered for ROP would be defined as the same or alternate language as the system or program to be implemented.

'''''Examples'''''

''Simple Reflection''

As an example, first let us review what reflection looks like as an implementation. To see how reflection works, consider this simple example:

import java.lang.reflect.*;

public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}

For an invocation of:

java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)

That is, the method names of class java.util.Stack are listed, along with their fully qualified parameter and return types.

This program loads the specified class using class.forName, and then calls getDeclaredMethods to retrieve the list of methods defined in the class. java.lang.reflect.Method is a class representing a single class method. Reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing program[2].

''ROP''

ROP is more than just simple reflection (although technically, it can be reflection alone), it is also analyzation or improvement at runtime without prior knowledge of source. A good example of this concept is Measuring Computational Expense. To implement such behavior, we need only these definitions:

define reflective <runtime> (<simple-reflective>)
slot ticks, init-value: 0;
end;

define method atomic (v, outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

define method compound-initial (outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

It is convenient to have default behaviors for atomic, compound-initial, and compound-rest that simply "thread" meta-information through the computations. The inherited definition of compound-rest suffices. Now suppose we want to evaluate some expression E without counting its cost. We could use the reify and reflect operations like this:

let r = reify(<runtime>);
let result = E;
reflect(<runtime>, r, result);

Here we capture the expense meta-information before evaluating E and save it as r. After evaluating E, we restore the old meta-information. The result from evaluating E is returned. Of course, any time we want to know the cumulative expense for the program, we can examine reify(<runtime>).ticks[4].

Java and Ruby are two examples of popular programming languages that are inherently reflective, and therefore could be used to implement an ROP paradigm.

'''''References'''''

[1] Reflection (Computer Science), Wikipedia: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 
[2] Using Java Reflection, Sun: http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
[3] List of reflective programming languages and platforms, Wikipedia: http://en.wikipedia.org/wiki/List_of_reflective_programming_languages_and_platforms 
[4] An Introduction to Reflection-Oriented Programming, Sobel & Friedman: http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf 
[5] What is Metainformation?: http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci900705,00.html 
[6] Metaprogramming, Wikipedia: http://en.wikipedia.org/wiki/Metaprogramming

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-13T18:33:13Z

Discostu:

== '''Reflection-Oriented Programming''' ==

__TOC__

'''Reflection-Oriented Programming''' (ROP), or "reflective programming", is defined as a programming model design with the intent to analyze and improve it's structure, performance or other implementation aspects during runtime (implying no prior knowledge of the source), as opposed to compile time. ROP is a natural extension to object-oriented programming.

'''''Concepts'''''

Two key concepts of ROP are meta-information, which is the state of the program at execution time, and metaprogramming, which is the idea that a language can act as it's own reflection. In other words, a language can reflect (modify) itself. More precisely, we define reflection-oriented programming to be a programming style that uses any means available (reflection or otherwise) to extend the meta-information in order to avoid situations in which a local program's requirements leads to non-local rewriting of said program [4]. Additionally, the ROP concepts extends reflection, in that it can make decisions on the architecture of the system, rather than just methods and variables.

'''''Reflection vs. ROP'''''

Reflection is the process by which a computer program can observe and modify it's own structure and behavior[1]. It allows an executing program to examine or "introspect" upon itself, and manipulate internal properties of the program[2]. Java, Ruby and .NET are among the most popular reflective languages, however there are many others[3]. Although reflection is the primary concept behind ROP, it does not necessarily preclude the existence of ROP. ROP is a concept of design; as with most designs, it is not necessarily dependent on the implementation. As an example, computational programming can also be used to implement the concepts of ROP, and does not assume the presence of source code at runtime, something that is essential to the concept of reflection[4].

The ROP metaprogramming model sequences are defined as either atomic (simple) or compound (multi-atomic). These sequences take advantage of meta-information that retains knowledge of program structure, which is different than a classic object-oriented program that can lose said structure after compilation.

'''''Meta-Information'''''

Meta-Information, or metadata, is the state of the program at execution time. Phrased another way, Meta-information is information about information. For example, a if a document is considered to be information, its title, location, and subject are examples of meta-information[5]. Meta-Information is essential not only for reflection but for the concepts of ROP to be implemented correctly.

'''''Metaprogramming'''''

Metaprogramming introduces the concept of "programs that write programs". Reflection is one type of metaprogramming, and therefore can be considered as an option when attempting to design a system or program based on the concepts defined by ROP. Metaprograms are written in Metalanguage[6], which to be considered for ROP would be defined as the same or alternate language as the system or program to be implemented.

'''''Examples'''''

''Simple Reflection''

As an example, first let us review what reflection looks like as an implementation. To see how reflection works, consider this simple example:

import java.lang.reflect.*;

public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}

For an invocation of:

java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)

That is, the method names of class java.util.Stack are listed, along with their fully qualified parameter and return types.

This program loads the specified class using class.forName, and then calls getDeclaredMethods to retrieve the list of methods defined in the class. java.lang.reflect.Method is a class representing a single class method. Reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing program[2].

''ROP''

ROP is more than just simple reflection (although technically, it can be reflection alone), it is also analyzation or improvement at runtime without prior knowledge of source. A good example of this concept is Measuring Computational Expense. To implement such behavior, we need only these definitions:

define reflective <runtime> (<simple-reflective>)
slot ticks, init-value: 0;
end;

define method atomic (v, outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

define method compound-initial (outer :: <runtime>)
update(outer, ticks: add1(outer.ticks))
end;

It is convenient to have default behaviors for atomic, compound-initial, and compound-rest that simply "thread" meta-information through the computations. The inherited definition of compound-rest suffices. Now suppose we want to evaluate some expression E without counting its cost. We could use the reify and reflect operations like this:

let r = reify(<runtime>);
let result = E;
reflect(<runtime>, r, result);

Here we capture the expense meta-information before evaluating E and save it as r. After evaluating E, we restore the old meta-information. The result from evaluating E is returned. Of course, any time we want to know the cumulative expense for the program, we can examine reify(<runtime>).ticks[4].

Java and Ruby are two examples of popular programming languages that are inherently reflective, and therefore could be used to implement an ROP paradigm.

'''''References'''''

[1] Reflection (Computer Science), Wikipedia: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 
[2] Using Java Reflection, Sun: http://java.sun.com/developer/technicalArticles/ALT/Reflection/ 
[3] List of reflective programming languages and platforms, Wikipedia: http://en.wikipedia.org/wiki/List_of_reflective_programming_languages_and_platforms 
[4] An Introduction to Reflection-Oriented Programming, Sobel & Friedman: http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/sobel.pdf 
[5] What is Metainformation?: http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci900705,00.html 
[6] Metaprogramming, Wikipedia: http://en.wikipedia.org/wiki/Metaprogramming

CSC/ECE 517 Fall 2009/wiki2pthelm

2009-10-09T20:39:03Z

Discostu: