Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T02:10:23Z

Rdflterr:

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon [http://en.wikipedia.org/wiki/Abstraction abstractions]. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to [http://www.webopedia.com/TERM/T/tight_coupling.html tight coupling] of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
''[http://www.oodesign.com/dependency-inversion-principle.html Source]''
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionality present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the [http://en.wikipedia.org/wiki/Abstract_type abstract classes]. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: [http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm Template Design Pattern]]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle cannot be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

==Appendix==
*'''Abstraction''' - Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically to retain only information which is relevant for a particular purpose.
*'''Tight coupling''' - tight coupling (or tightly coupled) is a type of coupling that describes a system in which hardware and software are not only linked together, but are also dependant upon each other.
*'''Factory factory''' - The factory method pattern is an object-oriented design pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created.
*'''Abstract factory''' - Abstract Factory Pattern provides a way to encapsulate a group of individual factories that have a common theme. In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interfaces to create the concrete objects that are part of the theme.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T02:06:11Z

Rdflterr: /* Conclusion */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon [http://en.wikipedia.org/wiki/Abstraction abstractions]. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to [http://www.webopedia.com/TERM/T/tight_coupling.html tight coupling] of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
''[http://www.oodesign.com/dependency-inversion-principle.html Source]''
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionality present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the [http://en.wikipedia.org/wiki/Abstract_type abstract classes]. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: [http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm Template Design Pattern]]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle cannot be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T02:03:42Z

Rdflterr: /* A design pattern based on dependency inversion policy (Template design pattern) */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon [http://en.wikipedia.org/wiki/Abstraction abstractions]. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to [http://www.webopedia.com/TERM/T/tight_coupling.html tight coupling] of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
''[http://www.oodesign.com/dependency-inversion-principle.html Source]''
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionality present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the [http://en.wikipedia.org/wiki/Abstract_type abstract classes]. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: [http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm Template Design Pattern]]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T02:02:14Z

Rdflterr: /* Example of Dependency inversion principle */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon [http://en.wikipedia.org/wiki/Abstraction abstractions]. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to [http://www.webopedia.com/TERM/T/tight_coupling.html tight coupling] of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
''[http://www.oodesign.com/dependency-inversion-principle.html Source]''
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionality present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: [http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm Template Design Pattern]]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T02:01:22Z

Rdflterr: /* Overview */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon [http://en.wikipedia.org/wiki/Abstraction abstractions]. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to [http://www.webopedia.com/TERM/T/tight_coupling.html tight coupling] of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
''[http://www.oodesign.com/dependency-inversion-principle.html Source]''
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: [http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm Template Design Pattern]]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:59:22Z

Rdflterr: /* Introduction */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon [http://en.wikipedia.org/wiki/Abstraction abstractions]. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
''[http://www.oodesign.com/dependency-inversion-principle.html Source]''
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: [http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm Template Design Pattern]]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:59:05Z

Rdflterr: /* Introduction */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon [abstractions http://en.wikipedia.org/wiki/Abstraction]. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
''[http://www.oodesign.com/dependency-inversion-principle.html Source]''
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: [http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm Template Design Pattern]]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:58:02Z

Rdflterr: /* A design pattern based on dependency inversion policy (Template design pattern) */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
''[http://www.oodesign.com/dependency-inversion-principle.html Source]''
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: [http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm Template Design Pattern]]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:57:47Z

Rdflterr: /* A design pattern based on dependency inversion policy (Template design pattern) */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
''[http://www.oodesign.com/dependency-inversion-principle.html Source]''
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:55:31Z

Rdflterr: /* Example of Dependency inversion principle */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
''[http://www.oodesign.com/dependency-inversion-principle.html Source]''
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:55:04Z

Rdflterr: /* Example of Dependency inversion principle */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
[Source http://www.oodesign.com/dependency-inversion-principle.html]
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:54:51Z

Rdflterr: /* Example of Dependency inversion principle */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
''[Source http://www.oodesign.com/dependency-inversion-principle.html]''
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:54:06Z

Rdflterr: /* Example of Dependency inversion principle */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
''Source:http://www.oodesign.com/dependency-inversion-principle.html''
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:50:58Z

Rdflterr: /* Overview */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Higher-level components depend upon lower-level components]]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: [http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Relationship diagram]]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T18:47:16Z

Rdflterr: /* References */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T18:43:13Z

Rdflterr: /* References */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Amazing article lots of stuff 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx----pics in here as well 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T18:41:59Z

Rdflterr:

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Amazing article lots of stuff 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx----pics in here as well 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T18:04:58Z

Rdflterr:

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Amazing article lots of stuff 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx----pics in here as well 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T17:52:42Z

Rdflterr:

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Amazing article lots of stuff 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx----pics in here as well 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T17:49:00Z

Rdflterr: /* Example of Dependency inversion principle */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}

class Worker implements IWorker{
public void work() {
// ....working
}
}

class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}

class Manager {
IWorker m_worker;

public void setWorker(IWorker w) {
m_worker=w;
}

public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Amazing article lots of stuff 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx----pics in here as well 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T17:48:35Z

Rdflterr: /* Example of Dependency inversion principle */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}

public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}

class Worker implements IWorker{
public void work() {
// ....working
}
}

class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}

class Manager {
IWorker m_worker;

public void setWorker(IWorker w) {
m_worker=w;
}

public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Amazing article lots of stuff 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx----pics in here as well 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T17:48:05Z

Rdflterr:

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}

class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}

public void manage() {
m_worker.work();
}
}

class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
1.Manager class should not be changed.
2.Minimized risk to affect old funtionallity present in Manager class.
3.No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}

class Worker implements IWorker{
public void work() {
// ....working
}
}

class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}

class Manager {
IWorker m_worker;

public void setWorker(IWorker w) {
m_worker=w;
}

public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Amazing article lots of stuff 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx----pics in here as well 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T17:44:05Z

Rdflterr: /* A design pattern based on dependency inversion policy (Template design pattern) */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Amazing article lots of stuff 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx----pics in here as well 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm

File:Wiki3 5 rm3.png

2009-11-18T17:40:28Z

Rdflterr:

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T17:40:13Z

Rdflterr:

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Amazing article lots of stuff 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx----pics in here as well 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T17:30:26Z

Rdflterr:

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Amazing article lots of stuff 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx----pics in here as well 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T17:29:50Z

Rdflterr:

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html Amazing article lots of stuff
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx----pics in here as well
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx
[6] http://www.oodesign.com/dependency-inversion-principle.html
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm

File:Wiki3 5 rm2.png

2009-11-18T17:26:54Z

Rdflterr:

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T17:26:38Z

Rdflterr:

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

File:Wiki3 5 rm1.png

2009-11-18T17:21:34Z

Rdflterr:

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T17:21:20Z

Rdflterr:

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T17:16:13Z

Rdflterr:

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-18T17:07:19Z

Rdflterr:

Dependency Inversion policy

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-15T03:32:26Z

Rdflterr: /* 7. jRapture: */

=GUI Testing Frameworks=

==Introduction==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools](Example provided in the appendix), and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Rip the GUI structure of the AUT : To begin testing an application, the tester first needs to determine the GUI structure of the AUT. Running the Ripper applications on the AUT automatically does this. Types of rippers are available for analyzing the AUT. For analyzing an AUT developed using
**Java use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/JavaGUIRipper.htm JavaGUIRipper]
**Native Win32 use [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/GUIRipper.htm Windows GUI Ripper]

*Generate the Event Flow Graph : The Event Flow Graph is generated from the GUI structure, ripped in the above step. The EFGGenerator generates the event-flow graph for an AUT’s GUI. To see how to analyzes a window-based application and understand its GUI integration tree. This is explained in detail [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/EFGGenerator.htm here]

*Generate Test cases : To generate testcases from the event flow graphs use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/TCGenerator.htm TCGenerator]

*Replay the Testcases :

[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.

[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example [http://wiki.github.com/aslakhellesoy/cucumber source]:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

===7. jRapture:===
jRapture is a tool for capturing and replying Java program execution in the field.This works with the Java binaries and the Java virtual machine. It employs a lightweight , transparent capture process that permits unobtrusive of a Java programs executions. jRapture captures the interactions between a Java program and the system, which includes GUI.It has a profiling interface that permits a Java program to be instrumented for profiling after its executions have been captured.Using an XML-based profiling specification language a tester can specify various forms of profiling to be carried out during replay.

[[Image:jRapture.jpg|450px|thumb|center|Figure 1:[http://portal.acm.org/citation.cfm?id=348993 Future API Modifications]]]

==Appendix==
*'''ScreenScrapper''' - Software that automatically extracts data from interactive screens without user intervention.
*'''Regression testing''' - Regression testing is any type of software testing that seeks to uncover software regressions. Such regressions occur whenever previously working software functionality stops working as intended
*'''Test harness''' - In software testing, a test harness or automated test framework is a collection of software and test data configured to test a program unit by running it under varying conditions and monitoring its behavior and outputs.
*'''Model-based testing''' - Model-based testing is software testing in which test cases are derived in whole or in part from a model that describes some (usually functional) aspects of the system under test (SUT).
*'''WinRunner''' - WinRunner is an automated functional GUI testing tool that allows a user to record and play back UI interactions as test scripts.
*'''Abbot framework''' - The Abbot framework is a Java library that provides methods to reproduce user actions and examine the state of GUI components.
*'''Rational Robot''' - Rational Robot is a test automation tool for functional testing of client/server applications.
*'''Reverse engineering''' - Reverse engineering (RE) is the process of discovering the technological principles of a device, object or system through analysis of its structure, function and operation.
*'''Ontology''' - a rigorous and exhaustive organization of some knowledge domain that is usually hierarchical and contains all the relevant entities and their relations.
*'''Unified Modeling Language''' - Unified Modeling Language is the industry-standard language for the specification, visualization, construction, and documentation of the components of software systems. UML helps to simplify the process of software design, making a model for construction with a number of different views.
*'''Use case''' - A use case in software engineering and systems engineering is a description of a system’s behavior as it responds to a request that originates from outside of that system.
*'''Activity diagram''' - Activity diagrams are diagram technique showing workflows of stepwise activities and actions, with support for choice, iteration and concurrency.
*'''Flow graph''' - A control flow graph (CFG) in computer science is a representation, using graph notation, of all paths that might be traversed through a program during its execution.
*'''GUITAR''' - GUITAR is a suite of models, components, and tools for automated testing of software applications that have a Graphical User Interface (GUI) front-end.
*'''Application under test''' - refers to a system that is being tested for correct operation. The term is used mostly in software testing.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-15T03:28:57Z

Rdflterr:

=GUI Testing Frameworks=

==Introduction==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools](Example provided in the appendix), and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Rip the GUI structure of the AUT : To begin testing an application, the tester first needs to determine the GUI structure of the AUT. Running the Ripper applications on the AUT automatically does this. Types of rippers are available for analyzing the AUT. For analyzing an AUT developed using
**Java use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/JavaGUIRipper.htm JavaGUIRipper]
**Native Win32 use [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/GUIRipper.htm Windows GUI Ripper]

*Generate the Event Flow Graph : The Event Flow Graph is generated from the GUI structure, ripped in the above step. The EFGGenerator generates the event-flow graph for an AUT’s GUI. To see how to analyzes a window-based application and understand its GUI integration tree. This is explained in detail [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/EFGGenerator.htm here]

*Generate Test cases : To generate testcases from the event flow graphs use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/TCGenerator.htm TCGenerator]

*Replay the Testcases :

[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.

[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example [http://wiki.github.com/aslakhellesoy/cucumber source]:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

===7. jRapture:===
jRapture is a tool for capturing and replying Java program execution in the field.This works with the Java binaries and the Java virtual machine. It employs a lightweight , transparent capture process that permits unobtrusive of a Java programs executions. jRapture captures the interactions between a Java program and the system, which includes GUI.It has a profiling interface that permits a Java program to be instrumented for profiling after its executions have been captured.Using an XML-based profiling specification language a tester can specify various forms of profiling to be carried out during replay.

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

==Appendix==
*'''ScreenScrapper''' - Software that automatically extracts data from interactive screens without user intervention.
*'''Regression testing''' - Regression testing is any type of software testing that seeks to uncover software regressions. Such regressions occur whenever previously working software functionality stops working as intended
*'''Test harness''' - In software testing, a test harness or automated test framework is a collection of software and test data configured to test a program unit by running it under varying conditions and monitoring its behavior and outputs.
*'''Model-based testing''' - Model-based testing is software testing in which test cases are derived in whole or in part from a model that describes some (usually functional) aspects of the system under test (SUT).
*'''WinRunner''' - WinRunner is an automated functional GUI testing tool that allows a user to record and play back UI interactions as test scripts.
*'''Abbot framework''' - The Abbot framework is a Java library that provides methods to reproduce user actions and examine the state of GUI components.
*'''Rational Robot''' - Rational Robot is a test automation tool for functional testing of client/server applications.
*'''Reverse engineering''' - Reverse engineering (RE) is the process of discovering the technological principles of a device, object or system through analysis of its structure, function and operation.
*'''Ontology''' - a rigorous and exhaustive organization of some knowledge domain that is usually hierarchical and contains all the relevant entities and their relations.
*'''Unified Modeling Language''' - Unified Modeling Language is the industry-standard language for the specification, visualization, construction, and documentation of the components of software systems. UML helps to simplify the process of software design, making a model for construction with a number of different views.
*'''Use case''' - A use case in software engineering and systems engineering is a description of a system’s behavior as it responds to a request that originates from outside of that system.
*'''Activity diagram''' - Activity diagrams are diagram technique showing workflows of stepwise activities and actions, with support for choice, iteration and concurrency.
*'''Flow graph''' - A control flow graph (CFG) in computer science is a representation, using graph notation, of all paths that might be traversed through a program during its execution.
*'''GUITAR''' - GUITAR is a suite of models, components, and tools for automated testing of software applications that have a Graphical User Interface (GUI) front-end.
*'''Application under test''' - refers to a system that is being tested for correct operation. The term is used mostly in software testing.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-15T03:09:32Z

Rdflterr: /* Some problems of GUI testing */

=GUI Testing Frameworks=

==Introduction==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools](Example provided in the appendix), and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Rip the GUI structure of the AUT : To begin testing an application, the tester first needs to determine the GUI structure of the AUT. Running the Ripper applications on the AUT automatically does this. Types of rippers are available for analyzing the AUT. For analyzing an AUT developed using
**Java use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/JavaGUIRipper.htm JavaGUIRipper]
**Native Win32 use [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/GUIRipper.htm Windows GUI Ripper]

*Generate the Event Flow Graph : The Event Flow Graph is generated from the GUI structure, ripped in the above step. The EFGGenerator generates the event-flow graph for an AUT’s GUI. To see how to analyzes a window-based application and understand its GUI integration tree. This is explained in detail [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/EFGGenerator.htm here]

*Generate Test cases : To generate testcases from the event flow graphs use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/TCGenerator.htm TCGenerator]

*Replay the Testcases :

[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.

[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example [http://wiki.github.com/aslakhellesoy/cucumber source]:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-15T02:29:48Z

Rdflterr: /* Tools for GUI testing */

=GUI Testing Frameworks=

==Introduction==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Rip the GUI structure of the AUT : To begin testing an application, the tester first needs to determine the GUI structure of the AUT. Running the Ripper applications on the AUT automatically does this. Types of rippers are available for analyzing the AUT. For analyzing an AUT developed using
**Java use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/JavaGUIRipper.htm JavaGUIRipper]
**Native Win32 use [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/GUIRipper.htm Windows GUI Ripper]

*Generate the Event Flow Graph : The Event Flow Graph is generated from the GUI structure, ripped in the above step. The EFGGenerator generates the event-flow graph for an AUT’s GUI. To see how to analyzes a window-based application and understand its GUI integration tree. This is explained in detail [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/EFGGenerator.htm here]

*Generate Test cases : To generate testcases from the event flow graphs use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/TCGenerator.htm TCGenerator]

*Replay the Testcases :

[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.

[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example [http://wiki.github.com/aslakhellesoy/cucumber source]:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-15T02:28:20Z

Rdflterr: /* Tools for GUI testing */

=GUI Testing Frameworks=

==Introduction==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Rip the GUI structure of the AUT : To begin testing an application, the tester first needs to determine the GUI structure of the AUT. Running the Ripper applications on the AUT automatically does this. Types of rippers are available for analyzing the AUT. For analyzing an AUT developed using
Java use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/JavaGUIRipper.htm JavaGUIRipper]
Native Win32 use [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/GUIRipper.htm Windows GUI Ripper]

*Generate the Event Flow Graph : The Event Flow Graph is generated from the GUI structure, ripped in the above step. The EFGGenerator generates the event-flow graph for an AUT’s GUI. To see how to analyzes a window-based application and understand its GUI integration tree. This is explained in detail [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/EFGGenerator.htm here]

*Generate Test cases : To generate testcases from the event flow graphs use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/TCGenerator.htm TCGenerator]

*Replay the Testcases :

[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.

[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example [http://wiki.github.com/aslakhellesoy/cucumber source]:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-15T02:25:41Z

Rdflterr: /* Tools for GUI testing */

=GUI Testing Frameworks=

==Introduction==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Rip the GUI structure of the AUT
To begin testing an application, the tester first needs to determine the GUI structure of the AUT. Running the Ripper applications on the AUT automatically does this. Types of rippers are available for analyzing the AUT. For analyzing an AUT developed using
**Java use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/JavaGUIRipper.htm JavaGUIRipper]
**Native Win32 use [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/GUIRipper.htm Windows GUI Ripper]

*Generate the Event Flow Graph
The Event Flow Graph is generated from the GUI structure, ripped in the above step. The EFGGenerator generates the event-flow graph for an AUT’s GUI. To see how to analyzes a window-based application and understand its GUI integration tree. This is explained in detail [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/EFGGenerator.htm here]

*Generate Test cases
To generate testcases from the event flow graphs use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/TCGenerator.htm TCGenerator]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example [http://wiki.github.com/aslakhellesoy/cucumber source]:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-15T02:20:02Z

Rdflterr: /* 1. GUITAR */

=GUI Testing Frameworks=

==Introduction==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Rip the GUI structure of the AUT
To begin testing an application, the tester first needs to determine the GUI structure of the AUT. Running the Ripper applications on the AUT automatically does this.

Types of rippers are available for analyzing the AUT.
For analyzing an AUT developed using
**Java use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/JavaGUIRipper.htm JavaGUIRipper]
**Native Win32 use [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/GUIRipper.htm Windows GUI Ripper]

*Generate the Event Flow Graph
The Event Flow Graph is generated from the GUI structure, ripped in the above step. The EFGGenerator generates the event-flow graph for an AUT’s GUI. To see how to analyzes a window-based application and understand its GUI integration tree. This is explained in detail [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/EFGGenerator.htm here]

*Generate Test cases
To generate testcases from the event flow graphs use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/TCGenerator.htm TCGenerator]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example [http://wiki.github.com/aslakhellesoy/cucumber source]:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-14T16:26:42Z

Rdflterr:

=GUI Testing Frameworks=

==Introduction==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example [http://wiki.github.com/aslakhellesoy/cucumber source]:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-14T16:10:02Z

Rdflterr: /* 6. Cucumber: */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example [http://wiki.github.com/aslakhellesoy/cucumber source]:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-10T03:01:22Z

Rdflterr: /* Some problems of GUI testing */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-10T03:00:46Z

Rdflterr: /* Some problems of GUI testing */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI, only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-10T02:58:58Z

Rdflterr: /* Some problems of GUI testing */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen using manual tools to mimic the usage of the GUI, only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-10T02:53:48Z

Rdflterr: /* 1. GUITAR */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests are that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests ill the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen using manual tools to mimic the usage of the GUI, only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-10T02:53:13Z

Rdflterr: /* 5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94] */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests are that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests ill the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen using manual tools to mimic the usage of the GUI, only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project which helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-10T02:50:18Z

Rdflterr: /* 3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf] */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests are that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests ill the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen using manual tools to mimic the usage of the GUI, only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage upon no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project which helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-10T02:50:05Z

Rdflterr: /* 3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf] */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests are that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests ill the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen using manual tools to mimic the usage of the GUI, only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage upon no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project which helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-10T02:49:29Z

Rdflterr: /* 2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932] */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests are that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests ill the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen using manual tools to mimic the usage of the GUI, only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of the testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage upon no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project which helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:guitar.jpg|650px|thumb|center|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94