Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:39:52Z

Messi: /* Conclusion */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

We discussed why it is important to use DRY in the [[#Why Dry | previous]] section by discussing how it may result in clumsy code. It is a misconception that DRY is applicable to code only. It is very much applicable to data as well which we shall see in this section by analysing how it could be a harmful idea to have data duplication.
 
The following figure is a representation of how DRY is violated in a bad way by data duplication.
[[Image:dry.jpg|thumb|center|550px|alt=Taken from http://tagschema.com/blogs/tagschema/ |Taken from http://tagschema.com/blogs/tagschema/ ]]
 

Let us consider some of the many possible problems of Data Duplication
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stores multiple copies increases the amount of memory required for the system

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

DRY is one of the important principle that needs to be used while design a system. DRY principle for code is definitely a must, but as mentioned above there can be cases where DRY can be violated for data. There can be no definite guidelines for not following this rule, but in the following cases violating DRY for data should be considered

* If the performance of the system is significantly improved. For example adding layers of cache improves the performance of the computer significantly. 
* If there is need for data redundancy. For example Source control software makes sure that if one version of file is damaged there are always previous versions to fall back on. 
* If violating DRY reduces overhead. For example making copies of global data locally reduces the overhead of adding logic for mutual exclusion. 

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:38:40Z

Messi: /* Conclusion */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

We discussed why it is important to use DRY in the [[#Why Dry | previous]] section by discussing how it may result in clumsy code. It is a misconception that DRY is applicable to code only. It is very much applicable to data as well which we shall see in this section by analysing how it could be a harmful idea to have data duplication.
 
The following figure is a representation of how DRY is violated in a bad way by data duplication.
[[Image:dry.jpg|thumb|center|550px|alt=Taken from http://tagschema.com/blogs/tagschema/ |Taken from http://tagschema.com/blogs/tagschema/ ]]
 

Let us consider some of the many possible problems of Data Duplication
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stores multiple copies increases the amount of memory required for the system

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

DRY is one of the important principle that needs to be used while design a system. DRY principle for code is definitely a must, but as mentioned above there can be cases where DRY can be violated for data. There can be no definite guidelines for not following this rule, but in the following cases violating DRY for data should be considered

* If the performance of the system is significantly improved. For example adding layers of caches improves the performance of the computer significantly. 
* If there is need for data redundancy. For example Source control software makes sure that even if one version of file is damaged there are always previous versions to fall back on. 
* If violating DRY reduces overhead. For example making copies of global data locally reduces the overhead of adding logic for mutual exclusion. 

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:38:13Z

Messi: /* Conclusion */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

We discussed why it is important to use DRY in the [[#Why Dry | previous]] section by discussing how it may result in clumsy code. It is a misconception that DRY is applicable to code only. It is very much applicable to data as well which we shall see in this section by analysing how it could be a harmful idea to have data duplication.
 
The following figure is a representation of how DRY is violated in a bad way by data duplication.
[[Image:dry.jpg|thumb|center|550px|alt=Taken from http://tagschema.com/blogs/tagschema/ |Taken from http://tagschema.com/blogs/tagschema/ ]]
 

Let us consider some of the many possible problems of Data Duplication
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stores multiple copies increases the amount of memory required for the system

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

DRY is one of the important principle that needs to be used while design a system. DRY principle for code is definitely a must, but as mentioned above there can be cases where DRY can be violated for data. There can be no definite guidelines for not following this rule, but in the following cases violating DRY for data should be considered

* If the performance of the system is significantly improved. For example adding layers of caches improves the performance of the computer significantly. 
* If there is need for data redundancy. For example Source control software makes sure that even if one version of file is damaged there are always previous versions to fall back on.
* If violating DRY reduces overhead. For example making copies of global data locally reduces the overhead of adding logic for mutual exclusion.

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:34:37Z

Messi: /* Conclusion */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

We discussed why it is important to use DRY in the [[#Why Dry | previous]] section by discussing how it may result in clumsy code. It is a misconception that DRY is applicable to code only. It is very much applicable to data as well which we shall see in this section by analysing how it could be a harmful idea to have data duplication.
 
The following figure is a representation of how DRY is violated in a bad way by data duplication.
[[Image:dry.jpg|thumb|center|550px|alt=Taken from http://tagschema.com/blogs/tagschema/ |Taken from http://tagschema.com/blogs/tagschema/ ]]
 

Let us consider some of the many possible problems of Data Duplication
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

DRY is one of the important principle that need to be used while design a system. Following DRY principle for code is definitely a must, but as mentioned above there can be cases where DRY can be violated for data. There can be no definite guidelines for not following this rule, but we think in the following cases violating DRY for data should be considered

* If the performance of the system is significantly improved. For example adding layers of caches improves the performance of the computer significantly.
* If there is need for redundancy. For example Source control software makes sure that even if one version of file is damaged there are always previous versions to fall back on.
* If violating DRY reduces overhead. For example making copies of global data locally reduces the overhead of adding logic for mutual exclusion.

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:21:13Z

Messi: /* Conclusion */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY

<table border="3">
<tr>
<td>
[[Image:dry.jpg]]
</td>
</tr>
<tr>
<td>
Taken from http://tagschema.com/blogs/tagschema/
</td>
</tr>
</table>

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

DRY is one of the important principle that need to be used while design a system. Following

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:15:44Z

Messi: /* Why Data Duplication is harmful */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY

<table border="3">
<tr>
<td>
[[Image:dry.jpg]]
</td>
</tr>
<tr>
<td>
Taken from http://tagschema.com/blogs/tagschema/
</td>
</tr>
</table>

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)'''[#References | [5]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:09:34Z

Messi: /* Why Data Duplication is harmful */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY

<table border="3">
<tr>
<td>
[[Image:dry.jpeg.jpg]]
</td>
</tr>
<tr>
<td>
Taken from http://tagschema.com/blogs/tagschema/
</td>
</tr>
</table>

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't to get data or
instruction.

'''Buffer Manager in DBMS''' is a intermediate layer in the DBMS which gets the DB pages from the Disk and buffer them
for upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates creates a copy of the code to each member of the team to ensure smother development.

'''Read-copy-update (RCU)'''[3] is an operating system kernel technology for improving performance on computers with more than one
CPU. More technically it is a synchronization mechanism which can sometimes be used as an alternative to a readers-writer lock.
RCU allows you to read a shared data structure as if there is no other CPU accessing it. When you need to update the data
structure, you can update the global pointer to the data and keep the old copy until all the threads currently executing inside
the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, so the old copy can be
deleted.

Global Data in system can be a cause of concern because multiple components of the system share the same data specially in a multi-
threaded application. Instead we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When ever a new object has to be created then we clone the prototype
and use that object there by creating multiple copies of the same thing in the system

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

File:Dry.jpg

2009-11-19T01:09:16Z

Messi:

File:Dry.jpeg.jpg

2009-11-19T01:01:18Z

Messi:

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:56:43Z

Messi: /* Why Data Duplication is harmful */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY

== When Data Duplication wins over DRY... ==

Data Duplication while bad, are some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't to get data or
instruction.

'''Buffer Manager in DBMS''' is a intermediate layer in the DBMS which gets the DB pages from the Disk and buffer them
for upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates creates a copy of the code to each member of the team to ensure smother development.

'''Read-copy-update (RCU)'''[3] is an operating system kernel technology for improving performance on computers with more than one
CPU. More technically it is a synchronization mechanism which can sometimes be used as an alternative to a readers-writer lock.
RCU allows you to read a shared data structure as if there is no other CPU accessing it. When you need to update the data
structure, you can update the global pointer to the data and keep the old copy until all the threads currently executing inside
the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, so the old copy can be
deleted.

Global Data in system can be a cause of concern because multiple components of the system share the same data specially in a multi-
threaded application. Instead we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When ever a new object has to be created then we clone the prototype
and use that object there by creating multiple copies of the same thing in the system

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:56:27Z

Messi: /* When Data Duplication wins over DRY... */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

Let us look into DRY

== When Data Duplication wins over DRY... ==

Data Duplication while bad, are some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't to get data or
instruction.

'''Buffer Manager in DBMS''' is a intermediate layer in the DBMS which gets the DB pages from the Disk and buffer them
for upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates creates a copy of the code to each member of the team to ensure smother development.

'''Read-copy-update (RCU)'''[3] is an operating system kernel technology for improving performance on computers with more than one
CPU. More technically it is a synchronization mechanism which can sometimes be used as an alternative to a readers-writer lock.
RCU allows you to read a shared data structure as if there is no other CPU accessing it. When you need to update the data
structure, you can update the global pointer to the data and keep the old copy until all the threads currently executing inside
the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, so the old copy can be
deleted.

Global Data in system can be a cause of concern because multiple components of the system share the same data specially in a multi-
threaded application. Instead we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When ever a new object has to be created then we clone the prototype
and use that object there by creating multiple copies of the same thing in the system

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:56:12Z

Messi: /* DRY on Data */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

Let us look into DRY

== When Data Duplication wins over DRY... ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Data Duplication while bad, are some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't to get data or
instruction.

'''Buffer Manager in DBMS''' is a intermediate layer in the DBMS which gets the DB pages from the Disk and buffer them
for upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates creates a copy of the code to each member of the team to ensure smother development.

'''Read-copy-update (RCU)'''[3] is an operating system kernel technology for improving performance on computers with more than one
CPU. More technically it is a synchronization mechanism which can sometimes be used as an alternative to a readers-writer lock.
RCU allows you to read a shared data structure as if there is no other CPU accessing it. When you need to update the data
structure, you can update the global pointer to the data and keep the old copy until all the threads currently executing inside
the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, so the old copy can be
deleted.

Global Data in system can be a cause of concern because multiple components of the system share the same data specially in a multi-
threaded application. Instead we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When ever a new object has to be created then we clone the prototype
and use that object there by creating multiple copies of the same thing in the system

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:53:34Z

Messi: /* When Data Duplication wins over DRY... */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== DRY on Data ==

== When Data Duplication wins over DRY... ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Data Duplication while bad, are some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't to get data or
instruction.

'''Buffer Manager in DBMS''' is a intermediate layer in the DBMS which gets the DB pages from the Disk and buffer them
for upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates creates a copy of the code to each member of the team to ensure smother development.

'''Read-copy-update (RCU)'''[3] is an operating system kernel technology for improving performance on computers with more than one
CPU. More technically it is a synchronization mechanism which can sometimes be used as an alternative to a readers-writer lock.
RCU allows you to read a shared data structure as if there is no other CPU accessing it. When you need to update the data
structure, you can update the global pointer to the data and keep the old copy until all the threads currently executing inside
the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, so the old copy can be
deleted.

Global Data in system can be a cause of concern because multiple components of the system share the same data specially in a multi-
threaded application. Instead we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When ever a new object has to be created then we clone the prototype
and use that object there by creating multiple copies of the same thing in the system

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:52:32Z

Messi: /* When Data Duplication wins over DRY... */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== DRY on Data ==

== When Data Duplication wins over DRY... ==
Data Duplication can be a big problem is many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Data Duplication while bad, are some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't to get data or
instruction.

'''Buffer Manager in DBMS''' is a intermediate layer in the DBMS which gets the DB pages from the Disk and buffer them
for upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates creates a copy of the code to each member of the team to ensure smother development.

'''Read-copy-update (RCU)'''[3] is an operating system kernel technology for improving performance on computers with more than one
CPU. More technically it is a synchronization mechanism which can sometimes be used as an alternative to a readers-writer lock.
RCU allows you to read a shared data structure as if there is no other CPU accessing it. When you need to update the data
structure, you can update the global pointer to the data and keep the old copy until all the threads currently executing inside
the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, so the old copy can be
deleted.

Global Data in system can be a cause of concern because multiple components of the system share the same data specially in a multi-
threaded application. Instead we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When ever a new object has to be created then we clone the prototype
and use that object there by creating multiple copies of the same thing in the system

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:22:27Z

Messi: /* References */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:22:09Z

Messi: /* References */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:20:46Z

Messi: /* When Data Duplication wins over DRY... */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T22:28:00Z

Messi:

=Introduction=

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-10T02:46:18Z

Messi: /* C++ */

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

==Key Abstractions==

A abstraction which describes the system is referred as a '''key abstraction'''. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

= Abstraction in Different O-O languages =

== Java ==
Java implements abstraction using Abstract classes and methods. Any class which cannot be instantiated and contains one or more abstract methods in referred as an '''Abstract class''' in JAVA. Such class can only be inherited.

''' Example : Java code for the above figure.'''


/* The abstract class car is extended by both the classes Mechanic and LayMan. */
/* They implement the abstract method thingsILookFor */
/* according to what they consider important in a car */


public abstract class Car {

abstract void thingsILookFor();

}

public class Mechanic extends Car {

private int enginePower;

private int carMileage;

void thingsILookFor() {

enginePower = 1000;

carMileage = 32;
}

}

public class LayMan extends Car {

private string color;

private int seats;

void thingsILookFor() {

color = "yellow";

seats = 4;
}


== C++ ==
'''Abstract classes:''' These classes can be used as a framework to build new classes that provide new functionality. These class have one or more virtual function.
Functions of the base class whose functionality can be overridden by functions of the derived class at run time are called '''virtual functions'''.


class debugger
{

public:
virtual void dump()
{
cout << " No method implementation \n";
}
}

class X:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class X\n";
}

}
class Y:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class Y\n";
}

}


== Ruby ==
Ruby has no Abstract classes like in Java or Virtual function like in C++, but the same functionality can be implemented as follows


class Car
def thingsILike()
raise NotImplementedError.new("no implementation found \n")
end
end

class Mechanic < Car
def thingsILike()
puts " I like the horse power of the engine and the mileage \n"
end
end

class LayMan < Car
def thingsILike()
puts " I like the color \n"
end
end


=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html
* http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html
* http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/
* http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html
* http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization
* http://www.answers.com/topic/object-oriented-programming
* http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design
* http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169
* http://www.research.att.com/~bs/abstraction-and-machine.pdf

=Further Reading=
* http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html
* http://java.sun.com/docs/books/tutorial/java/concepts/
* http://computing.southern.edu/halterman/OOPJ/

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-10T02:30:52Z

Messi:

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

==Key Abstractions==

A abstraction which describes the system is referred as a '''key abstraction'''. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

= Abstraction in Different O-O languages =

== Java ==
Java implements abstraction using Abstract classes and methods. Any class which cannot be instantiated and contains one or more abstract methods in referred as an '''Abstract class''' in JAVA. Such class can only be inherited.

''' Example : Java code for the above figure.'''


/* The abstract class car is extended by both the classes Mechanic and LayMan. */
/* They implement the abstract method thingsILookFor */
/* according to what they consider important in a car */


public abstract class Car {

abstract void thingsILookFor();

}

public class Mechanic extends Car {

private int enginePower;

private int carMileage;

void thingsILookFor() {

enginePower = 1000;

carMileage = 32;
}

}

public class LayMan extends Car {

private string color;

private int seats;

void thingsILookFor() {

color = "yellow";

seats = 4;
}


== C++ ==
Abstraction mechanisms in C++ are

'''Abstract classes:''' These classes can be used as a framework to build new classes that provide new functionality. These class have one or more virtual function.
Functions of the base class whose functionality can be overridden by functions of the derived class at run time are called '''virtual functions'''.


class debugger
{

public:
virtual void dump()
{
cout << " No method implementation \n";
}
}

class X:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class X\n";
}

}
class Y:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class Y\n";
}

}


== Ruby ==
Ruby has no Abstract classes like in Java or Virtual function like in C++, but the same functionality can be implemented as follows


class Car
def thingsILike()
raise NotImplementedError.new("no implementation found \n")
end
end

class Mechanic < Car
def thingsILike()
puts " I like the horse power of the engine and the mileage \n"
end
end

class LayMan < Car
def thingsILike()
puts " I like the color \n"
end
end


=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html
* http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html
* http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/
* http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html
* http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization
* http://www.answers.com/topic/object-oriented-programming
* http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design
* http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169
* http://www.research.att.com/~bs/abstraction-and-machine.pdf

=Further Reading=
* http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html
* http://java.sun.com/docs/books/tutorial/java/concepts/
* http://computing.southern.edu/halterman/OOPJ/

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-10T02:29:07Z

Messi: /* Ruby */

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

==Key Abstractions==

A abstraction which describes the system is referred as a '''key abstraction'''. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

= Abstraction in Different O-O languages =

== Java ==
Java implements abstraction using Abstract classes and methods. Any class which cannot be instantiated and contains one or more abstract methods in referred as an '''Abstract class''' in JAVA. Such class can only be inherited.

''' Example : Java code for the above figure.'''


/* The abstract class car is extended by both the classes Mechanic and LayMan. */
/* They implement the abstract method thingsILookFor */
/* according to what they consider important in a car */

public abstract class Car {

abstract void thingsILookFor();

}

public class Mechanic extends Car {

private int enginePower;

private int carMileage;

void thingsILookFor() {

enginePower = 1000;

carMileage = 32;
}

}

public class LayMan extends Car {

private string color;

private int seats;

void thingsILookFor() {

color = "yellow";

seats = 4;
}

== Ruby ==
Ruby has no Abstract classes like in Java or Virtual function like in C++, but the same functionality can be implemented as follows


class Car
def thingsILike()
raise NotImplementedError.new("no implementation found \n")
end
end

class Mechanic < Car
def thingsILike()
puts " I like the horse power of the engine and the mileage \n"
end
end

class LayMan < Car
def thingsILike()
puts " I like the color \n"
end
end


== C++ ==
Abstraction mechanisms in C++ are

'''Abstract classes:''' These classes can be used as a framework to build new classes that provide new functionality. These class have one or more virtual function.
Functions of the base class whose functionality can be overridden by functions of the derived class at run time are called '''virtual functions'''.


class debugger
{

public:
virtual void dump()
{
cout << " No method implementation \n";
}
}

class X:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class X\n";
}

}
class Y:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class Y\n";
}

}


=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html
* http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html
* http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/
* http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html
* http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization
* http://www.answers.com/topic/object-oriented-programming
* http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design
* http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169
* http://www.research.att.com/~bs/abstraction-and-machine.pdf

=Further Reading=
* http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html
* http://java.sun.com/docs/books/tutorial/java/concepts/
* http://computing.southern.edu/halterman/OOPJ/

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-10T02:10:11Z

Messi: /* C++ */

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

==Key Abstractions==

A abstraction which describes the system is referred as a '''key abstraction'''. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

= Abstraction in Different O-O languages =

== Java ==
Java implements abstraction using Abstract classes and methods. Any class which cannot be instantiated and contains one or more abstract methods in referred as an '''Abstract class''' in JAVA. Such class can only be inherited.

''' Example : Java code for the above figure.'''


/* The abstract class car is extended by both the classes Mechanic and LayMan. */
/* They implement the abstract method thingsILookFor */
/* according to what they consider important in a car */

public abstract class Car {

abstract void thingsILookFor();

}

public class Mechanic extends Car {

private int enginePower;

private int carMileage;

void thingsILookFor() {

enginePower = 1000;

carMileage = 32;
}

}

public class LayMan extends Car {

private string color;

private int seats;

void thingsILookFor() {

color = "yellow";

seats = 4;
}

== Ruby ==

== C++ ==
Abstraction mechanisms in C++ are

'''Abstract classes:''' These classes can be used as a framework to build new classes that provide new functionality. These class have one or more virtual function.
Functions of the base class whose functionality can be overridden by functions of the derived class at run time are called '''virtual functions'''.


class debugger
{

public:
virtual void dump()
{
cout << " No method implementation \n";
}
}

class X:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class X\n";
}

}
class Y:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class Y\n";
}

}


=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html
* http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html
* http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/
* http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html
* http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization
* http://www.answers.com/topic/object-oriented-programming
* http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design
* http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169
* http://www.research.att.com/~bs/abstraction-and-machine.pdf

=Further Reading=
* http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html
* http://java.sun.com/docs/books/tutorial/java/concepts/
* http://computing.southern.edu/halterman/OOPJ/

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-10T01:53:40Z

Messi: /* C++ */

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

==Key Abstractions==

A abstraction which describes the system is referred as a '''key abstraction'''. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

= Abstraction in Different O-O languages =

== Java ==
Java implements abstraction using Abstract classes and methods. Any class which cannot be instantiated and contains one or more abstract methods in referred as an '''Abstract class''' in JAVA. Such class can only be inherited.

''' Example : Java code for the above figure.'''


/* The abstract class car is extended by both the classes Mechanic and LayMan. */
/* They implement the abstract method thingsILookFor */
/* according to what they consider important in a car */

public abstract class Car {

abstract void thingsILookFor();

}

public class Mechanic extends Car {

private int enginePower;

private int carMileage;

void thingsILookFor() {

enginePower = 1000;

carMileage = 32;
}

}

public class LayMan extends Car {

private string color;

private int seats;

void thingsILookFor() {

color = "yellow";

seats = 4;
}

== Ruby ==

== C++ ==
Abstraction mechanisms in C++ are
# Abstract Classes
# Templates

Abstract classes: These classes can be used as a framework to build new classes that provide new functionality. These class have one or more virtual function.
Functions of the base class whose functionality can be overridden by functions of the derived class at run time are called '''virtual functions'''.


class debugger
{

public:
virtual void dump()
{
cout << " No method implementation \n";
}
}

class X:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class X\n";
}

}
class Y:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class Y\n";
}

}


=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html
* http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html
* http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/
* http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html
* http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization
* http://www.answers.com/topic/object-oriented-programming
* http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design
* http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169
* http://www.research.att.com/~bs/abstraction-and-machine.pdf

=Further Reading=
* http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html
* http://java.sun.com/docs/books/tutorial/java/concepts/
* http://computing.southern.edu/halterman/OOPJ/

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-10T01:53:14Z

Messi:

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

==Key Abstractions==

A abstraction which describes the system is referred as a '''key abstraction'''. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

= Abstraction in Different O-O languages =

== Java ==
Java implements abstraction using Abstract classes and methods. Any class which cannot be instantiated and contains one or more abstract methods in referred as an '''Abstract class''' in JAVA. Such class can only be inherited.

''' Example : Java code for the above figure.'''


/* The abstract class car is extended by both the classes Mechanic and LayMan. */
/* They implement the abstract method thingsILookFor */
/* according to what they consider important in a car */

public abstract class Car {

abstract void thingsILookFor();

}

public class Mechanic extends Car {

private int enginePower;

private int carMileage;

void thingsILookFor() {

enginePower = 1000;

carMileage = 32;
}

}

public class LayMan extends Car {

private string color;

private int seats;

void thingsILookFor() {

color = "yellow";

seats = 4;
}

== Ruby ==

== C++ ==
Abstraction mechanisms in C++ are
# Abstract Classes
# Templates

Abstract classes: These classes can be used as a framework to build new classes that provide new functionality. These class have one or more virtual function.
Functions of the base class whose functionality can be overridden by functions of the derived class at run time are called '''virtual functions'''.


class debugger
{

public:
virtual void dump()
{
cout << " No method implementation \n";
}
}

class X:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class X\n";
}

}
class Y:public debugger
{

public:
virtual void dump()
{
cout << " dump method implementation for class Y\n";
}

}

=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html
* http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html
* http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/
* http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html
* http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization
* http://www.answers.com/topic/object-oriented-programming
* http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design
* http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169
* http://www.research.att.com/~bs/abstraction-and-machine.pdf

=Further Reading=
* http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html
* http://java.sun.com/docs/books/tutorial/java/concepts/
* http://computing.southern.edu/halterman/OOPJ/

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-10T01:31:41Z

Messi: /* Java */

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

==Key Abstractions==

A abstraction which describes the system is referred as a '''key abstraction'''. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

= Abstraction in Different O-O languages =

== Java ==
Java implements abstraction using Abstract classes and methods. Any class which cannot be instantiated and contains one or more abstract methods in referred as an '''Abstract class''' in JAVA. Such class can only be inherited.

''' Example : Java code for the above figure.'''


/* The abstract class car is extended by both the classes Mechanic and LayMan. */
/* They implement the abstract method thingsILookFor */
/* according to what they consider important in a car */

public abstract class Car {

abstract void thingsILookFor();

}

public class Mechanic extends Car {

private int enginePower;

private int carMileage;

void thingsILookFor() {

enginePower = 1000;

carMileage = 32;
}

}

public class LayMan extends Car {

private string color;

private int seats;

void thingsILookFor() {

color = "yellow";

seats = 4;
}

== Ruby ==

== C++ ==
=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html
* http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html
* http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/
* http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html
* http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization
* http://www.answers.com/topic/object-oriented-programming
* http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design
* http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169

=Further Reading=
* http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html
* http://java.sun.com/docs/books/tutorial/java/concepts/
* http://computing.southern.edu/halterman/OOPJ/

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-10T01:31:06Z

Messi:

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

==Key Abstractions==

A abstraction which describes the system is referred as a '''key abstraction'''. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

= Abstraction in Different O-O languages =

== Java ==
Java implements abstraction using Abstract classes and methods. Any class which cannot be instantiated and contains one or more abstract methods in referred as an '''Abstract class''' in JAVA. Such class can only be inherited.

''' Example : Java code for the above figure.'''


/* The abstract class car is extended by both the classes Mechanic and LayMan. */
/* They implement the abstract method thingsILookFor */
/* according to what they consider important in a car */

public abstract class Car {

abstract void thingsILookFor();

}

public class Mechanic extends Car {

private int enginePower;

private int carMileage;

void thingsILookFor() {

enginePower = 1000;

carMileage = 32;
}

}

public class LayMan extends Car {

private string color;

private int seats;

void thingsILookFor() {

color = "yellow";

seats = 4;
}

== Ruby ==

== C++ ==
=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html
* http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html
* http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/
* http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html
* http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization
* http://www.answers.com/topic/object-oriented-programming
* http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design
* http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169

=Further Reading=
* http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html
* http://java.sun.com/docs/books/tutorial/java/concepts/
* http://computing.southern.edu/halterman/OOPJ/

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-10T01:06:12Z

Messi: /* Types of abstractions */

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

=Mechanisms of finding key Abstractions=
A '''key abstraction''' is an abstraction without which we cannot describe the system. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html
* http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html
* http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/
* http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html
* http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization
* http://www.answers.com/topic/object-oriented-programming
* http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design
* http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169

=Further Reading=
* http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html
* http://java.sun.com/docs/books/tutorial/java/concepts/
* http://computing.southern.edu/halterman/OOPJ/

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-10T00:43:54Z

Messi: /* Types of abstractions */

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - Object represents a useful model of a problem domain or solution domain entity.
Example:

* Action abstraction - Object provides a generalized set of operations, all of which perform the same kind of function.
Example:

* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.
Example:

* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

=Mechanisms of finding key Abstractions=
A '''key abstraction''' is an abstraction without which we cannot describe the system. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html
* http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html
* http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/
* http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html
* http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization
* http://www.answers.com/topic/object-oriented-programming
* http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design
* http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169

=Further Reading=
* http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html
* http://java.sun.com/docs/books/tutorial/java/concepts/
* http://computing.southern.edu/halterman/OOPJ/

CSC/ECE 517 Fall 2009/wiki2 15 ms

2009-10-10T00:26:37Z

Messi: /* Mechanisms of finding key Abstractions */

=Introduction=
"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which repressents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."taken from Object-Oriented Analysis and Design by Grady Booch 
For all the things that we define as object oriented, the main framework is the object model. An object model can be defined as the collection of principles that form the foundation of object oriented design. The main elements of an object model are -:
*Abstraction
*Encapsulation
*Modularity
*Hierarchy

The goal of this article is to describe how abstraction relates to object oriented languages.

=Definition of Abstraction=
Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.[taken from [http://www.tutorialspoint.com/ruby/ruby_modules.htm what is abstraction?]]

An alternate definition given in the book object oriented analysis and design,states that-: 

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries,relative to the perceptive of the viewer."

The gist is that abstraction is a concept wherein all but the relevant information about an object is hidden in order to reduce complexity and increase the efficiency. This concept even applies in the field of arts wherein an object or a piece of art created by an artist is a representation of the original model with all the unwanted details removed.
In other words it is nothing but recognizing the similarities between objects and ignoring for some time their differences. It focuses on the outside view of the object and separate it's behavior from it's implementation. 
<table BORDER=3>
<tr>
<td>
[[Image:Abstraction.jpg]]
</td>
</tr>
</table>
'''Abstraction focuses on the essential characteristics of some object, relative to perspective of the viewer.''' 

=Types of abstractions=
There are different types of abstractions as suggested by Seidewitz and Stark of which some closely model problem domain entities and some which have no reason for existence. These are as following (mentioned in the order of their usefulness) -: 

* Entity abstraction - This is where an object represents a useful model of a problem domain or solution domain entity.
* Action abstraction - This is when an object provides a generalized set of operations, all of which perform the same kind of function.
* Virtual Machine abstraction - This is where an object groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.
* Conincidental abstraction - An object that packages a set of operations that have no relation to each other.

Entity abstractions is what is used widely because it directly parallels a given problem domain. 

Definitions taken from object oriented analysis and design by Grady Booch

=Mechanisms of finding key Abstractions=
A '''key abstraction''' is an abstraction without which we cannot describe the system. They give boundaries to our problem.They highlight things that are more relevant to our system and hence to the design and suppress the things that are outside the system. There are two important steps in identifying the key abstractions. These are -: 

* Discovery : Discovery is the process of recognizing the abstraction used in the design of the system.
For example, a customer doing a bank transaction speaks in terms of accounts,deposits and withdrawals;
these works are part of the vocabulary of the problem domain.

* Invention : Through invention, we can create new classes and objects that are not necessarily part of the problem domain, but are useful in design and implementation.
For example A developer of such a system uses these same abstractions, but must also introduce new ones, such as databases, screen
mangers, lists, queues and so on. These key abstractions are artifacts of the particular design, not of the problem domain.

=References=
* [http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-2nd/dp/0805353402 Object oriented Analysis and design by Grady Booch]

* http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci343038,00.html
* http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html
* http://www.mymindleaks.com/blog/programming/object-oriented-programming-abstraction/
* http://www.madsci.org/posts/archives/apr2001/987192403.Eg.r.html
* http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#Generalization
* http://www.answers.com/topic/object-oriented-programming
* http://computer-programming-tutorials.suite101.com/article.cfm/a_brief_introduction_to_objectoriented_design
* http://delivery.acm.org/10.1145/30000/25315/p54-seidewitz.pdf?key1=25315&key2=8831215521&coll=GUIDE&dl=GUIDE&CFID=55753397&CFTOKEN=61066169

=Further Reading=
* http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/OOP_ObjC/Articles/ooObjectModel.html
* http://java.sun.com/docs/books/tutorial/java/concepts/
* http://computing.southern.edu/halterman/OOPJ/

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T02:32:29Z

Messi: /* '''References''' */

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the software system
# SDLC: Software Development Life Cycle
# Stub: Dummy procedure that can be used to simulate or substitute an actual portion of a system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describes the interaction between an user and a system

== '''Functional testing''' ==
Functional testing is designed to ensure whether the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application complies with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.The behavior of the elevator when the eight inside exceeds
the maximum allowable limit ( i.e to test the buffer conditions). There can be many other scenarios.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected results specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module. They had worked on the desired lines in the previous tests but have to be tested currently after some changes have been made in the system. The changes might not be in the particular module but it can be affected due to the inter dependencies.
 

== '''Integration Testing''' ==
Integration testing is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.It is the next phase of unit testing. Generally in software development, complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems arise. So the intention of integration tests is not to test the functionality of individual modules but the interaction and inter-dependencies between the modules.
 
For instance in Object oriented model, the classes in a particular module could have been inherited from some other module.
The interface can be in a different module and the implementation can be elsewhere. In such scenarios, the faults can be
best found in the integration tests.
 
Another instance is to test the communication and compatibility between the client and server. Stand alone client and server
functionality is tested in the unit tests.

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems is easier.
* Advantages:
** Since all the modules are combined and tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not trivial. The reason being many modules are integrated and not all the bugs are determined in the unit tests.Therefore it is ambiguous for the tester whether the fault is due to the sub-system or due to the integration.
** Testing process cannot be started until all the sub-systems have finished their unit tests.
** Designing the test cases is an arduous task.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of each module. After the successful completion of the unit tests, sub-systems are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules call other modules and lower level modules are are called by Top level ones. Terminal modules do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs are created for the remaining modules which are used for the tests.As and when the sub-systems are ready after the unit tests, they are replaced by their respective stubs for the integration tests.
* Advantages:
** The test flow follows the architecture of the system so any bug at the top level design or implementation could be found in the early stages
** If the top level module calls multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantages :
** The main problem with this approach is the use of stubs. Mostly stubs are written to print out some trace statement based on the output of module.There can be frequent changes in the stubs as and when the bugs are found out and while testing multiple scenarios.This is an additional overhead.

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal modules are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system, in the sense that until all the modules are integrated, the tests do not follow the flow of the design.

== '''Other Types of Testing''' ==

=== '''System Testing''' ===
Every software system has well defined objectives and a comprehensive functionality.The intention here is to test the working of the system with respect to its original objectives. This is slightly different from functional testing. In functional testing we basically test all possible use-cases of the system while in system testing we are looking for discrepancies between the actual behavior as compared to its objectives.
There are various categories of system tests some of the main ones are listed below

* Compatibility Tests: It involves checking the compatibility when interacted or used in cohesion with other systems.
For Example: A routing protocol has a set of standards. The implementation can be vendor specific. When the two different
implementations of the protocols run on different routers, compatibility tests are conducted to ensure the communication between
them.

* '''Security Tests''': They test the security feature of the system.
For Example: Security alarms are equipped with a secret code and the people having access have the information about them. They
are tested for all possible incorrect codes to prevent an unauthorized person from entering the protected area.

* '''Stress Tests''': These type of tests stress the system to the maximum to find out the robustness.
For Example: A good stress test for a web server would be sending HTTP requests at the peak rate for short
period of time

* '''Volume Tests''': These tests subject the system to heavy loads of data.
For Example: Sending HTTP Requests at a high rate ( less than the peak rate) to a web server for a significant amount of
time

* '''Usability Test''': They are used to test if the system is user friendly
For Example: In a banking software, the employee is unaware of the implementation details and he / she should be able to perform
the transactions with considerable ease.

=== '''Acceptance Testing''' ===
The testing done by user or customer before accepting the software. The main focus of this testing is to establish confidence in the user regarding the system.
For Example: In the case of a program product such as a computer manufacturer’s operating system or compiler or a software
company’s database management system, the customer first performs an acceptance test to determine whether the product
satisfies his needs

== '''References''' ==
# [http://books.google.com/books?id=86rz6UExDEEC&dq=Art+of+software+testing&printsec=frontcover&source=bl&ots=yPUqKjndyO&sig=g3u5nwc_zyQcJI6UDzJzuah1_zs&hl=en&ei=nSe4SoHjLJXSlAe99_HODg&sa=X&oi=book_result&ct=result&resnum=3#v=onepage&q=&f=false Art of Software Testing by Glenford J. Myers]
# [http://books.google.com/books?id=Ss62LSqCa1MC&pg=PA197&lpg=PA197&dq=FOUNDATIONS+OF+SOFTWARE+TESTING&ots=YIbCfRQrR3&sig=itF1c7wwPFwdfIb2RYoOIcVz2VM&hl=en&ei=xim4St-nKY7klAfDyM3KDg&sa=X&oi=book_result&ct=result&resnum=1#v=onepage&q=&f=false FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION Dorothy Graham Erik van Veenendaal Isabel Evans Rex Black]
# [http://www.softwaretestinghelp.com/types-of-software-testing/ www.softwaretestinghelp.com/types-of-software-testing/]
# [http://www.cs.pitt.edu/~mock/cs1530/lectnotes.html
# [http://portal.acm.org/citation.cfm?id=1253532.1254712&coll=&dl=&type=series&idx=1253532&part=Proceedings&WantType=Proceedings&title=International%20Conference%20on%20Software%20Engineering Software Testing Research: Achievements, Challenges, Dreams. Antonia Bertolino. In Future of Software Engineering, 29th International Conference on Software Engineering, May 2007]
# [http://publib.boulder.ibm.com/infocenter/rfthelp/v7r0m0/index.jsp?topic=/com.ibm.rational.test.ft.doc/topics/FTJava_Tutorials.html publib.boulder.ibm.com/infocenter]
# [http://cs.allegheny.edu/~gkapfham/research/publish/software_testing_chapter.pdf Software Testing. Gregory M. Kapfhammer. The Computer Science and Engineering Handbook]

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T02:28:16Z

Messi:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the software system
# SDLC: Software Development Life Cycle
# Stub: Dummy procedure that can be used to simulate or substitute an actual portion of a system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describes the interaction between an user and a system

== '''Functional testing''' ==
Functional testing is designed to ensure whether the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application complies with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.The behavior of the elevator when the eight inside exceeds
the maximum allowable limit ( i.e to test the buffer conditions). There can be many other scenarios.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected results specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module. They had worked on the desired lines in the previous tests but have to be tested currently after some changes have been made in the system. The changes might not be in the particular module but it can be affected due to the inter dependencies.
 

== '''Integration Testing''' ==
Integration testing is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.It is the next phase of unit testing. Generally in software development, complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems arise. So the intention of integration tests is not to test the functionality of individual modules but the interaction and inter-dependencies between the modules.
 
For instance in Object oriented model, the classes in a particular module could have been inherited from some other module.
The interface can be in a different module and the implementation can be elsewhere. In such scenarios, the faults can be
best found in the integration tests.
 
Another instance is to test the communication and compatibility between the client and server. Stand alone client and server
functionality is tested in the unit tests.

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems is easier.
* Advantages:
** Since all the modules are combined and tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not trivial. The reason being many modules are integrated and not all the bugs are determined in the unit tests.Therefore it is ambiguous for the tester whether the fault is due to the sub-system or due to the integration.
** Testing process cannot be started until all the sub-systems have finished their unit tests.
** Designing the test cases is an arduous task.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of each module. After the successful completion of the unit tests, sub-systems are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules call other modules and lower level modules are are called by Top level ones. Terminal modules do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs are created for the remaining modules which are used for the tests.As and when the sub-systems are ready after the unit tests, they are replaced by their respective stubs for the integration tests.
* Advantages:
** The test flow follows the architecture of the system so any bug at the top level design or implementation could be found in the early stages
** If the top level module calls multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantages :
** The main problem with this approach is the use of stubs. Mostly stubs are written to print out some trace statement based on the output of module.There can be frequent changes in the stubs as and when the bugs are found out and while testing multiple scenarios.This is an additional overhead.

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal modules are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system, in the sense that until all the modules are integrated, the tests do not follow the flow of the design.

== '''Other Types of Testing''' ==

=== '''System Testing''' ===
Every software system has well defined objectives and a comprehensive functionality.The intention here is to test the working of the system with respect to its original objectives. This is slightly different from functional testing. In functional testing we basically test all possible use-cases of the system while in system testing we are looking for discrepancies between the actual behavior as compared to its objectives.
There are various categories of system tests some of the main ones are listed below

* Compatibility Tests: It involves checking the compatibility when interacted or used in cohesion with other systems.
For Example: A routing protocol has a set of standards. The implementation can be vendor specific. When the two different
implementations of the protocols run on different routers, compatibility tests are conducted to ensure the communication between
them.

* '''Security Tests''': They test the security feature of the system.
For Example: Security alarms are equipped with a secret code and the people having access have the information about them. They
are tested for all possible incorrect codes to prevent an unauthorized person from entering the protected area.

* '''Stress Tests''': These type of tests stress the system to the maximum to find out the robustness.
For Example: A good stress test for a web server would be sending HTTP requests at the peak rate for short
period of time

* '''Volume Tests''': These tests subject the system to heavy loads of data.
For Example: Sending HTTP Requests at a high rate ( less than the peak rate) to a web server for a significant amount of
time

* '''Usability Test''': They are used to test if the system is user friendly
For Example: In a banking software, the employee is unaware of the implementation details and he / she should be able to perform
the transactions with considerable ease.

=== '''Acceptance Testing''' ===
The testing done by user or customer before accepting the software. The main focus of this testing is to establish confidence in the user regarding the system.
For Example: In the case of a program product such as a computer manufacturer’s operating system or compiler or a software
company’s database management system, the customer first performs an acceptance test to determine whether the product
satisfies his needs

== '''References''' ==
# [http://books.google.com/books?id=86rz6UExDEEC&dq=Art+of+software+testing&printsec=frontcover&source=bl&ots=yPUqKjndyO&sig=g3u5nwc_zyQcJI6UDzJzuah1_zs&hl=en&ei=nSe4SoHjLJXSlAe99_HODg&sa=X&oi=book_result&ct=result&resnum=3#v=onepage&q=&f=false Art of Software Testing by Glenford J. Myers]
# [http://books.google.com/books?id=Ss62LSqCa1MC&pg=PA197&lpg=PA197&dq=FOUNDATIONS+OF+SOFTWARE+TESTING&ots=YIbCfRQrR3&sig=itF1c7wwPFwdfIb2RYoOIcVz2VM&hl=en&ei=xim4St-nKY7klAfDyM3KDg&sa=X&oi=book_result&ct=result&resnum=1#v=onepage&q=&f=false FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION Dorothy Graham Erik van Veenendaal Isabel Evans Rex Black]
# [http://www.softwaretestinghelp.com/types-of-software-testing/ www.softwaretestinghelp.com/types-of-software-testing/]
# [http://www.cs.pitt.edu/~mock/cs1530/lectnotes.html
# Software Testing Research: Achievements, Challenges, Dreams. Antonia Bertolino. In Future of Software Engineering, 29th International Conference on Software Engineering, May 2007
# [http://publib.boulder.ibm.com/infocenter/rfthelp/v7r0m0/index.jsp?topic=/com.ibm.rational.test.ft.doc/topics/FTJava_Tutorials.html publib.boulder.ibm.com/infocenter]

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T01:37:35Z

Messi:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the software system
# SDLC: Software Development Life Cycle
# Stub: Dummy procedure that can be used to simulate or substitute an actual portion of a system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describes the interaction between an user and a system

== '''Functional testing''' ==
Functional testing is designed to ensure whether the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application complies with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.The behavior of the elevator when the eight inside exceeds
the maximum allowable limit ( i.e to test the buffer conditions). There can be many other scenarios.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected results specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module. They had worked on the desired lines in the previous tests but have to be tested currently after some changes have been made in the system. The changes might not be in the particular module but it can be affected due to the inter dependencies.
 

== '''Integration Testing''' ==
Integration testing is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.It is the next phase of unit testing. Generally in software development, complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems arise. So the intention of integration tests is not to test the functionality of individual modules but the interaction and inter-dependencies between the modules.
 
For instance in Object oriented model, the classes in a particular module could have been inherited from some other module.
The interface can be in a different module and the implementation can be elsewhere. In such scenarios, the faults can be
best found in the integration tests.
 
Another instance is to test the communication and compatibility between the client and server. Stand alone client and server
functionality is tested in the unit tests.

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems is easier.
* Advantages:
** Since all the modules are combined and tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not trivial. The reason being many modules are integrated and not all the bugs are determined in the unit tests.Therefore it is ambiguous for the tester whether the fault is due to the sub-system or due to the integration.
** Testing process cannot be started until all the sub-systems have finished their unit tests.
** Designing the test cases is an arduous task.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of each module. After the successful completion of the unit tests, sub-systems are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules call other modules and lower level modules are are called by Top level ones. Terminal modules do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs are created for the remaining modules which are used for the tests.As and when the sub-systems are ready after the unit tests, they are replaced by their respective stubs for the integration tests.
* Advantages:
** The test flow follows the architecture of the system so any bug at the top level design or implementation could be found in the early stages
** If the top level module calls multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantages :
** The main problem with this approach is the use of stubs. Mostly stubs are written to print out some trace statement based on the output of module.There can be frequent changes in the stubs as and when the bugs are found out and while testing multiple scenarios.This is an additional overhead.

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal modules are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system, in the sense that until all the modules are integrated, the tests do not follow the flow of the design.

== '''Other Type of Testing''' ==

=== '''System Testing''' ===
System testing is testing the working of the system or program with respect to the orginal objectives of the system. This is slightly different from Functional testing. In Functional testing we basically test the use-case of the system while in system testing we are looking for discrepancies between the working of the system and the objectives.
There are various categories of system tests some of the main ones are listed below

* Compatibility Tests: They check the compatibility of the system which other system.
For Example: Testing a routing protocol in one router with the one running on a system from another vendor

* '''Security Tests''': They test the security feature of the system.
 
* '''Stress Tests''': These type of tests stress the system to the maximum to find out how robust they are.
For Example: A good stress test for a web server would be sending HTTP requests at rate for the peak rate for short
period of time

* '''Volume Tests''': These test subject the system to heavy loads of data.
For Example: Sending HTTP Requests at a high rate ( less than the peak rate) to a web server for a significant amount of
time is volume testing

* '''Usability Test''': They are used to test if the system is easy to use of the end-user
For Example: Tests that test UI of any product fall under this category

=== '''Acceptance Testing''' ===
The testing done by user or customer after before accepting the system. The main focus of the testing to establish confidence in the user regarding the system.
For Example: In the case of a program product, such as a computer manufacturer’s operating system or compiler, or a software
company’s database management system, the sensible customer first performs an acceptance test to determine whether the product
satisfies its needs

== '''References''' ==
# [http://books.google.com/books?id=86rz6UExDEEC&dq=Art+of+software+testing&printsec=frontcover&source=bl&ots=yPUqKjndyO&sig=g3u5nwc_zyQcJI6UDzJzuah1_zs&hl=en&ei=nSe4SoHjLJXSlAe99_HODg&sa=X&oi=book_result&ct=result&resnum=3#v=onepage&q=&f=false Art of Software Testing by Glenford J. Myers]
# [http://books.google.com/books?id=Ss62LSqCa1MC&pg=PA197&lpg=PA197&dq=FOUNDATIONS+OF+SOFTWARE+TESTING&ots=YIbCfRQrR3&sig=itF1c7wwPFwdfIb2RYoOIcVz2VM&hl=en&ei=xim4St-nKY7klAfDyM3KDg&sa=X&oi=book_result&ct=result&resnum=1#v=onepage&q=&f=false FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION Dorothy Graham Erik van Veenendaal Isabel Evans Rex Black]
# [http://www.softwaretestinghelp.com/types-of-software-testing/ www.softwaretestinghelp.com/types-of-software-testing/]
# [http://www.cs.pitt.edu/~mock/cs1530/lectnotes.html

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T01:35:28Z

Messi:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the software system
# SDLC: Software Development Life Cycle
# Stub: Dummy procedure that can be used to simulate or substitute an actual portion of a system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describes the interaction between an user and a system

== '''Functional testing''' ==
Functional testing is designed to ensure whether the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application complies with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.The behavior of the elevator when the eight inside exceeds
the maximum allowable limit ( i.e to test the buffer conditions). There can be many other scenarios.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected results specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module. They had worked on the desired lines in the previous tests but have to be tested currently after some changes have been made in the system. The changes might not be in the particular module but it can be affected due to the inter dependencies.
 

== '''Integration Testing''' ==
Integration testing is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.It is the next phase of unit testing. Generally in software development, complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems arise. So the intention of integration tests is not to test the functionality of individual modules but the interaction and inter-dependencies between the modules.
 
For instance in Object oriented model, the classes in a particular module could have been inherited from some other module.
The interface can be in a different module and the implementation can be elsewhere. In such scenarios, the faults can be
best found in the integration tests.
 
Another instance is to test the communication and compatibility between the client and server. Stand alone client and server
functionality is tested in the unit tests.

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems is easier.
* Advantages:
** Since all the modules are combined and tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not trivial. The reason being many modules are integrated and not all the bugs are determined in the unit tests.Therefore it is ambiguous for the tester whether the fault is due to the sub-system or due to the integration.
** Testing process cannot be started until all the sub-systems have finished their unit tests.
** Designing the test cases is an arduous task.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of each module. After the successful completion of the unit tests, sub-systems are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules call other modules and lower level modules are are called by Top level ones. Terminal modules do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs are created for the remaining modules which are used for the tests.As and when the sub-systems are ready after the unit tests, they are replaced by their respective stubs for the integration tests.
* Advantages:
** The test flow follows the architecture of the system so any bug at the top level design or implementation could be found in the early stages
** If the top level module calls multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantages :
** The main problem with this approach is the use of stubs. Mostly stubs are written to print out some trace statement based on the output of module.There can be frequent changes in the stubs as and when the bugs are found out and while testing multiple scenarios.This is an additional overhead.

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal modules are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system, in the sense that until all the modules are integrated, the tests do not follow the flow of the design.

== '''Other Type of Testing''' ==

=== '''System Testing''' ===
System testing is testing the working of the system or program with respect to the orginal objectives of the system. This is slightly different from Functional testing. In Functional testing we basically test the use-case of the system while in system testing we are looking for discrepancies between the working of the system and the objectives.
There are various categories of system tests some of the main ones are listed below

* Compatibility Tests: They check the compatibility of the system which other system.
For Example: Testing a routing protocol in one router with the one running on a system from another vendor

* '''Security Tests''': They test the security feature of the system.
 
* '''Stress Tests''': These type of tests stress the system to the maximum to find out how robust they are.
For Example: A good stress test for a web server would be sending HTTP requests at rate for the peak rate for short
period of time

* '''Volume Tests''': These test subject the system to heavy loads of data.
For Example: Sending HTTP Requests at a high rate ( less than the peak rate) to a web server for a significant amount of
time is volume testing

* '''Usability Test''': They are used to test if the system is easy to use of the end-user
For Example: Tests that test UI of any product fall under this category

=== '''Acceptance Testing''' ===
The testing done by user or customer after before accepting the system. The main focus of the testing to establish confidence in the user regarding the system.
For Example: In the case of a program product, such as a computer manufacturer’s operating system or compiler, or a software
company’s database management system, the sensible customer first performs an acceptance test to determine whether the product
satisfies its needs

== '''References''' ==
# [http://books.google.com/books?id=86rz6UExDEEC&dq=Art+of+software+testing&printsec=frontcover&source=bl&ots=yPUqKjndyO&sig=g3u5nwc_zyQcJI6UDzJzuah1_zs&hl=en&ei=nSe4SoHjLJXSlAe99_HODg&sa=X&oi=book_result&ct=result&resnum=3#v=onepage&q=&f=false Art
of Software Testing by Glenford J. Myers]
# [http://books.google.com/books?id=Ss62LSqCa1MC&pg=PA197&lpg=PA197&dq=FOUNDATIONS+OF+SOFTWARE+TESTING&ots=YIbCfRQrR3&sig=itF1c7wwPFwdfIb2RYoOIcVz2VM&hl=en&ei=xim4St-nKY7klAfDyM3KDg&sa=X&oi=book_result&ct=result&resnum=1#v=onepage&q=&f=false
FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION Dorothy Graham Erik van Veenendaal Isabel Evans Rex Black]
# [http://www.softwaretestinghelp.com/types-of-software-testing/ ww.softwaretestinghelp.com/types-of-software-testing/]
# [http://www.cs.pitt.edu/~mock/cs1530/lectnotes.html

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T01:33:25Z

Messi:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the software system
# SDLC: Software Development Life Cycle
# Stub: Dummy procedure that can be used to simulate or substitute an actual portion of a system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describes the interaction between an user and a system

== '''Functional testing''' ==
Functional testing is designed to ensure whether the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application complies with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.The behavior of the elevator when the eight inside exceeds
the maximum allowable limit ( i.e to test the buffer conditions). There can be many other scenarios.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected results specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module. They had worked on the desired lines in the previous tests but have to be tested currently after some changes have been made in the system. The changes might not be in the particular module but it can be affected due to the inter dependencies.
 

== '''Integration Testing''' ==
Integration testing is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.It is the next phase of unit testing. Generally in software development, complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems arise. So the intention of integration tests is not to test the functionality of individual modules but the interaction and inter-dependencies between the modules.
 
For instance in Object oriented model, the classes in a particular module could have been inherited from some other module.
The interface can be in a different module and the implementation can be elsewhere. In such scenarios, the faults can be
best found in the integration tests.
 
Another instance is to test the communication and compatibility between the client and server. Stand alone client and server
functionality is tested in the unit tests.

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems is easier.
* Advantages:
** Since all the modules are combined and tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not trivial. The reason being many modules are integrated and not all the bugs are determined in the unit tests.Therefore it is ambiguous for the tester whether the fault is due to the sub-system or due to the integration.
** Testing process cannot be started until all the sub-systems have finished their unit tests.
** Designing the test cases is an arduous task.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of each module. After the successful completion of the unit tests, sub-systems are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules call other modules and lower level modules are are called by Top level ones. Terminal modules do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs are created for the remaining modules which are used for the tests.As and when the sub-systems are ready after the unit tests, they are replaced by their respective stubs for the integration tests.
* Advantages:
** The test flow follows the architecture of the system so any bug at the top level design or implementation could be found in the early stages
** If the top level module calls multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantages :
** The main problem with this approach is the use of stubs. Mostly stubs are written to print out some trace statement based on the output of module.There can be frequent changes in the stubs as and when the bugs are found out and while testing multiple scenarios.This is an additional overhead.

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal modules are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system, in the sense that until all the modules are integrated, the tests do not follow the flow of the design.

== '''Other Type of Testing''' ==

=== '''System Testing''' ===
System testing is testing the working of the system or program with respect to the orginal objectives of the system. This is slightly different from Functional testing. In Functional testing we basically test the use-case of the system while in system testing we are looking for discrepancies between the working of the system and the objectives.
There are various categories of system tests some of the main ones are listed below

* Compatibility Tests: They check the compatibility of the system which other system.
For Example: Testing a routing protocol in one router with the one running on a system from another vendor

* '''Security Tests''': They test the security feature of the system.
 
* '''Stress Tests''': These type of tests stress the system to the maximum to find out how robust they are.
For Example: A good stress test for a web server would be sending HTTP requests at rate for the peak rate for short
period of time

* '''Volume Tests''': These test subject the system to heavy loads of data.
For Example: Sending HTTP Requests at a high rate ( less than the peak rate) to a web server for a significant amount of
time is volume testing

* '''Usability Test''': They are used to test if the system is easy to use of the end-user
For Example: Tests that test UI of any product fall under this category

=== '''Acceptance Testing''' ===
The testing done by user or customer after before accepting the system. The main focus of the testing to establish confidence in the user regarding the system.
For Example: In the case of a program product, such as a computer manufacturer’s operating system or compiler, or a software
company’s database management system, the sensible customer first performs an acceptance test to determine whether the product
satisfies its needs

== '''References''' ==
# [http://books.google.com/books?id=86rz6UExDEEC&dq=Art+of+software+testing&printsec=frontcover&source=bl&ots=yPUqKjndyO& sig=g3u5nwc_zyQcJI6UDzJzuah1_zs&hl=en&ei=nSe4SoHjLJXSlAe99_HODg&sa=X&oi=book_result&ct=result&resnum=3#v=onepage&q=&f=false Art
of Software Testing]
# [http://books.google.com/books?id=Ss62LSqCa1MC&pg=PA197&lpg=PA197&dq=FOUNDATIONS+OF+SOFTWARE+TESTING&ots=YIbCfRPw_2&sig=VVPi7ZMQRYu_HZSyuUmtjngr5Do&hl=en&ei=Kii4SuyyNZCOlQeU2PjaDg&sa=X&oi=book_result&ct=result&resnum=1#v=onepage&q=&f=false
FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION Dorothy Graham Erik van Veenendaal Isabel Evans Rex Black]
# [http://www.softwaretestinghelp.com/types-of-software-testing/ ww.softwaretestinghelp.com/types-of-software-testing/]
# [http://www.cs.pitt.edu/~mock/cs1530/lectnotes.html

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T01:32:11Z

Messi:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the software system
# SDLC: Software Development Life Cycle
# Stub: Dummy procedure that can be used to simulate or substitute an actual portion of a system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describes the interaction between an user and a system

== '''Functional testing''' ==
Functional testing is designed to ensure whether the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application complies with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.The behavior of the elevator when the eight inside exceeds
the maximum allowable limit ( i.e to test the buffer conditions). There can be many other scenarios.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected results specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module. They had worked on the desired lines in the previous tests but have to be tested currently after some changes have been made in the system. The changes might not be in the particular module but it can be affected due to the inter dependencies.
 

== '''Integration Testing''' ==
Integration testing is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.It is the next phase of unit testing. Generally in software development, complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems arise. So the intention of integration tests is not to test the functionality of individual modules but the interaction and inter-dependencies between the modules.
 
For instance in Object oriented model, the classes in a particular module could have been inherited from some other module.
The interface can be in a different module and the implementation can be elsewhere. In such scenarios, the faults can be
best found in the integration tests.
 
Another instance is to test the communication and compatibility between the client and server. Stand alone client and server
functionality is tested in the unit tests.

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems is easier.
* Advantages:
** Since all the modules are combined and tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not trivial. The reason being many modules are integrated and not all the bugs are determined in the unit tests.Therefore it is ambiguous for the tester whether the fault is due to the sub-system or due to the integration.
** Testing process cannot be started until all the sub-systems have finished their unit tests.
** Designing the test cases is an arduous task.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of each module. After the successful completion of the unit tests, sub-systems are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules call other modules and lower level modules are are called by Top level ones. Terminal modules do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs are created for the remaining modules which are used for the tests.As and when the sub-systems are ready after the unit tests, they are replaced by their respective stubs for the integration tests.
* Advantages:
** The test flow follows the architecture of the system so any bug at the top level design or implementation could be found in the early stages
** If the top level module calls multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantages :
** The main problem with this approach is the use of stubs. Mostly stubs are written to print out some trace statement based on the output of module.There can be frequent changes in the stubs as and when the bugs are found out and while testing multiple scenarios.This is an additional overhead.

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal modules are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system, in the sense that until all the modules are integrated, the tests do not follow the flow of the design.

== '''Other Type of Testing''' ==

=== '''System Testing''' ===
System testing is testing the working of the system or program with respect to the orginal objectives of the system. This is slightly different from Functional testing. In Functional testing we basically test the use-case of the system while in system testing we are looking for discrepancies between the working of the system and the objectives.
There are various categories of system tests some of the main ones are listed below

* Compatibility Tests: They check the compatibility of the system which other system.
For Example: Testing a routing protocol in one router with the one running on a system from another vendor

* '''Security Tests''': They test the security feature of the system.
 
* '''Stress Tests''': These type of tests stress the system to the maximum to find out how robust they are.
For Example: A good stress test for a web server would be sending HTTP requests at rate for the peak rate for short
period of time

* '''Volume Tests''': These test subject the system to heavy loads of data.
For Example: Sending HTTP Requests at a high rate ( less than the peak rate) to a web server for a significant amount of
time is volume testing

* '''Usability Test''': They are used to test if the system is easy to use of the end-user
For Example: Tests that test UI of any product fall under this category

=== '''Acceptance Testing''' ===
The testing done by user or customer after before accepting the system. The main focus of the testing to establish confidence in the user regarding the system.
For Example: In the case of a program product, such as a computer manufacturer’s operating system or compiler, or a software
company’s database management system, the sensible customer first performs an acceptance test to determine whether the product
satisfies its needs

== '''References''' ==
# [http://books.google.com/books?id=86rz6UExDEEC&dq=Art+of+software+testing&printsec=frontcover&source=bl&ots=yPUqKjndyO& sig=g3u5nwc_zyQcJI6UDzJzuah1_zs&hl=en&ei=nSe4SoHjLJXSlAe99_HODg&sa=X&oi=book_result&ct=result&resnum=3#v=onepage&q=&f=false Art
of Software Testing]
# [http://books.google.com/books?id=Ss62LSqCa1MC&pg=PA197&lpg=PA197&dq=FOUNDATIONS+OF+SOFTWARE+TESTING&ots=YIbCfRPw_2&sig=VVPi7ZMQRYu_HZSyuUmtjngr5Do&hl=en&ei=Kii4SuyyNZCOlQeU2PjaDg&sa=X&oi=book_result&ct=result&resnum=1#v=onepage&q=&f=false
FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION Dorothy Graham Erik van Veenendaal Isabel Evans Rex Black]
# [http://www.softwaretestinghelp.com/types-of-software-testing/]
# [http://www.cs.pitt.edu/~mock/cs1530/lectnotes.html

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T01:24:55Z

Messi:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the software system
# SDLC: Software Development Life Cycle
# Stub: Dummy procedure that can be used to simulate or substitute an actual portion of a system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describes the interaction between an user and a system

== '''Functional testing''' ==
Functional testing is designed to ensure whether the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application complies with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.The behavior of the elevator when the eight inside exceeds
the maximum allowable limit ( i.e to test the buffer conditions). There can be many other scenarios.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected results specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module. They had worked on the desired lines in the previous tests but have to be tested currently after some changes have been made in the system. The changes might not be in the particular module but it can be affected due to the inter dependencies.
 

== '''Integration Testing''' ==
Integration testing is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.It is the next phase of unit testing. Generally in software development, complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems arise. So the intention of integration tests is not to test the functionality of individual modules but the interaction and inter-dependencies between the modules.
 
For instance in Object oriented model, the classes in a particular module could have been inherited from some other module.
The interface can be in a different module and the implementation can be elsewhere. In such scenarios, the faults can be
best found in the integration tests.
 
Another instance is to test the communication and compatibility between the client and server. Stand alone client and server
functionality is tested in the unit tests.

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems is easier.
* Advantages:
** Since all the modules are combined and tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not trivial. The reason being many modules are integrated and not all the bugs are determined in the unit tests.Therefore it is ambiguous for the tester whether the fault is due to the sub-system or due to the integration.
** Testing process cannot be started until all the sub-systems have finished their unit tests.
** Designing the test cases is an arduous task.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of each module. After the successful completion of the unit tests, sub-systems are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules call other modules and lower level modules are are called by Top level ones. Terminal modules do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs are created for the remaining modules which are used for the tests.As and when the sub-systems are ready after the unit tests, they are replaced by their respective stubs for the integration tests.
* Advantages:
** The test flow follows the architecture of the system so any bug at the top level design or implementation could be found in the early stages
** If the top level module calls multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantages :
** The main problem with this approach is the use of stubs. Mostly stubs are written to print out some trace statement based on the output of module.There can be frequent changes in the stubs as and when the bugs are found out and while testing multiple scenarios.This is an additional overhead.

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal modules are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system, in the sense that until all the modules are integrated, the tests do not follow the flow of the design.

== '''Other Types of Testing''' ==

=== '''System Testing''' ===
System testing is testing the working of the system or program with respect to the original objectives of the system. This is slightly different from Functional testing. In Functional testing we basically test the use-case of the system while in system testing we are looking for discrepancies between the working of the system and the objectives.
There are various categories of system tests some of the main ones are listed below

* Compatibility Tests: They check the compatibility of the system which other system.
For Example: Testing a routing protocol in one router with the one running on a system from another vendor

* '''Security Tests''': They test the security feature of the system.
 
* '''Stress Tests''': These type of tests stress the system to the maximum to find out how robust they are.
For Example: A good stress test for a web server would be sending HTTP requests at rate for the peak rate for short
period of time

* '''Volume Tests''': These test subject the system to heavy loads of data.
For Example: Sending HTTP Requests at a high rate ( less than the peak rate) to a web server for a significant amount of
time is volume testing

* '''Usability Test''': They are used to test if the system is easy to use of the end-user
For Example: Tests that test UI of any product fall under this category

=== '''Acceptance Testing''' ===
The testing done by user or customer after before accepting the system. The main focus of the testing to establish confidence in the user regarding the system.
For Example: In the case of a program product, such as a computer manufacturer’s operating system or compiler, or a software
company’s database management system, the sensible customer first performs an acceptance test to determine whether the product
satisfies its needs

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T01:23:18Z

Messi:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the software system
# SDLC: Software Development Life Cycle
# Stub: Dummy procedure that can be used to simulate or substitute an actual portion of a system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describes the interaction between an user and a system

== '''Functional testing''' ==
Functional testing is designed to ensure whether the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application complies with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.The behavior of the elevator when the eight inside exceeds
the maximum allowable limit ( i.e to test the buffer conditions). There can be many other scenarios.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected results specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module. They had worked on the desired lines in the previous tests but have to be tested currently after some changes have been made in the system. The changes might not be in the particular module but it can be affected due to the inter dependencies.
 

== '''Integration Testing''' ==
Integration testing is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.It is the next phase of unit testing. Generally in software development, complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems arise. So the intention of integration tests is not to test the functionality of individual modules but the interaction and inter-dependencies between the modules.
 
For instance in Object oriented model, the classes in a particular module could have been inherited from some other module.
The interface can be in a different module and the implementation can be elsewhere. In such scenarios, the faults can be
best found in the integration tests.
 
Another instance is to test the communication and compatibility between the client and server. Stand alone client and server
functionality is tested in the unit tests.

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems is easier.
* Advantages:
** Since all the modules are combined and tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not trivial. The reason being many modules are integrated and not all the bugs are determined in the unit tests.Therefore it is ambiguous for the tester whether the fault is due to the sub-system or due to the integration.
** Testing process cannot be started until all the sub-systems have finished their unit tests.
** Designing the test cases is an arduous task.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of each module. After the successful completion of the unit tests, sub-systems are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules call other modules and lower level modules are are called by Top level ones. Terminal modules do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs are created for the remaining modules which are used for the tests.As and when the sub-systems are ready after the unit tests, they are replaced by their respective stubs for the integration tests.
* Advantages:
** The test flow follows the architecture of the system so any bug at the top level design or implementation could be found in the early stages
** If the top level module calls multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantages :
** The main problem with this approach is the use of stubs. Mostly stubs are written to print out some trace statement based on the output of module.There can be frequent changes in the stubs as and when the bugs are found out and while testing multiple scenarios.This is an additional overhead.

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal modules are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system, in the sense that until all the modules are integrated, the tests do not follow the flow of the design.

== '''Other Type of Testing''' ==

=== '''System Testing''' ===
System testing is testing the working of the system or program with respect to the orginal objectives of the system. This is slightly different from Functional testing. In Functional testing we basically test the use-case of the system while in system testing we are looking for discrepancies between the working of the system and the objectives.
There are various categories of system tests some of the main ones are listed below

* Compatibility Tests: They check the compatibility of the system which other system.
For Example: Testing a routing protocol in one router with the one running on a system from another vendor

* '''Security Tests''': They test the security feature of the system.
 
* '''Stress Tests''': These type of tests stress the system to the maximum to find out how robust they are.
For Example: A good stress test for a web server would be sending HTTP requests at rate for the peak rate for short
period of time

* '''Volume Tests''': These test subject the system to heavy loads of data.
For Example: Sending HTTP Requests at a high rate ( less than the peak rate) to a web server for a significant amount of
time is volume testing

* '''Usability Test''': They are used to test if the system is easy to use of the end-user
For Example: Tests that test UI of any product fall under this category

=== '''Acceptance Testing''' ===
The testing done by user or customer after before accepting the system. The main focus of the testing to establish confidence in the user regarding the system.
For Example: In the case of a program product, such as a computer manufacturer’s operating system or compiler, or a software
company’s database management system, the sensible customer first performs an acceptance test to determine whether the product
satisfies its needs

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T01:21:51Z

Messi:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the software system
# SDLC: Software Development Life Cycle
# Stub: Dummy procedure that can be used to simulate or substitute an actual portion of a system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describes the interaction between an user and a system

== '''Functional testing''' ==
Functional testing is designed to ensure whether the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application complies with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.The behavior of the elevator when the eight inside exceeds
the maximum allowable limit ( i.e to test the buffer conditions). There can be many other scenarios.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected results specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module. They had worked on the desired lines in the previous tests but have to be tested currently after some changes have been made in the system. The changes might not be in the particular module but it can be affected due to the inter dependencies.
 

== '''Integration Testing''' ==
Integration testing is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.It is the next phase of unit testing. Generally in software development, complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems arise. So the intention of integration tests is not to test the functionality of individual modules but the interaction and inter-dependencies between the modules.
 
For instance in Object oriented model, the classes in a particular module could have been inherited from some other module.
The interface can be in a different module and the implementation can be elsewhere. In such scenarios, the faults can be
best found in the integration tests.
 
Another instance is to test the communication and compatibility between the client and server. Stand alone client and server
functionality is tested in the unit tests.

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems is easier.
* Advantages:
** Since all the modules are combined and tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not trivial. The reason being many modules are integrated and not all the bugs are determined in the unit tests.Therefore it is ambiguous for the tester whether the fault is due to the sub-system or due to the integration.
** Testing process cannot be started until all the sub-systems have finished their unit tests.
** Designing the test cases is an arduous task.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of each module. After the successful completion of the unit tests, sub-systems are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules call other modules and lower level modules are are called by Top level ones. Terminal modules do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs are created for the remaining modules which are used for the tests.As and when the sub-systems are ready after the unit tests, they are replaced by their respective stubs for the integration tests.
* Advantages:
** The test flow follows the architecture of the system so any bug at the top level design or implementation could be found in the early stages
** If the top level module calls multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantages :
** The main problem with this approach is the use of stubs. Mostly stubs are written to print out some trace statement based on the output of module.There can be frequent changes in the stubs as and when the bugs are found out and while testing multiple scenarios.This is an additional overhead.

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal modules are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system, in the sense that until all the modules are integrated, the tests do not follow the flow of the design.

== '''Other Type of Testing''' ==

=== '''System Testing''' ===
System testing is testing the working of the system or program with respect to the orginal objectives of the system. This is slightly different from Functional testing. In Functional testing we basically test the use-case of the system while in system testing we are looking for discrepancies between the working of the system and the objectives.
There are various categories of system tests some of the main ones are listed below

* Compatibility Tests: They check the compatibility of the system which other system.
For Example: Testing a routing protocol in one router with the one running on a system from another vendor

* '''Security Tests''': They test the security feature of the system.
 
* '''Stress Tests''': These type of tests stress the system to the maximum to find out how robust they are.
For Example: A good stress test for a web server would be sending HTTP requests at rate for the peak rate for short period
of time

* '''Volume Tests''': These test subject the system to heavy loads of data.
For Example: Sending HTTP Requests at a high rate ( less than the peak rate) to a web server for a significant amount of time is volume testing

* '''Usability Test''': They are used to test if the system is easy to use of the end-user
For Example: Tests that test UI of any product fall under this category

=== '''Acceptance Testing''' ===
The testing done by user or customer after before accepting the system. The main focus of the testing to establish confidence in the user regarding the system.
For Example: In the case of a program product, such as a computer manufacturer’s operating system or compiler, or a software
company’s database management system, the sensible customer first performs an acceptance test to determine whether the product
satisfies its needs

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T01:13:44Z

Messi: /* '''Other Type of Testing''' */

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the software system
# SDLC: Software Development Life Cycle
# Stub: Dummy procedure that can be used to simulate or substitute an actual portion of a system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describes the interaction between an user and a system

== '''Functional testing''' ==
Functional testing is designed to ensure whether the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application complies with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.The behavior of the elevator when the eight inside exceeds
the maximum allowable limit ( i.e to test the buffer conditions). There can be many other scenarios.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected results specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module. They had worked on the desired lines in the previous tests but have to be tested currently after some changes have been made in the system. The changes might not be in the particular module but it can be affected due to the inter dependencies.
 

== '''Integration Testing''' ==
Integration testing is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.It is the next phase of unit testing. Generally in software development, complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems arise. So the intention of integration tests is not to test the functionality of individual modules but the interaction and inter-dependencies between the modules.
 
For instance in Object oriented model, the classes in a particular module could have been inherited from some other module.
The interface can be in a different module and the implementation can be elsewhere. In such scenarios, the faults can be
best found in the integration tests.
 
Another instance is to test the communication and compatibility between the client and server. Stand alone client and server
functionality is tested in the unit tests.

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems is easier.
* Advantages:
** Since all the modules are combined and tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not trivial. The reason being many modules are integrated and not all the bugs are determined in the unit tests.Therefore it is ambiguous for the tester whether the fault is due to the sub-system or due to the integration.
** Testing process cannot be started until all the sub-systems have finished their unit tests.
** Designing the test cases is an arduous task.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of each module. After the successful completion of the unit tests, sub-systems are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules call other modules and lower level modules are are called by Top level ones. Terminal modules do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs are created for the remaining modules which are used for the tests.As and when the sub-systems are ready after the unit tests, they are replaced by their respective stubs for the integration tests.
* Advantages:
** The test flow follows the architecture of the system so any bug at the top level design or implementation could be found in the early stages
** If the top level module calls multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantages :
** The main problem with this approach is the use of stubs. Mostly stubs are written to print out some trace statement based on the output of module.There can be frequent changes in the stubs as and when the bugs are found out and while testing multiple scenarios.This is an additional overhead.

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal modules are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system, in the sense that until all the modules are integrated, the tests do not follow the flow of the design.

=== '''Other Type of Testing''' ===

* '''System Testing'''
System testing is testing the working of the system or program with respect to the orginal objectives of the system. This is slightly different from Functional testing. In Functional testing we basically test the use-case of the system while in system testing we are looking for discrepancies between the working of the system and the objectives.
There are various categories of system tests some of the main ones are listed below

* Compatibility Tests: They check the compatibility of the system which other system.
For Example: Testing a routing protocol in one router with the one running on a system from another vendor

* '''Security Tests''': They test the security feature of the system.
 
* '''Stress Tests''': These type of tests stress the system to the maximum to find out how robust they are.
For Example: A good stress test for a web server would be sending HTTP requests at rate for the peak rate for short period
of time

* '''Volume Tests''': These test subject the system to heavy loads of data.
For Example: Sending HTTP Requests at a high rate ( less than the peak rate) to a web server for a significant amount of time is volume testing

* '''Usability Test''': They are used to test if the system is easy to use of the end-user
For Example: Tests that test UI of any product fall under this category

*

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T01:12:02Z

Messi:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the software system
# SDLC: Software Development Life Cycle
# Stub: Dummy procedure that can be used to simulate or substitute an actual portion of a system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describes the interaction between an user and a system

== '''Functional testing''' ==
Functional testing is designed to ensure whether the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application complies with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.The behavior of the elevator when the eight inside exceeds
the maximum allowable limit ( i.e to test the buffer conditions). There can be many other scenarios.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected results specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module. They had worked on the desired lines in the previous tests but have to be tested currently after some changes have been made in the system. The changes might not be in the particular module but it can be affected due to the inter dependencies.
 

== '''Integration Testing''' ==
Integration testing is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.It is the next phase of unit testing. Generally in software development, complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems arise. So the intention of integration tests is not to test the functionality of individual modules but the interaction and inter-dependencies between the modules.
 
For instance in Object oriented model, the classes in a particular module could have been inherited from some other module.
The interface can be in a different module and the implementation can be elsewhere. In such scenarios, the faults can be
best found in the integration tests.
 
Another instance is to test the communication and compatibility between the client and server. Stand alone client and server
functionality is tested in the unit tests.

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems is easier.
* Advantages:
** Since all the modules are combined and tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not trivial. The reason being many modules are integrated and not all the bugs are determined in the unit tests.Therefore it is ambiguous for the tester whether the fault is due to the sub-system or due to the integration.
** Testing process cannot be started until all the sub-systems have finished their unit tests.
** Designing the test cases is an arduous task.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of each module. After the successful completion of the unit tests, sub-systems are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules call other modules and lower level modules are are called by Top level ones. Terminal modules do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs are created for the remaining modules which are used for the tests.As and when the sub-systems are ready after the unit tests, they are replaced by their respective stubs for the integration tests.
* Advantages:
** The test flow follows the architecture of the system so any bug at the top level design or implementation could be found in the early stages
** If the top level module calls multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantages :
** The main problem with this approach is the use of stubs. Mostly stubs are written to print out some trace statement based on the output of module.There can be frequent changes in the stubs as and when the bugs are found out and while testing multiple scenarios.This is an additional overhead.

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal modules are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system, in the sense that until all the modules are integrated, the tests do not follow the flow of the design.

=== '''Other Type of Testing''' ===

* '''System Testing'''
System testing is testing the working of the system or program with respect to the orginal objectives of the system. This is slightly different from Functional testing. In Functional testing we basically test the use-case of the system while in system testing we are looking for discrepancies between the working of the system and the objectives.
There are various categories of system tests some of the main ones are listed below

* Compatiblity Tests: They check the compatibilty of the system which other system.
For Example: Testing a routing protocol in one router with the one running on a system from another vendor

* '''Security Tests''': They test the security feature of the system.
 
* '''Stress Tests''': These type of tests stress the system to the maximum to find out how robust they are.
For Example: A good stress test for testing a webserver would be sending HTTP requests at rate for the peak rate for short period
of time

* '''Volume Tests''': These test subject the system to heavy loads of data.
For Example: Sending HTTP Request at a high rate ( less than the peak rate) for a significant amount of time is volume testing

* '''Usablilty Test''': They are used to test if the system is easy to use of the end-user
For Example: Tests that test UI of any product fall under this category

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T01:11:08Z

Messi:

==''' Functional and Integration testing and beyond''' ==
Recognition of software test engineering as a specialty area has increased during the last twenty years. Testing is one of the key focus areas in software engineering. It is an essential activity that observes the functionality of a software system validates its intended behavior and identifies the potential malfunctions. Testing is also the primary way to improve software reliability.

The test cases should be carefully designed to cover many aspects in the SDLC such as possible aberrations from user’s requirements, system behavior upon malicious inputs, and robustness to extensive load conditions and so on. As more and more software is used in critical applications, the time and cost involved in testing is also increasing owing to the higher quality required. Although test automation saves a lot of time and can be used for regression load tests, manual testing is still widely used in the industry.

== '''Terms''' ==
# Driver: Supporting code or data used for testing the software system
# SDLC: Software Development Life Cycle
# Stub: Dummy procedure that can be used to simulate or substitute an actual portion of a system
# Sub-system: Component or Module of a software system
# System Under Test: The software system which has to be tested
# Test: Sequence of steps to validate the system design and implementation
# Usecase :Scenario that describes the interaction between an user and a system

== '''Functional testing''' ==
Functional testing is designed to ensure whether the system requirements and specifications are achieved. It can start with testing of the requirements and whether the application complies with the organizational policies and procedures.
During the design phase, after knowing the functionality of the module/modules and the system, some errors can be predicted in advance. A functional test should incorporate such type of scenarios too. In this case the erroneous transactions/ applications are deliberately introduced and the system should be able to correctly find them. In general, all the use cases in the user’s requirements become the functional test cases.
 
For example, suppose we are to develop the software for an elevator. For designing the test cases for this software,
all the scenarios and operations that can take place in the elevator need to be analyzed. To begin from the basic operations, the
elevator should be bidirectional and it should stop at each floor (unless we have two elevators in the requirement for even and
odd floors separately).The elevator should stop at the desired floor.The behavior of the elevator when the eight inside exceeds
the maximum allowable limit ( i.e to test the buffer conditions). There can be many other scenarios.

Generally Functional testing is '''Black Box''' testing. In this method the SUT (System under Test) is considered as a Black box. In this phase of testing the internals of the SUT like the design or algorithm are not considered by the tester. Inputs are provided to the black box and the outputs are validated to the expected results specified in the design document.

2 approaches can be taken for writing the functional tests
* '''Requirement based approach''': In this approach the specification for the system or software design is used as the base to write functional test.
* '''Business process based approach''': Business process refer to the day-to-day use of the system. This knowledge is used to do functional testing of the system.

Regression testing is another form of functional testing where you test the earlier features and functionality of the module. They had worked on the desired lines in the previous tests but have to be tested currently after some changes have been made in the system. The changes might not be in the particular module but it can be affected due to the inter dependencies.
 

== '''Integration Testing''' ==
Integration testing is a systematic approach to build the complete software structure specified in the design from unit-tested
modules.It is the next phase of unit testing. Generally in software development, complete software is divided into various sub-systems mostly developed by different teams. More often than not each sub-system works very well individually but when they are integrated then lot of problems arise. So the intention of integration tests is not to test the functionality of individual modules but the interaction and inter-dependencies between the modules.
 
For instance in Object oriented model, the classes in a particular module could have been inherited from some other module.
The interface can be in a different module and the implementation can be elsewhere. In such scenarios, the faults can be
best found in the integration tests.
 
Another instance is to test the communication and compatibility between the client and server. Stand alone client and server
functionality is tested in the unit tests.

There are many approaches that can be followed for Integration Testing

=== '''Big Bang Testing Approach''' ===
As the name suggests all the components are integrated at once. After all the integration is completed a set of tests are run which not only validate a single component of sub-system but also test and validate the interaction between different components. This approach is more useful in smaller systems because integration of smaller systems is easier.
* Advantages:
** Since all the modules are combined and tested at the same time, this approach of integration is less time consuming
* Disadvantages:
** Debugging and solving a fault is not trivial. The reason being many modules are integrated and not all the bugs are determined in the unit tests.Therefore it is ambiguous for the tester whether the fault is due to the sub-system or due to the integration.
** Testing process cannot be started until all the sub-systems have finished their unit tests.
** Designing the test cases is an arduous task.
<table>
<tr>
<td>
[[Image:Bigbang.jpg]]
</td>
</tr>
</table>
 
 
=== '''Incremental Testing Approach''' ===
Testing is done after integration of each module. After the successful completion of the unit tests, sub-systems are integrated and tested. Stubs are used for modules in the system which are not integrated till now.
* Advantages:
** Problems detection is early compared to the Big Bang approach
** No need to wait till the unit testing of all the modules have finished
** Debugging is much simpler
* Disadvantages:
** This approach is a time taking process because the integration tests have to run multiple times
** Stubs have to be developed to substitute the missing modules
<table>
<tr>
<td>
[[Image:Incremental testing.jpg]]
</td>
</tr>
</table>
 
 
Various Approach can be taken for Incremental Testing
* '''Top-Down Approach''': In this approach the system is tested according to the work flow or code flow. The Top level module is tested first then each lower level module is integrated and tested.Top level modules call other modules and lower level modules are are called by Top level ones. Terminal modules do not call any other module.
<table>
<tr>
<td>
[[Image:Topdown testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure Module A is the top most module in the system then B,C,D are lower level modules. Generally module A is the user interface and stubs are created for the remaining modules which are used for the tests.As and when the sub-systems are ready after the unit tests, they are replaced by their respective stubs for the integration tests.
* Advantages:
** The test flow follows the architecture of the system so any bug at the top level design or implementation could be found in the early stages
** If the top level module calls multiple lower modules then the testing can be done in various combinations
For example in the figure A calls B and C. The testing can be done as follows
A-B-C-D
A-C-B-D
* Disadvantages :
** The main problem with this approach is the use of stubs. Mostly stubs are written to print out some trace statement based on the output of module.There can be frequent changes in the stubs as and when the bugs are found out and while testing multiple scenarios.This is an additional overhead.

* '''Bottom-Up Approach''': The bottom-up approach is the opposite of the top-down approach. In this approach the terminal modules are tested first, then the higher modules and finally the top-most one. Drivers are used in this approach.
<table>
<tr>
<td>
[[Image:Bottomup testing.jpg]]
</td>
</tr>
</table>
 
 
In the above figure E,D are the terminal modules which are tested first. Then the higher level modules B,C are tested and finally the topmost module is tested
*Advantages:
** No need to write stubs
** If the terminal modules does the main work in the system then they will be tested first
*Disadvantages:
** Need to write drivers
** The testing is not according to the architecture of the system, in the sense that until all the modules are integrated, the tests do not follow the flow of the design.

=== '''Other Type of Testing''' ===

* '''System Testing'''
System testing is testing the working of the system or program with respect to the orginal objectives of the system. This is slightly different from Functional testing. In Functional testing we basically test the use-case of the system while in system testing we are looking for discrepancies between the working of the system and the objectives.
There are various categories of system tests some of the main ones are listed below

* Compatiblity Tests: They check the compatibilty of the system which other system.
For Example: Testing a routing protocol in one router with the one running on a system from another vendor

* '''Security Tests''': They test the security feature of the system.
 
* '''Stress Tests''': These type of tests stress the system to the maximum to find out how robust they are.
For Example: A good stress test for testing a webserver would be sending HTTP requests at rate for the peak rate for short period
of time

* '''Volume Tests''': These test subject the system to heavy loads of data.
For Example: Sending HTTP Request at a high rate ( less than the peak rate) for a significant amount of time is volume testing

* '''Usablilty Test''': They are used to test if the system is easy to use of the end-user
For Example: Tests that test UI of any product fall under this category

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T00:36:34Z

Messi:

CSC/ECE 517 Fall 2009/wiki1b 4 xy

2009-09-22T00:28:56Z

Messi: