Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T03:05:18Z

Gohan: /* Design by Contract */

'''Programming by Assertion'''

== Introduction to Assertions ==

Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort or execute an exception handler. Typically if program is aborted the expression and line number are displayed to standard error as well.

== Design by Contract ==
Assertions are used in a facility called [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract].
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of [http://en.wikipedia.org/wiki/Precondition preconditions], [http://en.wikipedia.org/wiki/Postcondition postconditions], [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants], and general errors. These specifications of "contract" define the interface of different element of software includes method, class, module, etc.

For detail information of contract, please refers to the helpful reading list in [2].

=== Design by Contract Benefits ===
* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== Precondition and Postcondition contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>

=== Invariant contract ===
Here is simple example of invariant condition. Physically a size of a container should be 0 or positive.
<pre>
assert(size >= 0)
</pre>

=== General Assertion Error ===
Assertion will fail here if there is not any memory to allocate.
<pre>
int* ptr = (int) malloc(sizeof(int));
assert(ptr != NULL);
</pre>

=== In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

== Assertion Advantages ==
* Since they help clarifiy program constraints and assumptions they help with providing documentation.
* Provide runtime verification, which leads to continious and ongoing testing.
* Can perform Validations deep inside of a private method or in general a method not publicly visible.
* When used inside of classes they are encapuslated and hidden from the client. (helps client isolate problem to either client code or provided code)

== Assertion Disadvantages ==
* If not turned off they can lead to serious performance implications (e.g. asserting a list is sorted)
* Not useful when validaton and output for a given input over a range of scenarios
* If assumptons are to restrictive assertions indicate bugs that are potentially false positives.

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract

[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T03:04:48Z

Gohan: /* Assertion Advantages */

'''Programming by Assertion'''

== Introduction to Assertions ==

Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort or execute an exception handler. Typically if program is aborted the expression and line number are displayed to standard error as well.

=== Design by Contract ===
Assertions are used in a facility called [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract].
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of [http://en.wikipedia.org/wiki/Precondition preconditions], [http://en.wikipedia.org/wiki/Postcondition postconditions], [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants], and general errors. These specifications of "contract" define the interface of different element of software includes method, class, module, etc.

For detail information of contract, please refers to the helpful reading list in [2].

==== Design by Contract Benefits ====
* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== Precondition and Postcondition contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>

=== Invariant contract ===
Here is simple example of invariant condition. Physically a size of a container should be 0 or positive.
<pre>
assert(size >= 0)
</pre>

=== General Assertion Error ===
Assertion will fail here if there is not any memory to allocate.
<pre>
int* ptr = (int) malloc(sizeof(int));
assert(ptr != NULL);
</pre>

=== In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

== Assertion Advantages ==
* Since they help clarifiy program constraints and assumptions they help with providing documentation.
* Provide runtime verification, which leads to continious and ongoing testing.
* Can perform Validations deep inside of a private method or in general a method not publicly visible.
* When used inside of classes they are encapuslated and hidden from the client. (helps client isolate problem to either client code or provided code)

== Assertion Disadvantages ==
* If not turned off they can lead to serious performance implications (e.g. asserting a list is sorted)
* Not useful when validaton and output for a given input over a range of scenarios
* If assumptons are to restrictive assertions indicate bugs that are potentially false positives.

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract

[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:50:16Z

Gohan:

'''Programming by Assertion'''

== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort or execute an exception handler. Typically if program is aborted the expression and line number are displayed to standard error as well.

=== Design by Contract ===
Assertions are used in a facility called [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract].
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of [http://en.wikipedia.org/wiki/Precondition preconditions], [http://en.wikipedia.org/wiki/Postcondition postconditions], [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants], and general errors. These specifications of "contract" define the interface of different element of software includes method, class, module, etc.

For detail information of contract, please refers to the helpful reading list in [2].

==== Design by Contract Benefits ====
* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== Precondition and Postcondition contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>

=== Invariant contract ===
Here is simple example of invariant condition. Physically a size of a container should be 0 or positive.
<pre>
assert(size >= 0)
</pre>

=== General Assertion Error ===
Assertion will fail here if there is not any memory to allocate.
<pre>
int* ptr = (int) malloc(sizeof(int));
assert(ptr != NULL);
</pre>

=== In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

== Assertion Advantages ==
* Since they help clarifiy program constraints and assumptions they help with providing documentation.
* Provide runtime verification, which leads to continious and ongoing testing.
* Can perform Validations deep inside of a private method or in general a method not publicly visible.
* When used inside of classes they are encapuslated and hidden from the client. (helps client isolate problem to either client code or provide code)

== Assertion Disadvantages ==
* If not turned off they can lead to serious performance implications (e.g. asserting a list is sorted)
* Not useful when validaton and output for a given input over a range of scenarios
* If assumptons are to restrictive assertions indicate bugs that are potentially false positives.

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract

[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:49:43Z

Gohan: /* References */

'''Programming by Assertion'''

== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort or execute an exception handler. Typically if program is aborted the expression and line number are displayed to standard error as well.

=== Design by Contract ===
Assertions are used in a facility called [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract].
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of [http://en.wikipedia.org/wiki/Precondition preconditions], [http://en.wikipedia.org/wiki/Postcondition postconditions], [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants], and general errors. These specifications of "contract" define the interface of different element of software includes method, class, module, etc.

For detail information of contract, please refers to the helpful reading list in [2].

==== Design by Contract Benefits ====
* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== Precondition and Postcondition contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>

=== Invariant contract ===
Here is simple example of invariant condition. Physically a size of a container should be 0 or positive.
<pre>
assert(size >= 0)
</pre>

=== General Assertion Error ===
Assertion will fail here if there is not any memory to allocate.
<pre>
int* ptr = (int) malloc(sizeof(int));
assert(ptr != NULL);
</pre>

=== In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

== Assertion Advantages ==
* Since they help clarifiy program constraints and assumptions they help with providing documentation.
* Provide runtime verification, which leads to continious and ongoing testing.
* Can perform Validations deep inside of a private method or in general a method not publicly visible.
* When used inside of classes they are encapuslated and hidden from the client. (helps client isolate problem to either client code or provide code)

== Assertion Disadvantages ==
* If not turned off they can lead to serious performance implications (e.g. asserting a list is sorted)
* Not useful when validaton and output for a given input over a range of scenarios
* If assumptons are to restrictive assertions indicate bugs that are potentially false positives.

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract

[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:48:49Z

Gohan:

'''Programming by Assertion'''

== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort or execute an exception handler. Typically if program is aborted the expression and line number are displayed to standard error as well.

=== Design by Contract ===
Assertions are used in a facility called [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract].
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of [http://en.wikipedia.org/wiki/Precondition preconditions], [http://en.wikipedia.org/wiki/Postcondition postconditions], [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants], and general errors. These specifications of "contract" define the interface of different element of software includes method, class, module, etc.

For detail information of contract, please refers to the helpful reading list in [2].

==== Design by Contract Benefits ====
* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== Precondition and Postcondition contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>

=== Invariant contract ===
Here is simple example of invariant condition. Physically a size of a container should be 0 or positive.
<pre>
assert(size >= 0)
</pre>

=== General Assertion Error ===
Assertion will fail here if there is not any memory to allocate.
<pre>
int* ptr = (int) malloc(sizeof(int));
assert(ptr != NULL);
</pre>

=== In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

== Assertion Advantages ==
* Since they help clarifiy program constraints and assumptions they help with providing documentation.
* Provide runtime verification, which leads to continious and ongoing testing.
* Can perform Validations deep inside of a private method or in general a method not publicly visible.
* When used inside of classes they are encapuslated and hidden from the client. (helps client isolate problem to either client code or provide code)

== Assertion Disadvantages ==
* If not turned off they can lead to serious performance implications (e.g. asserting a list is sorted)
* Not useful when validaton and output for a given input over a range of scenarios
* If assumptons are to restrictive assertions indicate bugs that are potentially false positives.

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:47:54Z

Gohan:

'''Programming by Assertion'''

== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort or execute an exception handler. Typically if program is aborted the expression and line number are displayed to standard error as well.

=== Design by Contract ===
Assertions are used in a facility called [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract].
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of [http://en.wikipedia.org/wiki/Precondition preconditions], [http://en.wikipedia.org/wiki/Postcondition postconditions], [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants], and general errors. These specifications of "contract" define the interface of different element of software includes method, class, module, etc.

For detail information of contract, please refers to the helpful reading list in [2].

==== Design by Contract Benefits ====
* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== Precondition and Postcondition contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>

=== Invariant contract ===
Here is simple example of invariant condition. Physically a size of a container should be 0 or positive.
<pre>
assert(size >= 0)
</pre>

=== General Assertion Error ===
Assertion will fail here if there is not any memory to allocate.
<pre>
int* ptr = (int) malloc(sizeof(int));
assert(ptr != NULL);
</pre>

=== In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

== Assertion Advantages ==
Since they help clarifiy program constraints and assumptions they help with providing documentation.
Provide runtime verification, which leads to continious and ongoing testing.
Can perform Validations deep inside of a private method or in general a method not publicly visible.
When used inside of classes they are encapuslated and hidden from the client. (helps client isolate problem to code

== Assertion Disadvantages ==
If not turned off they can lead to serious performance implications (e.g. asserting a list is sorted)
Not useful when validaton and output for a given input over a range of scenarios
If assumptons are to restrictive assertions indicate bugs that are potentially false positives.

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:35:47Z

Gohan:

'''Programming by Assertion'''

== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort or execute an exception handler. Typically if program is aborted the expression and line number are displayed to standard error as well.

=== Design by Contract ===
Assertions are used in a facility called [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract].
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of [http://en.wikipedia.org/wiki/Precondition preconditions], [http://en.wikipedia.org/wiki/Postcondition postconditions], [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants], and general errors. These specifications of "contract" define the interface of different element of software includes method, class, module, etc.

==== Design by Contract Benefits ====
* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== Precondition and Postcondition contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>

=== Invariant contract ===
Here is simple example of invariant condition. Physically a size of a container should be 0 or positive.
<pre>
assert(size >= 0)
</pre>

=== In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

for detail information of contract, please refers to the helpful reading list in [2].

== The advantages of Contract Programming==

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:33:01Z

Gohan:

'''Programming by Assertion'''

== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort or execute an exception handler. Typically if program is aborted the expression and line number are displayed to standard error as well.

=== Design by Contract ===
Assertions are used in a facility called [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract].
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of [http://en.wikipedia.org/wiki/Precondition preconditions], [http://en.wikipedia.org/wiki/Postcondition postconditions], [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants], and general errors. These specifications of "contract" define the interface of different element of software includes method, class, module, etc.

==== Design by Contract Benefits ====
* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== Precondition and Postcondition contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>

=== In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

===Class Invariants ===
Class invariants are used to specify characteristics of a class that always must be true (except while executing a member function). They are described in Classes.

for detail information of contract, please refers to the helpful reading list in [2].

==The advantages of Contract Programming==

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:30:20Z

Gohan:

'''Programming by Assertion'''

== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort. Typically the expression and line number are displayed to standard error as well.

=== Design by Contract ===
Assertions are used in a facility called [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract].
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of [http://en.wikipedia.org/wiki/Precondition preconditions], [http://en.wikipedia.org/wiki/Postcondition postconditions], [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants], and general errors. These specifications of "contract" define the interface of different element of software includes method, class, module, etc.

==== Design by Contract Benefits ====
* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

===Assert contract===
The most basic contract is the assert. An assert inserts a checkable expression into the code, and that expression must evaluate to true:

an assert in function bodies works by throwing an AssertError, which can be caught and handled. Catching the contract violation is useful when the code must deal with errant uses by other code, when it must be failure proof, and as a useful tool for debugging.

===Pre and Post contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>
===In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

===Class Invariants ===
Class invariants are used to specify characteristics of a class that always must be true (except while executing a member function). They are described in Classes.

for detail information of contract, please refers to the helpful reading list in [2].

==The advantages of Contract Programming==

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:26:57Z

Gohan:

'''Programming by Assertion'''

== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort. Typically the expression and line number are displayed to standard error as well.

=== Design by Contract ===
Assertions are used in a facility called [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract].
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of preconditions, postconditions, errors, and invariants. These specifications of "contract" define the interface of different element of software includes method, class, module...

===Assert contract===
The most basic contract is the assert. An assert inserts a checkable expression into the code, and that expression must evaluate to true:

an assert in function bodies works by throwing an AssertError, which can be caught and handled. Catching the contract violation is useful when the code must deal with errant uses by other code, when it must be failure proof, and as a useful tool for debugging.

===Pre and Post contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>
===In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

===Class Invariants ===
Class invariants are used to specify characteristics of a class that always must be true (except while executing a member function). They are described in Classes.

for detail information of contract, please refers to the helpful reading list in [2].

==The advantages of Contract Programming==

* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== The disadvantages of Contract Programming ===

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:25:16Z

Gohan:

'''Programming by Assertion'''

== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort. Typically the expression and line number are displayed to standard error as well.

=== Design by Contract ===
Assertions are used in a facility called [Design by Contract], http://en.wikipedia.org/wiki/Design_by_contract.
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of preconditions, postconditions, errors, and invariants. These specifications of "contract" define the interface of different element of software includes method, class, module...

===Assert contract===
The most basic contract is the assert. An assert inserts a checkable expression into the code, and that expression must evaluate to true:

an assert in function bodies works by throwing an AssertError, which can be caught and handled. Catching the contract violation is useful when the code must deal with errant uses by other code, when it must be failure proof, and as a useful tool for debugging.

===Pre and Post contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>
===In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

===Class Invariants ===
Class invariants are used to specify characteristics of a class that always must be true (except while executing a member function). They are described in Classes.

for detail information of contract, please refers to the helpful reading list in [2].

==The advantages of Contract Programming==

* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== The disadvantages of Contract Programming ===

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:23:05Z

Gohan:

'''Programming by Assertion'''

== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort. Typically the expression and line number are displayed to standard error as well.

Assertions are used in a facility called [Design by Contract]
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of preconditions, postconditions, errors, and invariants. These specifications of "contract" define the interface of different element of software includes method, class, module...

===Assert contract===
The most basic contract is the assert. An assert inserts a checkable expression into the code, and that expression must evaluate to true:

an assert in function bodies works by throwing an AssertError, which can be caught and handled. Catching the contract violation is useful when the code must deal with errant uses by other code, when it must be failure proof, and as a useful tool for debugging.

===Pre and Post contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>
===In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

===Class Invariants ===
Class invariants are used to specify characteristics of a class that always must be true (except while executing a member function). They are described in Classes.

for detail information of contract, please refers to the helpful reading list in [2].

==The advantages of Contract Programming==

* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== The disadvantages of Contract Programming ===

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:18:46Z

Gohan:

'''Programming by Assertion'''

== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.
<pre>
assert(expression);
</pre>

Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of preconditions, postconditions, errors, and invariants. These specifications of "contract" define the interface of different element of software includes method, class, module...

===Assert contract===
The most basic contract is the assert. An assert inserts a checkable expression into the code, and that expression must evaluate to true:

an assert in function bodies works by throwing an AssertError, which can be caught and handled. Catching the contract violation is useful when the code must deal with errant uses by other code, when it must be failure proof, and as a useful tool for debugging.

===Pre and Post contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>
===In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

===Class Invariants ===
Class invariants are used to specify characteristics of a class that always must be true (except while executing a member function). They are described in Classes.

for detail information of contract, please refers to the helpful reading list in [2].

==The advantages of Contract Programming==

* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== The disadvantages of Contract Programming ===

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:17:03Z

Gohan:

'''Programming by Assertion'''

== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

The Asset Statement
<pre>
assert(expression);
</pre>

Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of preconditions, postconditions, errors, and invariants. These specifications of "contract" define the interface of different element of software includes method, class, module...

===Assert contract===
The most basic contract is the assert. An assert inserts a checkable expression into the code, and that expression must evaluate to true:

an assert in function bodies works by throwing an AssertError, which can be caught and handled. Catching the contract violation is useful when the code must deal with errant uses by other code, when it must be failure proof, and as a useful tool for debugging.

===Pre and Post contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>
===In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

===Class Invariants ===
Class invariants are used to specify characteristics of a class that always must be true (except while executing a member function). They are described in Classes.

for detail information of contract, please refers to the helpful reading list in [2].

==The advantages of Contract Programming==

* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== The disadvantages of Contract Programming ===

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki3 15 SJ3

2009-11-19T00:13:37Z

Gohan:

'''Advantages and Disadvantages of Programming by Contract'''

== Introduction of Contract Programming ==

Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of preconditions, postconditions, errors, and invariants. These specifications of "contract" define the interface of different element of software includes method, class, module...

===Assert contract===
The most basic contract is the assert. An assert inserts a checkable expression into the code, and that expression must evaluate to true:
<pre>
assert(expression);
</pre>
an assert in function bodies works by throwing an AssertError, which can be caught and handled. Catching the contract violation is useful when the code must deal with errant uses by other code, when it must be failure proof, and as a useful tool for debugging.

===Pre and Post contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
<pre>
long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}
</pre>
===In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

===Class Invariants ===
Class invariants are used to specify characteristics of a class that always must be true (except while executing a member function). They are described in Classes.

for detail information of contract, please refers to the helpful reading list in [2].

==The advantages of Contract Programming==

* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

=== The disadvantages of Contract Programming ===

== References ==

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

CSC/ECE 517 Fall 2009/wiki 1a 9b SJ

2009-09-09T20:15:03Z

Gohan:

== What is Code Refactoring ==
According to the famous book "Refactoring: Improving the Design of Existing Code " by Martin Fowler: Refactoring is the process of applying behavior-preserving transformations to a program with the objective of improving the program’s design. Intuitively people refer to code refactoring as "cleaning it up".

=== Motivation of Refactoring ===
Refactoring is very useful for software engineer to maintain the quality of their code in different environment. In fact, no software can be guaranteed to be perfect when it is first developed. Usually when the source code is applied to different customer needs, we want to improve the inner-structure without modify the external behavior. The ability to refactor your code takes the pressure off the design phase of software development. Refactoring gives you the ability to change the design of the code at a later stage. This means that you don’t have to get the design absolutely right before you write any code. You can get a rough design worked out, code it up and then if (when) you spot a better design you can refactor your code towards the better design.

=== List of Common Refactorings ===
In the following we list some popular refactoring to specify how refactoring transform the code. For more detail information, the reader please refer to the section 2.1.2 of the thesis of Thomas Corbat[1]. [1] provide Ruby example for each refactoring this list .

{|
| 1. Merge Class Parts
|-
| 2. Convert Local Variable to Field
|-
| 3. Encapsulate Field
|-
| 4. Extract Method
|-
| 5. Inline Class
|-
| 6. Inline Method
|-
| 7. Move Field
|-
| 8. Move Method
|-
| 9. Rename Class
|-
| 10. Rename Field
|-
| 11. Rename Local Variable
|-
| 12. Rename Method
|-
| 13. Replace Temporary Variable with Query
|-
| 14. Split Temporary Variable
|}

=== Ruby Example of Refactoring ===
before rename:

def badRenameMethod
puts("Hello World");
end

after rename:

def hello
puts("Hello World");
end

before encapsulation:

class SomeClass
def initialize
@field = 0;
end
end

after encapsulation:

class SomeClass
def initialize
@field = 0;
end

def field
@field
end
private :field

def field= field
@field = field
end
private :field=
end

=== Java Example of Refactoring ===
before rename:

public class rename_method
{
static void badRenameMethod()
{
System.out.println("Hello, world!");
}
}

after rename:

public class rename_method
{
static void hello()
{
System.out.println("Hello, world!");
}
}

before encapsulation:

public class encap_field
{
public String field;
}

after encapsulation:

public class encap_field
{
private int field;

public void setField(int field)
{
this.field = field;
}

public int getField()
{
return field;
}
}

== Refactoring support for Current Ruby IDE ==
This the following table we summary the current ruby IDE and their refactoring support situation.
{|
| Current Ruby IDE || Refactoring Support (Y/N)
|-
| ActiveState Komodo || N
|-
| NetBeans || N
|-
| Arachno Ruby || N
|-
| FreeRIDE || N
|-
| Mondrian Ruby IDE || N
|-
| Ruby in Steel || N
|-
| RubyMine || Y
|-
| Eclipse (Aptana) || Y
|}

=== Example of Using Ruby Refactoring Tools in Eclipse ===
Here the renaming of the method "badRenameMethod" to "Hello" is illustrated for Ruby. The source code is show in section 1.3.
{|
| [[Image:r00.jpg|thumb|upright|alt= rename step 1]]
| [[Image:r01.jpg|thumb|upright|alt= rename step 2]]
| [[Image:r02.jpg|thumb|upright|alt= rename step 3]]
| [[Image:r03.jpg|thumb|upright|alt= rename step 4]]
| [[Image:r04.jpg|thumb|upright|alt= rename step 5]]
|}

Here the encapsulation of the field "field" is illustrated for Ruby. The source code is show in section 1.3.
{|
| [[Image:r05.jpg|thumb|upright|alt= encapsulation step 1]]
| [[Image:r06.jpg|thumb|upright|alt= encapsulation step 2]]
| [[Image:r07.jpg|thumb|upright|alt= encapsulation step 3]]
| [[Image:r08.jpg|thumb|upright|alt= encapsulation step 4]]
| [[Image:r09.jpg|thumb|upright|alt= encapsulation step 5]]
|}

=== Example of Using Java Refactoring Tools in Eclipse ===
Here the renaming of the method "badRenameMethod" to "Hello" is illustrated for Java. The source code is show in section 1.4.

{|
| [[Image:j00.jpg|thumb|upright|alt= rename step 1]]
| [[Image:j01.jpg|thumb|upright|alt= rename step 2]]
| [[Image:j02.jpg|thumb|upright|alt= rename step 3]]
| [[Image:j03.jpg|thumb|upright|alt= rename step 4]]
| [[Image:j04.jpg|thumb|upright|alt= rename step 5]]
| [[Image:j05.jpg|thumb|upright|alt= rename step 6]]
|}
Here the encapsulation of the field "field" is illustrated for Java. The source code is show in section 1.4.

{|
| [[Image:j06.jpg|thumb|upright|alt= encapsulation step 1]]
| [[Image:j07.jpg|thumb|upright|alt= encapsulation step 2]]
| [[Image:j08.jpg|thumb|upright|alt= encapsulation step 3]]
| [[Image:j09.jpg|thumb|upright|alt= encapsulation step 4]]
|}

== Comparison of Ruby and Java Refactoring Tools ==
Comprehensiveness comparison:

{|
|1. Refactoring Options for Java in Eclipse |||| 2. Refactoring Options in Eclipse for Ruby
|-
|Rename || || Rename
|-
|Move || || Move
|-
|Change Method Signature || || Merge Class Parts in File
|-
|Extract Local Variable || || Pull Up
|-
|Extract Constant || || Pull Down
|-
|Inline || || Merge With External Class Parts
|-
|Convert Anonymous Class to Nested || || Split Local Variable
|-
|Convert Member to Top Level || || Merge With External Class Parts
|-
|Convert Local Variable to Field || || Inline
|-
|Extract Super Class || || Extract Constant
|-
|Extract Interface || || Encapsulate Field
|-
|Extract Class || || Convert Local Variable to Field
|-
|Use Supertype where possible
|-
|Pull Up
|-
|Pull Down
|-
|Introduce Parameter Object
|-
|Introduce Indirection
|-
|Introduce Factory
|-
|Introduce Parameter
|-
|Encapsulate Field
|-
|Generalize Declared Type
|-
|Infer Generic Type Arguments
|}

The refactoring options for Ruby and Java cover all the basic refactorings. The differences in the number of options mainly come from the difference in the two languages. Ruby is a dynamically typed language, has unbounded polymorphism, and all classes are open to extension. On the other hand, Java is a statically typed language, polymorphism is mainly implemented via interfaces and inheritance, and classes cannot be extended at runtime. The given examples (in section 1.3, 1.4) illustrate the ease of use of the refactoring tools for both Ruby and Java and how well these tools are integrated into the Eclipse IDE.

== References ==

[1] Thomas Corbat, Lukas Felber, Mirko Stocker
Refactoring Support for the Eclipse Ruby Development Tools, Diploma Thesis, HSR University of Applied Sciences Rapperswil Institute for Software

[2] code refactoring wiki, http://en.wikipedia.org/wiki/Code_refactoring

[3] the first workshop on refactoring, https://netfiles.uiuc.edu/dig/RefactoringWorkshop

[4] refactoring tutorial on ruby on rail, http://www.good-tutorials.com/tutorials/ruby-on-rails/refactoring

CSC/ECE 517 Fall 2009/wiki 1a 9b SJ

2009-09-09T20:06:16Z

Gohan:

== What is Code Refactoring ==
According to the famous book "Refactoring: Improving the Design of Existing Code " by Martin Fowler: Refactoring is the process of applying behavior-preserving transformations to a program with the objective of improving the program’s design. Intuitively people refer to code refactoring as "cleaning it up".

=== Motivation of Refactoring ===
Refactoring is very useful for software engineer to maintain the quality of their code in different environment. In fact, no software can be guaranteed to be perfect when it is first developed. Usually when the source code is applied to different customer needs, we want to improve the inner-structure without modify the external behavior. The ability to refactor your code takes the pressure off the design phase of software development. Refactoring gives you the ability to change the design of the code at a later stage. This means that you don’t have to get the design absolutely right before you write any code. You can get a rough design worked out, code it up and then if (when) you spot a better design you can refactor your code towards the better design.

=== List of Common Refactorings ===
In the following we list some popular refactoring to specify how refactoring transform the code. For more detail information, the reader please refer to the section 2.1.2 of the thesis of Thomas Corbat[1]. [1] provide Ruby example for each refactoring this list.

{|
| 1. Merge Class Parts
|-
| 2. Convert Local Variable to Field
|-
| 3. Encapsulate Field
|-
| 4. Extract Method
|-
| 5. Inline Class
|-
| 6. Inline Method
|-
| 7. Move Field
|-
| 8. Move Method
|-
| 9. Rename Class
|-
| 10. Rename Field
|-
| 11. Rename Local Variable
|-
| 12. Rename Method
|-
| 13. Replace Temporary Variable with Query
|-
| 14. Split Temporary Variable
|}

=== Ruby Example of Refactoring ===
before rename:

def badRenameMethod
puts("Hello World");
end

after rename:

def hello
puts("Hello World");
end

before encapsulation:

class SomeClass
def initialize
@field = 0;
end
end

after encapsulation:

class SomeClass
def initialize
@field = 0;
end

def field
@field
end
private :field

def field= field
@field = field
end
private :field=
end

=== Java Example of Refactoring ===
before rename:

public class rename_method
{
static void badRenameMethod()
{
System.out.println("Hello, world!");
}
}

after rename:

public class rename_method
{
static void hello()
{
System.out.println("Hello, world!");
}
}

before encapsulation:

public class encap_field
{
public String field;
}

after encapsulation:

public class encap_field
{
private int field;

public void setField(int field)
{
this.field = field;
}

public int getField()
{
return field;
}
}

== Refactoring support for Current Ruby IDE ==
This the following table we summary the current ruby IDE and their refactoring support situation.
{|
| Current Ruby IDE || Refactoring Support (Y/N)
|-
| ActiveState Komodo || N
|-
| NetBeans || N
|-
| Arachno Ruby || N
|-
| FreeRIDE || N
|-
| Mondrian Ruby IDE || N
|-
| Ruby in Steel || N
|-
| RubyMine || Y
|-
| Eclipse (Aptana) || Y
|}

=== Example of Using Ruby Refactoring Tools in Eclipse ===
Here the renaming of the method "badRenameMethod" to "Hello" is illustrated for Ruby. The source code is show in section 1.3.
{|
| [[Image:r00.jpg|thumb|upright|alt= rename step 1]]
| [[Image:r01.jpg|thumb|upright|alt= rename step 2]]
| [[Image:r02.jpg|thumb|upright|alt= rename step 3]]
| [[Image:r03.jpg|thumb|upright|alt= rename step 4]]
| [[Image:r04.jpg|thumb|upright|alt= rename step 5]]
|}

Here the encapsulation of the field "field" is illustrated for Ruby. The source code is show in section 1.3.
{|
| [[Image:r05.jpg|thumb|upright|alt= encapsulation step 1]]
| [[Image:r06.jpg|thumb|upright|alt= encapsulation step 2]]
| [[Image:r07.jpg|thumb|upright|alt= encapsulation step 3]]
| [[Image:r08.jpg|thumb|upright|alt= encapsulation step 4]]
| [[Image:r09.jpg|thumb|upright|alt= encapsulation step 5]]
|}

=== Example of Using Java Refactoring Tools in Eclipse ===
Here the renaming of the method "badRenameMethod" to "Hello" is illustrated for Java. The source code is show in section 1.4.

{|
| [[Image:j00.jpg|thumb|upright|alt= rename step 1]]
| [[Image:j01.jpg|thumb|upright|alt= rename step 2]]
| [[Image:j02.jpg|thumb|upright|alt= rename step 3]]
| [[Image:j03.jpg|thumb|upright|alt= rename step 4]]
| [[Image:j04.jpg|thumb|upright|alt= rename step 5]]
| [[Image:j05.jpg|thumb|upright|alt= rename step 6]]
|}
Here the encapsulation of the field "field" is illustrated for Java. The source code is show in section 1.4.

{|
| [[Image:j06.jpg|thumb|upright|alt= encapsulation step 1]]
| [[Image:j07.jpg|thumb|upright|alt= encapsulation step 2]]
| [[Image:j08.jpg|thumb|upright|alt= encapsulation step 3]]
| [[Image:j09.jpg|thumb|upright|alt= encapsulation step 4]]
|}

== Comparison of Ruby and Java Refactoring Tools ==
Comprehensiveness comparison:

{|
|1. Refactoring Options for Java in Eclipse |||| 2. Refactoring Options in Eclipse for Ruby
|-
|Rename || || Rename
|-
|Move || || Move
|-
|Change Method Signature || || Merge Class Parts in File
|-
|Extract Local Variable || || Pull Up
|-
|Extract Constant || || Pull Down
|-
|Inline || || Merge With External Class Parts
|-
|Convert Anonymous Class to Nested || || Split Local Variable
|-
|Convert Member to Top Level || || Merge With External Class Parts
|-
|Convert Local Variable to Field || || Inline
|-
|Extract Super Class || || Extract Constant
|-
|Extract Interface || || Encapsulate Field
|-
|Extract Class || || Convert Local Variable to Field
|-
|Use Supertype where possible
|-
|Pull Up
|-
|Pull Down
|-
|Introduce Parameter Object
|-
|Introduce Indirection
|-
|Introduce Factory
|-
|Introduce Parameter
|-
|Encapsulate Field
|-
|Generalize Declared Type
|-
|Infer Generic Type Arguments
|}

The refactoring options for Ruby and Java cover all the basic refactorings. The differences in the number of options mainly come from the difference in the two languages. Ruby is a dynamically typed language, has unbounded polymorphism, and all classes are open to extension. On the other hand, Java is a statically typed language, polymorphism is mainly implemented via interfaces and inheritance, and classes cannot be extended at runtime. The given examples (in section 1.3, 1.4) illustrate the ease of use of the refactoring tools for both Ruby and Java and how well these tools are integrated into the Eclipse IDE.

== References ==

[1] Thomas Corbat, Lukas Felber, Mirko Stocker
Refactoring Support for the Eclipse Ruby Development Tools, Diploma Thesis, HSR University of Applied Sciences Rapperswil Institute for Software

[2] code refactoring wiki, http://en.wikipedia.org/wiki/Code_refactoring

[3] the first workshop on refactoring, https://netfiles.uiuc.edu/dig/RefactoringWorkshop

[4] refactoring tutorial on ruby on rail, http://www.good-tutorials.com/tutorials/ruby-on-rails/refactoring

CSC/ECE 517 Fall 2009/wiki 1a

2009-09-08T18:12:18Z

Gohan:

CSC/ECE 517 Fall 2009/wiki 1a

2009-09-08T18:11:44Z

Gohan:

== What is Code Refactoring ==
According to the famous book "Refactoring: Improving the Design of Existing Code " by Martin Fowler: Refactoring is the process of applying behavior-preserving transformations to a program with the objective of improving the program’s design. Intuitively people refer to code refactoring as "cleaning it up".

=== Motivation of Refactoring ===
Refactoring is very useful for software engineer to maintain the quality of their code in different environment. In fact, no software can be guaranteed to be perfect when it is first developed. Usually when the source code is applied to different customer needs, we want to improve the inner-structure without modify the external behavior. The ability to refactor your code takes the pressure off the design phase of software development. Refactoring gives you the ability to change the design of the code at a later stage. This means that you don’t have to get the design absolutely right before you write any code. You can get a rough design worked out, code it up and then if (when) you spot a better design you can refactor your code towards the better design.

===List of Common Refactorings===
In the following we list some popular refactoring to specify how refactoring transform the code. For more detail information, the reader please refer to the section 2.1.2 of the thesis of Thomas Corbat[1]. [1] provide Ruby example for each refactoring this list.

{|
| 1. Merge Class Parts
|-
| 2. Convert Local Variable to Field
|-
| 3. Encapsulate Field
|-
| 4. Extract Method
|-
| 5. Inline Class
|-
| 6. Inline Method
|-
| 7. Move Field
|-
| 8. Move Method
|-
| 9. Rename Class
|-
| 10. Rename Field
|-
| 11. Rename Local Variable
|-
| 12. Rename Method
|-
| 13. Replace Temporary Variable with Query
|-
| 14. Split Temporary Variable
|}

=== Ruby Example of Refactoring ===
before rename:

def badRenameMethod
puts("Hello World");
end

after rename:

def hello
puts("Hello World");
end

before encapsulation:

class SomeClass
def initialize
@field = 0;
end
end

after encapsulation:

class SomeClass
def initialize
@field = 0;
end

def field
@field
end
private :field

def field= field
@field = field
end
private :field=
end

=== Java Example of Refactoring ===
before rename:

public class rename_method
{
static void badRenameMethod()
{
System.out.println("Hello, world!");
}
}

after rename:

public class rename_method
{
static void hello()
{
System.out.println("Hello, world!");
}
}

before encapsulation:

public class encap_field
{
public String field;
}

after encapsulation:

public class encap_field
{
private int field;

public void setField(int field)
{
this.field = field;
}

public int getField()
{
return field;
}
}

== Refactoring support for Current Ruby IDE ==
This the following table we summary the current ruby IDE and their refactoring support situation.
{|
| Current Ruby IDE || Refactoring Support (Y/N)
|-
| ActiveState Komodo || N
|-
| NetBeans || N
|-
| Arachno Ruby || N
|-
| FreeRIDE || N
|-
| Mondrian Ruby IDE || N
|-
| Ruby in Steel || N
|-
| RubyMine || Y
|-
| Eclipse (Aptana) || Y
|}

=== Example of Using Ruby Refactoring Tools in Eclipse ===
Here the renaming of the method "badRenameMethod" to "Hello" is illustrated for Ruby. The source code is show in section 1.3.
{|
| [[Image:r00.jpg|thumb|upright|alt= rename step 1]]
| [[Image:r01.jpg|thumb|upright|alt= rename step 2]]
| [[Image:r02.jpg|thumb|upright|alt= rename step 3]]
| [[Image:r03.jpg|thumb|upright|alt= rename step 4]]
| [[Image:r04.jpg|thumb|upright|alt= rename step 5]]
|}

Here the encapsulation of the field "field" is illustrated for Ruby. The source code is show in section 1.3.
{|
| [[Image:r05.jpg|thumb|upright|alt= encapsulation step 1]]
| [[Image:r06.jpg|thumb|upright|alt= encapsulation step 2]]
| [[Image:r07.jpg|thumb|upright|alt= encapsulation step 3]]
| [[Image:r08.jpg|thumb|upright|alt= encapsulation step 4]]
| [[Image:r09.jpg|thumb|upright|alt= encapsulation step 5]]
|}

=== Example of Using Java Refactoring Tools in Eclipse ===
Here the renaming of the method "badRenameMethod" to "Hello" is illustrated for Java. The source code is show in section 1.4.

{|
| [[Image:j00.jpg|thumb|upright|alt= rename step 1]]
| [[Image:j01.jpg|thumb|upright|alt= rename step 2]]
| [[Image:j02.jpg|thumb|upright|alt= rename step 3]]
| [[Image:j03.jpg|thumb|upright|alt= rename step 4]]
| [[Image:j04.jpg|thumb|upright|alt= rename step 5]]
| [[Image:j05.jpg|thumb|upright|alt= rename step 6]]
|}
Here the encapsulation of the field "field" is illustrated for Java. The source code is show in section 1.4.

{|
| [[Image:j06.jpg|thumb|upright|alt= encapsulation step 1]]
| [[Image:j07.jpg|thumb|upright|alt= encapsulation step 2]]
| [[Image:j08.jpg|thumb|upright|alt= encapsulation step 3]]
| [[Image:j09.jpg|thumb|upright|alt= encapsulation step 4]]
|}

== Comparison of Ruby and Java Refactoring Tools ==
Comprehensiveness comparison:

{|
|1. Refactoring Options for Java in Eclipse |||| 2. Refactoring Options in Eclipse for Ruby
|-
|Rename || || Rename
|-
|Move || || Move
|-
|Change Method Signature || || Merge Class Parts in File
|-
|Extract Local Variable || || Pull Up
|-
|Extract Constant || || Pull Down
|-
|Inline || || Merge With External Class Parts
|-
|Convert Anonymous Class to Nested || || Split Local Variable
|-
|Convert Member to Top Level || || Merge With External Class Parts
|-
|Convert Local Variable to Field || || Inline
|-
|Extract Super Class || || Extract Constant
|-
|Extract Interface || || Encapsulate Field
|-
|Extract Class || || Convert Local Variable to Field
|-
|Use Supertype where possible
|-
|Pull Up
|-
|Pull Down
|-
|Introduce Parameter Object
|-
|Introduce Indirection
|-
|Introduce Factory
|-
|Introduce Parameter
|-
|Encapsulate Field
|-
|Generalize Declared Type
|-
|Infer Generic Type Arguments
|}

The refactoring options for Ruby and Java cover all the basic refactorings. The differences in the number of options mainly come from the difference in the two languages. Ruby is a dynamically typed language, has unbounded polymorphism, and all classes are open to extension. On the other hand, Java is a statically typed language, polymorphism is mainly implemented via interfaces and inheritance, and classes cannot be extended at runtime. The given examples (in section 1.3, 1.4) illustrate the ease of use of the refactoring tools for both Ruby and Java and how well these tools are integrated into the Eclipse IDE.

== References ==

[1] Thomas Corbat, Lukas Felber, Mirko Stocker
Refactoring Support for the Eclipse Ruby Development Tools, Diploma Thesis, HSR University of Applied Sciences Rapperswil Institute for Software

[2] code refactoring wiki, http://en.wikipedia.org/wiki/Code_refactoring

[3] the first workshop on refactoring, https://netfiles.uiuc.edu/dig/RefactoringWorkshop

[4] refactoring tutorial on ruby on rail, http://www.good-tutorials.com/tutorials/ruby-on-rails/refactoring