Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:25:55Z

Asridha2: /* Introduction */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big> 

=Introduction=
Testing plays a major role in the software development cycle. It is a well known fact that mandatory testing of every functionality implemented be done so as to ensure that the code does not break when in production. Testing can be done in four main stages: Unit testing (individual code modules are tested for flaws and re-coded if any errors are found), Integration testing (various interacting modules are put together piece by piece to ensure that seamless integration exists among them), System testing (the system is tested as a whole after it has been fully integrated) and Acceptance testing (potential users test the system for flaws in design or execution and to see if the product matches their expectation).

This article focuses on Unit testing by following the Test Driven Development approach for Ruby using RSpec framework.

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step [http://jeffkreeftmeijer.com/2011/spec-helpers-bundler-setup-faster-rails-test-suites/]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:18:08Z

Asridha2: /* Other Interesting Links */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big> 

=Introduction=

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby][http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [2]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host.[3]
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step[4]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=

=Other Interesting Links=
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
*[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
*[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:16:21Z

Asridha2: /* Also see */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big> 

=Introduction=

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby][http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [2]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host.[3]
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step[4]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=

=Also see=
[[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]]
[[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]]
[[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:15:50Z

Asridha2: /* Also see */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big> 

=Introduction=

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby][1]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [2]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host.[3]
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [http://guides.rubyonrails.org/command_line.html Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [http://en.wikipedia.org/wiki/Cucumber_%28software%29 Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.

==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper is a file that RSpec creates as a part of the install step[4]. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.

=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=

=Also see=
[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ Newbies guide to TDD]
[http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial The 30 minute Regex tutorial]
[http://www.andrejkoelewijn.com/wp/2008/10/27/sql-is-a-dsl/ SQL is a DSL]

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:10:05Z

Asridha2: /* Summary */

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big> 

=Introduction=

=Characteristics of a good Unit test=
*'''Fast''':
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*'''Independent''':
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*'''Repeatable''':
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*'''Self-checking''':
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*'''Timely''':
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
[http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Languages] (DSLs) are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), [http://en.wikipedia.org/wiki/Regular_expression Regexes], [http://en.wikipedia.org/wiki/SQL SQL].

=RSpec=
[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby][1]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/JBehave] which is another BDD testing framework [2]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host.[3]
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.
==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper[] is a file that RSpec creates as a part of the install step. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.
=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. RSpec can be used to perform unit and functional testing.

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T01:08:00Z

Asridha2:

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big> 

=Introduction=

=Characteristics of a good Unit test=
*Fast:
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*Independent:
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*Repeatable:
**The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*Self-checking:
**Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance Quality Assurance] department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*Timely:
**Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)] approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=DSL=
DSLs are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general.
Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), Regexes, SQL.

=RSpec=
[RSpec] is a testing tool for [Ruby][1]. It is based on [Behavior Driven Development(BDD)] framework and is inspired by [JBehave] which is another BDD testing framework[2]. RSpec is considered a [Domain Specific Language(DSL)] for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host.[]
==Features of RSpec==
*Each test in RSpec is called a ''spec'' (which is short for specification).
*RSpec code inhabits the Spec directory which mimics the directory structure of the application.''rspec:install'' is a [Rails generator] that creates the sub-directory structure for the Spec directory.
*Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [Cucumber] to test the view functionality.
{| class="wikitable"
! Apps folder !! Spec folder
|-
| app/models/*.rb || spec/models/*_spec.rb
|-
|app/controllers/ *_controller.rb || spec/controllers/ *_controller_spec.rb
|-
| app/views/*/*.html.erb || Use Cucumber
|}
User stories are taken as the input to write RSpecs. The following is an example of one such user story:
<pre>
When I fill in "Search Posts" with "Assignments"
And I press "Search"
Then I should be on the Posts page with Assignment Posts
</pre>
Once we have the user stories ready, the next is to implement the corresponding code to realize this test case.
==The code we wish we had==
When the user clicks on the button in the view for search_posts, the controller action receives the form submission and should perform the following actions:
#It will call a method that searches the BackChannel App for posts with the specified search term(s)
#It then calls the model method to check the database to see if the entered value exists.
#If there is a match, a view with the Posts corresponding to the search terms is rendered. If no match is found, there should be a redirection to the homepage with an error message for the user's information.
The RSpec for the above mentioned scenario can be written as follows:
<pre>
require 'spec_helper'
describe PostController do
describe 'searching Posts' do
it 'should call the model method that performs Post search'
it 'should select the Search Results template for rendering'
it 'should make the Post search results available to that template'
end
end
</pre>

Spec_helper[] is a file that RSpec creates as a part of the install step. This file ensures that the functions required for testing are loaded. The behavior of the post controller is described in the code block. The main behavior that we are focusing on is searching post.
In the code, ''it'' is a method that takes in a string parameter. This string describes the actions to be performed that corresponds to the specification given in the user story. Further behaviors can be added to or nested within the main describe block, or new test scripts can be written, as per requirements.
=Summary=
A good test case must adhere to the FIRST principle (Fast, Independent, Repeatable, Self-checking, Timely). TDD or Test Driven Development is the approach in which test cases are written for code even before the implementation is realized. DSLs or Domain Specific Languages take on a very specialized set of tasks. When unit tests are written using RSpec, which is an embedded DSL for Ruby testing, we usually write the tests for the controller and model methods and leave the view testing to Cucumber. The Spec files are stored in the Spec directory which mimics the application directory structure. The spec_helper file which facilitates testing, is installed with RSpec.

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T00:53:48Z

Asridha2:

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T00:50:50Z

Asridha2:

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T00:24:57Z

Asridha2: /* Features of RSpec */

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T00:24:00Z

Asridha2: /* Features of RSpec */

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T00:23:38Z

Asridha2: /* Features of RSpec */

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T00:22:50Z

Asridha2:

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T00:16:33Z

Asridha2:

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T00:15:30Z

Asridha2:

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-27T00:01:14Z

Asridha2:

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-26T23:40:44Z

Asridha2:

CSC/ECE 517 Fall 2012/ch2a 2w30 an

2012-10-26T23:40:03Z

Asridha2:

<big>''' SaaS - 5.2 - FIRST, TDD and getting started with RSpec'''</big> 

=Introduction=

Characteristics of a good Unit test=
*Fast:
**The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
*Independent:
**When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
*Repeatable: The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
*Self-checking: Testing field has changed considerably. Where Quality Assurance department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
*Timely: Testing should follow the Test Driven Development (TDD) approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

=Disadvantages of QA=

=Rspec=

=Conclusion=

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch1 1w11 ap

2012-09-22T02:41:52Z

Asridha2: /* Designing Software */

==Introduction==
 CRC Cards, also known as [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card Class-Responsibility-Collaboration ] cards are a brainstorming tool to enable collaboration across different teams or individuals in contribution to design, usually used in Object Oriented Software development. This was proposed by Ward Cunningham and Kent Beck[http://c2.com/doc/oopsla89/paper.html]. The CRC card can be viewed as an index card, with the following details:
[[Image:crc-card.gif|frame|right|CRC Card Structure]]

:* The Top of the card usually bears the name of the class.
:* The Left side of the card has the responsibilities of the class.
:* The Right side of the card has the collaborating classes corresponding to each of the responsibilities listed in the left side.

Thus in general, a CRC session can be viewed as the interaction between a set of collaborating classes for a particular [http://en.wikipedia.org/wiki/Use_case Use case]. According to [http://www.extremeprogramming.org/rules/crccards.html]A CRC session proceeds with someone simulating the system by talking about which objects send messages to other objects. By stepping through the process' weaknesses and problems are easily uncovered. Design alternatives can be explored quickly by simulating the design being proposed.

===A CRC Example===
To better understand how the CRC cards work together, let us consider a simple student enrollment problem,where we are required to model the students enrolled in different courses. We can easily define the Student CRC Card as having attributes such as student name, student id and responsibilities that enable a student to enroll in a course or drop the course. In this particular instance, the collaborating class would be the Course class. The Course CRC Card can in turn be visualized as having its own responsibilities, such as having attributes like Course id, course name and the collaborating class would be the Instructor
class. The CRC cards for the Student class and the Course Class are shown below. 
[[Image:Stud_enr_Crc.jpg|frame|center|Student and Course CRC Card]]
 
There are also several practical designs that use the CRC card model to design Object oriented software design. The [http://www.extremeprogramming.org/example/crcsim.html Simulator for Coffee Maker] explores an [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] approach combined with CRC card technique to come up with a design for the coffee maker.

Another interesting approach using CRC cards is the design for the [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html ATM Machine]

===Advantages of CRC cards===
There are a few advantages of CRC cards that make it a preferable model in many designs. Some of the advantages of the CRC card design method are
 
:* CRC cards can allow designers to easily make audience understand a very complex system. In essence it allows for building more complex designs by slowly building the interactions between the collaborating classes, one by one.
:* CRC cards are a simple technique and it can be easily used by anyone with very little training and does not require any expensive computing resources(a board or a paper and a pen would suffice).
:* CRC is fundamentally a brainstorming tool, enabling different people in a team to come up with the design by collaborating, enabling everyone in the team to contribute
:* CRC can be used with other formal object oriented design methodologies such as [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] (an [http://en.wikipedia.org/wiki/Agile_Modeling Agile] development Technique) and can be used along with modeling languages such as [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language(UML)]

==Software for CRC Cards==
CRC cards have limited scope. If we go about designing a huge project, the scope may span many classes and there might be numerous interactions between them. The tedious task here is to maintain the CRC cards and formulate appropriate interaction between them.
We need software for CRC Cards for the following reasons:
:* Designing Scenario: A scenario represents a series of steps in which classes and objects communicate. There can be references to other scenarios.
:* Modeling : Software provides an easy way to segregate cards and objects into different diagrams. Thus we can model our problem with different functionality very easily.
:* Simulation : Software can provide simulation of the design. This might include single-stepping a scenario forward or backwards or jumping to a specific location in the scenario stack of a multiple scenario simulation.
:* Synchronization and Dependencies: Software can maintain relationships between cards and scenarios as design changes take place. If a card references other cards or classes, any changes in those cards are generated automatically. Also any name changes and cross references between objects are instantly updated.
:* Revision history and [http://en.wikipedia.org/wiki/Revision_control Version Control] : Software for CRC cards supports changes to CRC cards. It is easy to model and keep track of all changes to a CRC card. This is extremely helpful in tracking design changes.

==Designing Software==
The steps to design software for CRC cards are:

*Create CRC Cards : A CRC model is usually created by an individual (or small group of designers) during the early phase of an object-oriented development project. The figure shows the design of hierarchy of classes. The set of class used for drawing objects are shown. We can see TShape class has a superclass called TObject and two subclasses, TBox and TCircle. Let us assume we create new class TWindow derived from the superclass TObject. [[Image:Design.png|thumb|Description]]

*Assign Responsibilities : Once a set of classes are defined, behaviors can be assigned that will provide the functions of the application. For example, the TShape card has responsibilities ''Initialize'' to create it and ''Draw'' to illustrate it on the diagram.

*Add Attributes : Attributes of classes may also be identified in a CRC Card. The TShape class has attributes fPosition, fType and fSelected.

*Define and simulate Scenario : A scenario describes a sequence of steps in the design using the responsibilities of a group of collaborating classes. Collaboration between classes refers to a client object that uses a responsibility performed by a server object. Often a class must call upon several collaborating classes to implement one of its responsibilities. A scenario describes what happens in the system from a high-level, user's point of view.
[[Image:Scenario.png|thumb|Description]]

Consider the situation to the right. We have defined two CRC cards with their responsibilities. A scenario defines several steps. Each step in a scenario has a Client, Server and Responsibility field. For each step, a client class uses a responsibility of a server class

The Open Document scenario in the picture references the Initialize Document sub-scenario by specifying its server class ''Document'' in the server field and its scenario name in the Responsibility field. The first step in the Initialize Document sub-scenario uses ''Document'' as the server class name. By single-stepping forward, backwards or through each sub-scenario, bugs in the design can be identified and corrected early.

*Partition the Design : As the number of CRC cards in the design grow, they can be grouped by function. By using Software for CRC cards, we can draw separate diagrams to partition the model into different subject areas.

*[http://www.google.com/search?q=what+is+an+inheritance+graph&rlz=1C1CHFX_enUS460US460&sugexp=chrome,mod=14&sourceid=chrome&ie=UTF-8#hl=en&rlz=1C1CHFX_enUS460US460&q=inheritance+graph&tbs=dfn:1&tbo=u&sa=X&ei=IyFdUK_wAZLw8ATD8oHgCw&ved=0CB8QkQ4&bav=on.2,or.r_gc.r_pw.r_qf.&fp=99d6414d69e5a888&biw=1517&bih=783 Inheritance Graph] : An automated tool can generate an inheritance graph from information on CRC cards. This diagram can concisely illustrate the big picture of a large project that might contain hundreds of classes and dozens of diagrams.

*Verify Your Work : Creating and simulating scenarios will help verify that a design is correct and complete. A CRC software can perform other error checks to locate design problems. For example, responsibilities that are not used in any scenarios may indicate that the design is incomplete or perhaps the responsibility isn't needed. Likewise, a card that is not used by any collaboration may not be needed.

==Software Development Process for Object Oriented Development[6]==

Software Development Life Cycles are different for a standard development process and for Object Oriented development. This difference needs to be understood in order to know how to meet the benchmarks set for the project. There are multiple processes that are used in software development, the most common ones in use being Waterfall model and Spiral model. The Waterfall model is progression based and the Spiral model is iterative.

We need to understand that the uniqueness of Object Oriented SDLCs comes from the fact that it is more user centric as compared to standard SDLCs that are more system centric. We will now see which models work for Object Oriented SDLCs (OO SDLCs) and which don’t. CRC cards play a very important role in an Object Oriented SDLC. Thus, figuring out which models work well for OO SDLCs will result in understanding which models use CRC cards and why.

====The Waterfall Model====

The Waterfall model is implemented in multiple phases with each phase having a clear demarcation in terms of its functionality and deliverable. It uses clear stepping stones to come up with deliverables for each deadline. In this case, there are multiple ways to measure progress and methods by which to audit internally and apply checkpoints.

The downside of the Waterfall model lies in the fact that it is a very rigid model that does not offer much in terms of leeway when it comes to deliverables and what each phase in the cycle has to offer. The process is also overly mechanical and over time, just ends up being boring.

Owing to the emphasis on checkpoints and deliverables with strict deadlines, in most cases the analysis and design phases are usually cut short and thus, the project may veer very far from reality. The users are involved only in the requirement gathering phase. This might result in mistranslation of the requirements of the user into what may be an amazing final product but something that the user did not even ask for.

====The Spiral Model====
This model iteratively goes through the phases of analysis, design, prototyping and testing after the initial requirements gathering phase. With each iteration, the product is improved based on the feedback from testing in the previous iteration. If required, the outcome of each phase is analyzed, revised and the next prototype is developed after the design is revised, if pertinent. The products from the first phase are not abandoned, they are revised. Evidently, this model is non-linear in nature.

After the first pass through the checkpoint, we can conclude that the work so far is adequate, but not final. The model places emphasis on the iterative process and on the development of standard prototypes at the end of each iteration. At the end of every cycle, we notice the shortcomings from the previous cycle and might end up having to redo all the work in the previous cycle. This proves to be a complete waste of time and effort. All the effort now goes into developing the end point for an older cycle, which makes the model ineffective for the current cycle.

One of the major drawbacks of such a non linear model is that the cost effectiveness and risk analysis cannot be analyzed thoroughly.

====Why CRC cards are not useful in Waterfall and Spiral Models====

The strength of OO model depends on the idea that, here, design and deployment come together. In the case of a spiral model, this works to make the spiral tighter. Since the waterfall model places over importance on deliverables and user involvement is minimal, which is one of the key focuses of OO SLDCs using CRC cards, the model is considered ineffective. The Spiral model involves multiple revisions of the same idea. When a set of cards have been developed, it would make sense to refine the idea presented in the card but not to redefine them over and over, which may be the case. This does not serve the purpose of actually convening a CRC discussion among the team to draw up cards corresponding to the user requirement. Moreover, in the case of the Spiral model, we would need to convene multiple such meetings at each iteration, which would drastically bring down the overall productivity of the team.

==CRC Cards in Software Development Process==

===Agile Methodology and CRC Cards===

Agile development is a model that has resurfaced and is gaining fame for its incremental cum iterative process. The iteration is carried over the processes of discovery, analysis, design and coding. In each iteration, the old model is worked on in each of the overlapping mini-cycles. The overlap of the cycles makes the process apparently iterative in nature. The model is considered incremental since every step acts as a value-add and this is emphasized by the capacity of classes for reuse. The idea that each phase is repeated ensures that the project is constantly working on a higher level of understanding. Moreover, the OOPS concept of reuse can be used to our advantage such that when we are continuously using OO development models in all our projects, the next implementation can be started far ahead in the SDLC.

The model focuses on analysis and design phase predominantly. Within each of these are mini phases of analysis->prototype->revision-> implementation cycles. The advantage of this model compared to other models described is that, being incremental, this also results in tightening of the spiral at the end of each iteration using concepts such as reusability and polymorphism. Thus, the progression from one point to another in the cycle is seamless from start to deployment.

CRC cards can be very effectively and efficiently used in the Agile model of OO SDLC owing to the fact that it is incremental as well as iterative and not just a repetitive process. Thus, we would not have to redefine the cards from the scratch at any point. Being incremental, we would refine our current model and proceed to refine the entire system as a whole at the end of all iterations. We would essentially be adding value to the cards written out in the previous cycle and if perfected, would never have to discard cards from any of the precious cycles.

Agile also practices active customer involvement. In every phase, the user is involved. This is one of the key characteristics of the CRC card design method. This not only ensures that the final product is as per the customer's requirements, but also that the customer is thoroughly satisfied, since they are aware of the changes and increments at each level. Another key aspect of Agile methodology is that it is feature driven. A CRC card holds details as to the feature of each class and how it collaborates with the rest of the system. Since this information is readily available to the developer and is highly fine-tuned by the end of the SDLC process, the cards can guarantee focus on 80/20 principle (i.e. pay more attention to 20% of the features which will used 80% of the times).

The power of CRC cards for OOP development is in the group session that employs them. The use of CRC cards is an excellent way for people to begin to grasp the underlying idea of object oriented approach. CRC cards are used in a few steps of the software development process such as Analysis and Design.

===CRC Cards for Analysis===

CRC cards and CRC card sessions are good at organizing and spreading domain knowledge in the analysis phase. When building an object–oriented application, the focus of the CRC card sessions is on analyzing and describing the problem. In this phase, the group identifies the objects that are relevant to the application. Before going to the CRC card session, the team must be aware of the domain classes and frameworks that exist to help them model the problem. During the session, they can decide if the existing ones can be used for the new application.

'''Advantages of using CRC cards in Analysis phase:'''

* People from all phases of the project are involved in the card sessions for problem modeling. The names of the classes and responsibilities are created, argued and agreed upon by the team members at the start itself in order to avoid conflicts later. This gives rise to common project and product vocabulary across different roles.

* Domain knowledge already known is shared in the sessions. Also, missing domain knowledge is identified.

* Role plays are conducted during these sessions that help spread knowledge about OO concepts.

* These sessions can be used to create a live prototype of what the application is supposed to do. This can be shown to clients as well so that the team receives feedback on their understanding of the requirements.

* A CRC card session will help the team walk through the requirements and identify any ambiguities.

At the end of the analysis phase, the CRC elements that will be available are:

* '''Classes:''' The classes identified in this phase directly reflect the concepts of the application that is being analyzed. It may not be modeled in terms of software system but it is useful in describing how the application works. However, at this stage the distinction between objects and classes may not be clear.

* '''Responsibilities:''' The responsibilities that are assigned to the classes in this phase are of relatively higher level.

===CRC Cards for Design===

During the CRC cards design sessions, other relevant classes are added, if any. "While an analysis must reflect the real world of the user, the design must reflect the real world of the implementers."[5] A CRC card tool may be helpful for saving, illustrating and documenting a design.

'''Advantages of using CRC cards in Design phase:'''

* These sessions help the team members concentrate on taking the design decisions for the application. These design decisions also include performance, efficiency and other constraints.

* By walking through the scenarios that were seen during the analysis phase, the implementers can give the testers an overview of how the application should work.

* Using CRC cards forces decision to be made up front in front of the team, thus any conflicts can be resolved right there.

* Design constraints such as target environment, language, UI, performance etc., can be discussed during these sessions to check if the design can be implemented.

==Summary==
Software for CRC cards are immensely helpful in designing and modeling software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.

==See Also==
*[http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language(UML)]
*[http://en.wikipedia.org/wiki/Agile_Modeling Agile Modelling]
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]

==References==
[1] [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking]

[2] [http://www.extremeprogramming.org/rules/crccards.html CRC Cards]

[3] [http://www.extremeprogramming.org/example/crcsim.html A Simulator for Coffee Maker]

[4] [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html CRC Card for ATM]

[5] "Using CRC Cards: An Informal Approach to Object-Oriented Development" by Nancy M.Wilkinson

[6] [http://books.google.com/books?id=SGOyQai2TboC&printsec=frontcover&dq=CRC+card+book&hl=en&ei=xSOaTKSaNISclgfRqtkK&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDYQ6AEwAA#v=onepage&q&f=false The CRC card book] by David Bellin, Susan Suchman Simone

==External Links==
* [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking] by Ward Cunningham and Kent Beck
* [http://www.agilemodeling.com/artifacts/crcModel.htm Modelling CRC Cards]
* [http://www.excelsoftware.com/quickcrcwin.html Quick CRC]
* [http://www.indicthreads.com/1439/quick-introduction-to-agile-software-development Quick Introduction to Agile Software Development]

CSC/ECE 517 Fall 2012/ch1 1w11 ap

2012-09-22T02:33:27Z

Asridha2: /* Software for CRC Cards */

==Introduction==
 CRC Cards, also known as [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card Class-Responsibility-Collaboration ] cards are a brainstorming tool to enable collaboration across different teams or individuals in contribution to design, usually used in Object Oriented Software development. This was proposed by Ward Cunningham and Kent Beck[http://c2.com/doc/oopsla89/paper.html]. The CRC card can be viewed as an index card, with the following details:
[[Image:crc-card.gif|frame|right|CRC Card Structure]]

:* The Top of the card usually bears the name of the class.
:* The Left side of the card has the responsibilities of the class.
:* The Right side of the card has the collaborating classes corresponding to each of the responsibilities listed in the left side.

Thus in general, a CRC session can be viewed as the interaction between a set of collaborating classes for a particular [http://en.wikipedia.org/wiki/Use_case Use case]. According to [http://www.extremeprogramming.org/rules/crccards.html]A CRC session proceeds with someone simulating the system by talking about which objects send messages to other objects. By stepping through the process' weaknesses and problems are easily uncovered. Design alternatives can be explored quickly by simulating the design being proposed.

===A CRC Example===
To better understand how the CRC cards work together, let us consider a simple student enrollment problem,where we are required to model the students enrolled in different courses. We can easily define the Student CRC Card as having attributes such as student name, student id and responsibilities that enable a student to enroll in a course or drop the course. In this particular instance, the collaborating class would be the Course class. The Course CRC Card can in turn be visualized as having its own responsibilities, such as having attributes like Course id, course name and the collaborating class would be the Instructor
class. The CRC cards for the Student class and the Course Class are shown below. 
[[Image:Stud_enr_Crc.jpg|frame|center|Student and Course CRC Card]]
 
There are also several practical designs that use the CRC card model to design Object oriented software design. The [http://www.extremeprogramming.org/example/crcsim.html Simulator for Coffee Maker] explores an [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] approach combined with CRC card technique to come up with a design for the coffee maker.

Another interesting approach using CRC cards is the design for the [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html ATM Machine]

===Advantages of CRC cards===
There are a few advantages of CRC cards that make it a preferable model in many designs. Some of the advantages of the CRC card design method are
 
:* CRC cards can allow designers to easily make audience understand a very complex system. In essence it allows for building more complex designs by slowly building the interactions between the collaborating classes, one by one.
:* CRC cards are a simple technique and it can be easily used by anyone with very little training and does not require any expensive computing resources(a board or a paper and a pen would suffice).
:* CRC is fundamentally a brainstorming tool, enabling different people in a team to come up with the design by collaborating, enabling everyone in the team to contribute
:* CRC can be used with other formal object oriented design methodologies such as [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] (an [http://en.wikipedia.org/wiki/Agile_Modeling Agile] development Technique) and can be used along with modeling languages such as [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language(UML)]

==Software for CRC Cards==
CRC cards have limited scope. If we go about designing a huge project, the scope may span many classes and there might be numerous interactions between them. The tedious task here is to maintain the CRC cards and formulate appropriate interaction between them.
We need software for CRC Cards for the following reasons:
:* Designing Scenario: A scenario represents a series of steps in which classes and objects communicate. There can be references to other scenarios.
:* Modeling : Software provides an easy way to segregate cards and objects into different diagrams. Thus we can model our problem with different functionality very easily.
:* Simulation : Software can provide simulation of the design. This might include single-stepping a scenario forward or backwards or jumping to a specific location in the scenario stack of a multiple scenario simulation.
:* Synchronization and Dependencies: Software can maintain relationships between cards and scenarios as design changes take place. If a card references other cards or classes, any changes in those cards are generated automatically. Also any name changes and cross references between objects are instantly updated.
:* Revision history and [http://en.wikipedia.org/wiki/Revision_control Version Control] : Software for CRC cards supports changes to CRC cards. It is easy to model and keep track of all changes to a CRC card. This is extremely helpful in tracking design changes.

==Designing Software==
The steps to design software for CRC cards are:

*Create CRC Cards : A CRC model is usually created by an individual or small group of designers during the early phase of an object-oriented development project.The figure shows the design of hierarchy of classes. These set of class used for drawing objects are shown. We can see TShape class has a superclass called TObject and two subclasses, TBox and TCircle. Lets assume we create new class TWindow derived from the superclass TObject. [[Image:Design.png|thumb|Description]]

*Assign Responsibilities : Once a set of classes are defined, behaviors can be assigned that will provide the functions of the application. For example, the TShape card has responsibilities ''Initialize'' to create it and ''Draw'' to illustrate it on the diagram.

*Add Attributes : Attributes of classes may also be identified in a CRC Card.The TShape class has attributes fPosition, fType and fSelected.

*Define and simulate Scenario : A scenario describes a sequence of steps in the design using the responsibilities of a group of collaborating classes. Collaboration between classes refers to a client object that uses a responsibility performed by a server object. Often a class must call upon several collaborating classes to implement one of its responsibilities.A scenario describes what happens in the system from a high-level, user's point of view.
[[Image:Scenario.png|thumb|Description]]

Consider situation to the right. We have defined two CRC cards with their responsibility. A scenario defines several steps. Each step in a scenario has a Client, Server and Responsibility field. For each step, a client class uses a responsibility of a server class

The Open Document scenario in the picture references the Initialize Document sub-scenario by specifying its server class ''Document'' in the server field and its scenario name in the Responsibility field. The first step in the Initialize Document sub-scenario uses ''Document'' as the server class name. By single-stepping forwards, backwards or through each sub-scenario, bugs in the design can be identified and corrected early.

*Partition the Design : As the number of CRC cards in the design grow, they can be grouped by function. By using Software for CRC cards,we can draw separate diagrams to partition the model into different subject areas.

*[http://www.google.com/search?q=what+is+an+inheritance+graph&rlz=1C1CHFX_enUS460US460&sugexp=chrome,mod=14&sourceid=chrome&ie=UTF-8#hl=en&rlz=1C1CHFX_enUS460US460&q=inheritance+graph&tbs=dfn:1&tbo=u&sa=X&ei=IyFdUK_wAZLw8ATD8oHgCw&ved=0CB8QkQ4&bav=on.2,or.r_gc.r_pw.r_qf.&fp=99d6414d69e5a888&biw=1517&bih=783 Inheritance Graph] : An automated tool can generate an inheritance graph from information on CRC cards. This diagram can concisely illustrate the big picture of a large project that might contain hundreds of classes and dozens of diagrams.

*Verify Your Work : Creating and simulating scenarios will help verify that a design is correct and complete. A CRC software can perform other error checks to locate design problems. For example, responsibilities that are not used in any scenarios may indicate that the design is incomplete or perhaps the responsibility isn't needed. Likewise, a card that is not used by any collaboration may not be needed.

==Software Development Process for Object Oriented Development[6]==

Software Development Life Cycles are different for a standard development process and for Object Oriented development. This difference needs to be understood in order to know how to meet the benchmarks set for the project. There are multiple processes that are used in software development, the most common ones in use being Waterfall model and Spiral model. The Waterfall model is progression based and the Spiral model is iterative.

We need to understand that the uniqueness of Object Oriented SDLCs comes from the fact that it is more user centric as compared to standard SDLCs that are more system centric. We will now see which models work for Object Oriented SDLCs (OO SDLCs) and which don’t. CRC cards play a very important role in an Object Oriented SDLC. Thus, figuring out which models work well for OO SDLCs will result in understanding which models use CRC cards and why.

====The Waterfall Model====

The Waterfall model is implemented in multiple phases with each phase having a clear demarcation in terms of its functionality and deliverable. It uses clear stepping stones to come up with deliverables for each deadline. In this case, there are multiple ways to measure progress and methods by which to audit internally and apply checkpoints.

The downside of the Waterfall model lies in the fact that it is a very rigid model that does not offer much in terms of leeway when it comes to deliverables and what each phase in the cycle has to offer. The process is also overly mechanical and over time, just ends up being boring.

Owing to the emphasis on checkpoints and deliverables with strict deadlines, in most cases the analysis and design phases are usually cut short and thus, the project may veer very far from reality. The users are involved only in the requirement gathering phase. This might result in mistranslation of the requirements of the user into what may be an amazing final product but something that the user did not even ask for.

====The Spiral Model====
This model iteratively goes through the phases of analysis, design, prototyping and testing after the initial requirements gathering phase. With each iteration, the product is improved based on the feedback from testing in the previous iteration. If required, the outcome of each phase is analyzed, revised and the next prototype is developed after the design is revised, if pertinent. The products from the first phase are not abandoned, they are revised. Evidently, this model is non-linear in nature.

After the first pass through the checkpoint, we can conclude that the work so far is adequate, but not final. The model places emphasis on the iterative process and on the development of standard prototypes at the end of each iteration. At the end of every cycle, we notice the shortcomings from the previous cycle and might end up having to redo all the work in the previous cycle. This proves to be a complete waste of time and effort. All the effort now goes into developing the end point for an older cycle, which makes the model ineffective for the current cycle.

One of the major drawbacks of such a non linear model is that the cost effectiveness and risk analysis cannot be analyzed thoroughly.

====Why CRC cards are not useful in Waterfall and Spiral Models====

The strength of OO model depends on the idea that, here, design and deployment come together. In the case of a spiral model, this works to make the spiral tighter. Since the waterfall model places over importance on deliverables and user involvement is minimal, which is one of the key focuses of OO SLDCs using CRC cards, the model is considered ineffective. The Spiral model involves multiple revisions of the same idea. When a set of cards have been developed, it would make sense to refine the idea presented in the card but not to redefine them over and over, which may be the case. This does not serve the purpose of actually convening a CRC discussion among the team to draw up cards corresponding to the user requirement. Moreover, in the case of the Spiral model, we would need to convene multiple such meetings at each iteration, which would drastically bring down the overall productivity of the team.

==CRC Cards in Software Development Process==

===Agile Methodology and CRC Cards===

Agile development is a model that has resurfaced and is gaining fame for its incremental cum iterative process. The iteration is carried over the processes of discovery, analysis, design and coding. In each iteration, the old model is worked on in each of the overlapping mini-cycles. The overlap of the cycles makes the process apparently iterative in nature. The model is considered incremental since every step acts as a value-add and this is emphasized by the capacity of classes for reuse. The idea that each phase is repeated ensures that the project is constantly working on a higher level of understanding. Moreover, the OOPS concept of reuse can be used to our advantage such that when we are continuously using OO development models in all our projects, the next implementation can be started far ahead in the SDLC.

The model focuses on analysis and design phase predominantly. Within each of these are mini phases of analysis->prototype->revision-> implementation cycles. The advantage of this model compared to other models described is that, being incremental, this also results in tightening of the spiral at the end of each iteration using concepts such as reusability and polymorphism. Thus, the progression from one point to another in the cycle is seamless from start to deployment.

CRC cards can be very effectively and efficiently used in the Agile model of OO SDLC owing to the fact that it is incremental as well as iterative and not just a repetitive process. Thus, we would not have to redefine the cards from the scratch at any point. Being incremental, we would refine our current model and proceed to refine the entire system as a whole at the end of all iterations. We would essentially be adding value to the cards written out in the previous cycle and if perfected, would never have to discard cards from any of the precious cycles.

Agile also practices active customer involvement. In every phase, the user is involved. This is one of the key characteristics of the CRC card design method. This not only ensures that the final product is as per the customer's requirements, but also that the customer is thoroughly satisfied, since they are aware of the changes and increments at each level. Another key aspect of Agile methodology is that it is feature driven. A CRC card holds details as to the feature of each class and how it collaborates with the rest of the system. Since this information is readily available to the developer and is highly fine-tuned by the end of the SDLC process, the cards can guarantee focus on 80/20 principle (i.e. pay more attention to 20% of the features which will used 80% of the times).

The power of CRC cards for OOP development is in the group session that employs them. The use of CRC cards is an excellent way for people to begin to grasp the underlying idea of object oriented approach. CRC cards are used in a few steps of the software development process such as Analysis and Design.

===CRC Cards for Analysis===

CRC cards and CRC card sessions are good at organizing and spreading domain knowledge in the analysis phase. When building an object–oriented application, the focus of the CRC card sessions is on analyzing and describing the problem. In this phase, the group identifies the objects that are relevant to the application. Before going to the CRC card session, the team must be aware of the domain classes and frameworks that exist to help them model the problem. During the session, they can decide if the existing ones can be used for the new application.

'''Advantages of using CRC cards in Analysis phase:'''

* People from all phases of the project are involved in the card sessions for problem modeling. The names of the classes and responsibilities are created, argued and agreed upon by the team members at the start itself in order to avoid conflicts later. This gives rise to common project and product vocabulary across different roles.

* Domain knowledge already known is shared in the sessions. Also, missing domain knowledge is identified.

* Role plays are conducted during these sessions that help spread knowledge about OO concepts.

* These sessions can be used to create a live prototype of what the application is supposed to do. This can be shown to clients as well so that the team receives feedback on their understanding of the requirements.

* A CRC card session will help the team walk through the requirements and identify any ambiguities.

At the end of the analysis phase, the CRC elements that will be available are:

* '''Classes:''' The classes identified in this phase directly reflect the concepts of the application that is being analyzed. It may not be modeled in terms of software system but it is useful in describing how the application works. However, at this stage the distinction between objects and classes may not be clear.

* '''Responsibilities:''' The responsibilities that are assigned to the classes in this phase are of relatively higher level.

===CRC Cards for Design===

During the CRC cards design sessions, other relevant classes are added, if any. "While an analysis must reflect the real world of the user, the design must reflect the real world of the implementers."[5] A CRC card tool may be helpful for saving, illustrating and documenting a design.

'''Advantages of using CRC cards in Design phase:'''

* These sessions help the team members concentrate on taking the design decisions for the application. These design decisions also include performance, efficiency and other constraints.

* By walking through the scenarios that were seen during the analysis phase, the implementers can give the testers an overview of how the application should work.

* Using CRC cards forces decision to be made up front in front of the team, thus any conflicts can be resolved right there.

* Design constraints such as target environment, language, UI, performance etc., can be discussed during these sessions to check if the design can be implemented.

==Summary==
Software for CRC cards are immensely helpful in designing and modeling software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.

==See Also==
*[http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language(UML)]
*[http://en.wikipedia.org/wiki/Agile_Modeling Agile Modelling]
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]

==References==
[1] [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking]

[2] [http://www.extremeprogramming.org/rules/crccards.html CRC Cards]

[3] [http://www.extremeprogramming.org/example/crcsim.html A Simulator for Coffee Maker]

[4] [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html CRC Card for ATM]

[5] "Using CRC Cards: An Informal Approach to Object-Oriented Development" by Nancy M.Wilkinson

[6] [http://books.google.com/books?id=SGOyQai2TboC&printsec=frontcover&dq=CRC+card+book&hl=en&ei=xSOaTKSaNISclgfRqtkK&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDYQ6AEwAA#v=onepage&q&f=false The CRC card book] by David Bellin, Susan Suchman Simone

==External Links==
* [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking] by Ward Cunningham and Kent Beck
* [http://www.agilemodeling.com/artifacts/crcModel.htm Modelling CRC Cards]
* [http://www.excelsoftware.com/quickcrcwin.html Quick CRC]
* [http://www.indicthreads.com/1439/quick-introduction-to-agile-software-development Quick Introduction to Agile Software Development]

CSC/ECE 517 Fall 2012/ch1 1w11 ap

2012-09-22T02:28:31Z

Asridha2:

==Introduction==
 CRC Cards, also known as [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card Class-Responsibility-Collaboration ] cards are a brainstorming tool to enable collaboration across different teams or individuals in contribution to design, usually used in Object Oriented Software development. This was proposed by Ward Cunningham and Kent Beck[http://c2.com/doc/oopsla89/paper.html]. The CRC card can be viewed as an index card, with the following details:
[[Image:crc-card.gif|frame|right|CRC Card Structure]]

:* The Top of the card usually bears the name of the class.
:* The Left side of the card has the responsibilities of the class.
:* The Right side of the card has the collaborating classes corresponding to each of the responsibilities listed in the left side.

Thus in general, a CRC session can be viewed as the interaction between a set of collaborating classes for a particular [http://en.wikipedia.org/wiki/Use_case Use case]. According to [http://www.extremeprogramming.org/rules/crccards.html]A CRC session proceeds with someone simulating the system by talking about which objects send messages to other objects. By stepping through the process' weaknesses and problems are easily uncovered. Design alternatives can be explored quickly by simulating the design being proposed.

===A CRC Example===
To better understand how the CRC cards work together, let us consider a simple student enrollment problem,where we are required to model the students enrolled in different courses. We can easily define the Student CRC Card as having attributes such as student name, student id and responsibilities that enable a student to enroll in a course or drop the course. In this particular instance, the collaborating class would be the Course class. The Course CRC Card can in turn be visualized as having its own responsibilities, such as having attributes like Course id, course name and the collaborating class would be the Instructor
class. The CRC cards for the Student class and the Course Class are shown below. 
[[Image:Stud_enr_Crc.jpg|frame|center|Student and Course CRC Card]]
 
There are also several practical designs that use the CRC card model to design Object oriented software design. The [http://www.extremeprogramming.org/example/crcsim.html Simulator for Coffee Maker] explores an [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] approach combined with CRC card technique to come up with a design for the coffee maker.

Another interesting approach using CRC cards is the design for the [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html ATM Machine]

===Advantages of CRC cards===
There are a few advantages of CRC cards that make it a preferable model in many designs. Some of the advantages of the CRC card design method are
 
:* CRC cards can allow designers to easily make audience understand a very complex system. In essence it allows for building more complex designs by slowly building the interactions between the collaborating classes, one by one.
:* CRC cards are a simple technique and it can be easily used by anyone with very little training and does not require any expensive computing resources(a board or a paper and a pen would suffice).
:* CRC is fundamentally a brainstorming tool, enabling different people in a team to come up with the design by collaborating, enabling everyone in the team to contribute
:* CRC can be used with other formal object oriented design methodologies such as [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] (an [http://en.wikipedia.org/wiki/Agile_Modeling Agile] development Technique) and can be used along with modeling languages such as [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language(UML)]

==Software for CRC Cards==
CRC cards have limited scope. If we go about designing a huge project, the scope spans many classes and interactions between them. The tedious task here is to maintain the CRC cards and properly formulate interaction between them.
We need software for CRC Cards for the following reasons:
:* Designing Scenario: A scenario represents series of steps in which classes and objects communicate. There can be references to other cards or scenarios.
:* Modeling : Software provides an easy way to segregate cards and objects into different diagrams. Thus we can model our problem with different functionality very easily.
:* Simulation : Software can provide simulation of the design. This might include single-stepping a scenario forwards/backwards or jumping to a specific location in the scenario stack of a multiple scenario simulation
:* Synchronization and Dependencies: Software can maintain relationships between cards, scenarios as design changes take place. If a card references other cards or classes, those cards are generated automatically. Also any name changes and cross references between objects are instantly updated.
:* Revision history and Version Control : Software for CRC cards supports changes to CRC cards. It is easy to model and keep track of all changes to a CRC card. This is extremely helpful in tracking the design changes in CRC cards.

==Designing Software==
The steps to design software for CRC cards are:

*Create CRC Cards : A CRC model is usually created by an individual or small group of designers during the early phase of an object-oriented development project.The figure shows the design of hierarchy of classes. These set of class used for drawing objects are shown. We can see TShape class has a superclass called TObject and two subclasses, TBox and TCircle. Lets assume we create new class TWindow derived from the superclass TObject. [[Image:Design.png|thumb|Description]]

*Assign Responsibilities : Once a set of classes are defined, behaviors can be assigned that will provide the functions of the application. For example, the TShape card has responsibilities ''Initialize'' to create it and ''Draw'' to illustrate it on the diagram.

*Add Attributes : Attributes of classes may also be identified in a CRC Card.The TShape class has attributes fPosition, fType and fSelected.

*Define and simulate Scenario : A scenario describes a sequence of steps in the design using the responsibilities of a group of collaborating classes. Collaboration between classes refers to a client object that uses a responsibility performed by a server object. Often a class must call upon several collaborating classes to implement one of its responsibilities.A scenario describes what happens in the system from a high-level, user's point of view.
[[Image:Scenario.png|thumb|Description]]

Consider situation to the right. We have defined two CRC cards with their responsibility. A scenario defines several steps. Each step in a scenario has a Client, Server and Responsibility field. For each step, a client class uses a responsibility of a server class

The Open Document scenario in the picture references the Initialize Document sub-scenario by specifying its server class ''Document'' in the server field and its scenario name in the Responsibility field. The first step in the Initialize Document sub-scenario uses ''Document'' as the server class name. By single-stepping forwards, backwards or through each sub-scenario, bugs in the design can be identified and corrected early.

*Partition the Design : As the number of CRC cards in the design grow, they can be grouped by function. By using Software for CRC cards,we can draw separate diagrams to partition the model into different subject areas.

*[http://www.google.com/search?q=what+is+an+inheritance+graph&rlz=1C1CHFX_enUS460US460&sugexp=chrome,mod=14&sourceid=chrome&ie=UTF-8#hl=en&rlz=1C1CHFX_enUS460US460&q=inheritance+graph&tbs=dfn:1&tbo=u&sa=X&ei=IyFdUK_wAZLw8ATD8oHgCw&ved=0CB8QkQ4&bav=on.2,or.r_gc.r_pw.r_qf.&fp=99d6414d69e5a888&biw=1517&bih=783 Inheritance Graph] : An automated tool can generate an inheritance graph from information on CRC cards. This diagram can concisely illustrate the big picture of a large project that might contain hundreds of classes and dozens of diagrams.

*Verify Your Work : Creating and simulating scenarios will help verify that a design is correct and complete. A CRC software can perform other error checks to locate design problems. For example, responsibilities that are not used in any scenarios may indicate that the design is incomplete or perhaps the responsibility isn't needed. Likewise, a card that is not used by any collaboration may not be needed.

==Software Development Process for Object Oriented Development[6]==

Software Development Life Cycles are different for a standard development process and for Object Oriented development. This difference needs to be understood in order to know how to meet the benchmarks set for the project. There are multiple processes that are used in software development, the most common ones in use being Waterfall model and Spiral model. The Waterfall model is progression based and the Spiral model is iterative.

We need to understand that the uniqueness of Object Oriented SDLCs comes from the fact that it is more user centric as compared to standard SDLCs that are more system centric. We will now see which models work for Object Oriented SDLCs (OO SDLCs) and which don’t. CRC cards play a very important role in an Object Oriented SDLC. Thus, figuring out which models work well for OO SDLCs will result in understanding which models use CRC cards and why.

====The Waterfall Model====

The Waterfall model is implemented in multiple phases with each phase having a clear demarcation in terms of its functionality and deliverable. It uses clear stepping stones to come up with deliverables for each deadline. In this case, there are multiple ways to measure progress and methods by which to audit internally and apply checkpoints.

The downside of the Waterfall model lies in the fact that it is a very rigid model that does not offer much in terms of leeway when it comes to deliverables and what each phase in the cycle has to offer. The process is also overly mechanical and over time, just ends up being boring.

Owing to the emphasis on checkpoints and deliverables with strict deadlines, in most cases the analysis and design phases are usually cut short and thus, the project may veer very far from reality. The users are involved only in the requirement gathering phase. This might result in mistranslation of the requirements of the user into what may be an amazing final product but something that the user did not even ask for.

====The Spiral Model====
This model iteratively goes through the phases of analysis, design, prototyping and testing after the initial requirements gathering phase. With each iteration, the product is improved based on the feedback from testing in the previous iteration. If required, the outcome of each phase is analyzed, revised and the next prototype is developed after the design is revised, if pertinent. The products from the first phase are not abandoned, they are revised. Evidently, this model is non-linear in nature.

After the first pass through the checkpoint, we can conclude that the work so far is adequate, but not final. The model places emphasis on the iterative process and on the development of standard prototypes at the end of each iteration. At the end of every cycle, we notice the shortcomings from the previous cycle and might end up having to redo all the work in the previous cycle. This proves to be a complete waste of time and effort. All the effort now goes into developing the end point for an older cycle, which makes the model ineffective for the current cycle.

One of the major drawbacks of such a non linear model is that the cost effectiveness and risk analysis cannot be analyzed thoroughly.

====Why CRC cards are not useful in Waterfall and Spiral Models====

The strength of OO model depends on the idea that, here, design and deployment come together. In the case of a spiral model, this works to make the spiral tighter. Since the waterfall model places over importance on deliverables and user involvement is minimal, which is one of the key focuses of OO SLDCs using CRC cards, the model is considered ineffective. The Spiral model involves multiple revisions of the same idea. When a set of cards have been developed, it would make sense to refine the idea presented in the card but not to redefine them over and over, which may be the case. This does not serve the purpose of actually convening a CRC discussion among the team to draw up cards corresponding to the user requirement. Moreover, in the case of the Spiral model, we would need to convene multiple such meetings at each iteration, which would drastically bring down the overall productivity of the team.

==CRC Cards in Software Development Process==

===Agile Methodology and CRC Cards===

Agile development is a model that has resurfaced and is gaining fame for its incremental cum iterative process. The iteration is carried over the processes of discovery, analysis, design and coding. In each iteration, the old model is worked on in each of the overlapping mini-cycles. The overlap of the cycles makes the process apparently iterative in nature. The model is considered incremental since every step acts as a value-add and this is emphasized by the capacity of classes for reuse. The idea that each phase is repeated ensures that the project is constantly working on a higher level of understanding. Moreover, the OOPS concept of reuse can be used to our advantage such that when we are continuously using OO development models in all our projects, the next implementation can be started far ahead in the SDLC.

The model focuses on analysis and design phase predominantly. Within each of these are mini phases of analysis->prototype->revision-> implementation cycles. The advantage of this model compared to other models described is that, being incremental, this also results in tightening of the spiral at the end of each iteration using concepts such as reusability and polymorphism. Thus, the progression from one point to another in the cycle is seamless from start to deployment.

CRC cards can be very effectively and efficiently used in the Agile model of OO SDLC owing to the fact that it is incremental as well as iterative and not just a repetitive process. Thus, we would not have to redefine the cards from the scratch at any point. Being incremental, we would refine our current model and proceed to refine the entire system as a whole at the end of all iterations. We would essentially be adding value to the cards written out in the previous cycle and if perfected, would never have to discard cards from any of the precious cycles.

Agile also practices active customer involvement. In every phase, the user is involved. This is one of the key characteristics of the CRC card design method. This not only ensures that the final product is as per the customer's requirements, but also that the customer is thoroughly satisfied, since they are aware of the changes and increments at each level. Another key aspect of Agile methodology is that it is feature driven. A CRC card holds details as to the feature of each class and how it collaborates with the rest of the system. Since this information is readily available to the developer and is highly fine-tuned by the end of the SDLC process, the cards can guarantee focus on 80/20 principle (i.e. pay more attention to 20% of the features which will used 80% of the times).

The power of CRC cards for OOP development is in the group session that employs them. The use of CRC cards is an excellent way for people to begin to grasp the underlying idea of object oriented approach. CRC cards are used in a few steps of the software development process such as Analysis and Design.

===CRC Cards for Analysis===

CRC cards and CRC card sessions are good at organizing and spreading domain knowledge in the analysis phase. When building an object–oriented application, the focus of the CRC card sessions is on analyzing and describing the problem. In this phase, the group identifies the objects that are relevant to the application. Before going to the CRC card session, the team must be aware of the domain classes and frameworks that exist to help them model the problem. During the session, they can decide if the existing ones can be used for the new application.

'''Advantages of using CRC cards in Analysis phase:'''

* People from all phases of the project are involved in the card sessions for problem modeling. The names of the classes and responsibilities are created, argued and agreed upon by the team members at the start itself in order to avoid conflicts later. This gives rise to common project and product vocabulary across different roles.

* Domain knowledge already known is shared in the sessions. Also, missing domain knowledge is identified.

* Role plays are conducted during these sessions that help spread knowledge about OO concepts.

* These sessions can be used to create a live prototype of what the application is supposed to do. This can be shown to clients as well so that the team receives feedback on their understanding of the requirements.

* A CRC card session will help the team walk through the requirements and identify any ambiguities.

At the end of the analysis phase, the CRC elements that will be available are:

* '''Classes:''' The classes identified in this phase directly reflect the concepts of the application that is being analyzed. It may not be modeled in terms of software system but it is useful in describing how the application works. However, at this stage the distinction between objects and classes may not be clear.

* '''Responsibilities:''' The responsibilities that are assigned to the classes in this phase are of relatively higher level.

===CRC Cards for Design===

During the CRC cards design sessions, other relevant classes are added, if any. "While an analysis must reflect the real world of the user, the design must reflect the real world of the implementers."[5] A CRC card tool may be helpful for saving, illustrating and documenting a design.

'''Advantages of using CRC cards in Design phase:'''

* These sessions help the team members concentrate on taking the design decisions for the application. These design decisions also include performance, efficiency and other constraints.

* By walking through the scenarios that were seen during the analysis phase, the implementers can give the testers an overview of how the application should work.

* Using CRC cards forces decision to be made up front in front of the team, thus any conflicts can be resolved right there.

* Design constraints such as target environment, language, UI, performance etc., can be discussed during these sessions to check if the design can be implemented.

==Summary==
Software for CRC cards are immensely helpful in designing and modeling software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.

==See Also==
*[http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language(UML)]
*[http://en.wikipedia.org/wiki/Agile_Modeling Agile Modelling]
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]

==References==
[1] [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking]

[2] [http://www.extremeprogramming.org/rules/crccards.html CRC Cards]

[3] [http://www.extremeprogramming.org/example/crcsim.html A Simulator for Coffee Maker]

[4] [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html CRC Card for ATM]

[5] "Using CRC Cards: An Informal Approach to Object-Oriented Development" by Nancy M.Wilkinson

[6] [http://books.google.com/books?id=SGOyQai2TboC&printsec=frontcover&dq=CRC+card+book&hl=en&ei=xSOaTKSaNISclgfRqtkK&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDYQ6AEwAA#v=onepage&q&f=false The CRC card book] by David Bellin, Susan Suchman Simone

==External Links==
* [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking] by Ward Cunningham and Kent Beck
* [http://www.agilemodeling.com/artifacts/crcModel.htm Modelling CRC Cards]
* [http://www.excelsoftware.com/quickcrcwin.html Quick CRC]
* [http://www.indicthreads.com/1439/quick-introduction-to-agile-software-development Quick Introduction to Agile Software Development]

CSC/ECE 517 Fall 2012/ch1 1w11 ap

2012-09-15T03:21:45Z

Asridha2:

==Introduction==
 CRC Cards, also known as [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card Class-Responsibility-Collaboration ] cards are a brainstorming tool to enable collaboration across different teams or individuals in contribution to design, usually used in Object Oriented Software development. This was proposed by Ward Cunningham and Kent Beck[http://c2.com/doc/oopsla89/paper.html]. The CRC card can be viewed as an index card, with the following details:
[[Image:crc-card.gif|frame|right|CRC Card Structure]]

:* The Top of the card usually bears the name of the class.
:* The Left side of the card has the responsibilities of the class.
:* The Right side of the card has the collaborating classes corresponding to each of the responsibilities listed in the left side.

Thus in general, a CRC session can be viewed as the interaction between a set of collaborating classes for a particular [http://en.wikipedia.org/wiki/Use_case Use case]. According to [http://www.extremeprogramming.org/rules/crccards.html]A CRC session proceeds with someone simulating the system by talking about which objects send messages to other objects. By stepping through the process' weaknesses and problems are easily uncovered. Design alternatives can be explored quickly by simulating the design being proposed.

===A CRC Example===
To better understand how the CRC cards work together, let us consider a simple student enrollment problem,where we are required to model the students enrolled in different courses. We can easily define the Student CRC Card as having attributes such as student name, student id and responsibilities that enable a student to enroll in a course or drop the course. In this particular instance, the collaborating class would be the Course class. The Course CRC Card can in turn be visualized as having its own responsibilities, such as having attributes like Course id, course name and the collaborating class would be the Instructor
class. The CRC cards for the Student class and the Course Class are shown below. 
[[Image:Stud_enr_Crc.jpg|frame|center|Student and Course CRC Card]]
 
There are also several practical designs that use the CRC card model to design Object oriented software design. The [http://www.extremeprogramming.org/example/crcsim.html Simulator for Coffee Maker] explores an [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] approach combined with CRC card technique to come up with a design for the coffee maker.

Another interesting approach using CRC cards is the design for the [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html ATM Machine]

===Advantages of CRC cards===
There are a few advantages of CRC cards that make it a preferable model in many designs. Some of the advantages of the CRC card design method are
 
:* CRC cards can allow designers to easily make audience understand a very complex system. In essence it allows for building more complex designs by slowly building the interactions between the collaborating classes, one by one.
:* CRC cards are a simple technique and it can be easily used by anyone with very little training and does not require any expensive computing resources(a board or a paper and a pen would suffice).
:* CRC is fundamentally a brainstorming tool, enabling different people in a team to come up with the design by collaborating, enabling everyone in the team to contribute
:* CRC can be used with other formal object oriented design methodologies such as [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] (an [http://en.wikipedia.org/wiki/Agile_Modeling Agile] development Technique) and can be used along with modeling languages such as [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language(UML)]

==Software for CRC Cards==
CRC cards have limited scope. If we go about designing a huge project, the scope spans many classes and interactions between them. The tedious task here is to maintain the CRC cards and properly formulate interaction between them.
We need software for CRC Cards for the following reasons:
:* Designing Scenario: A scenario represents series of steps in which classes and objects communicate. There can be references to other cards or scenarios.
:* Modeling : Software provides an easy way to segregate cards and objects into different diagrams. Thus we can model our problem with different functionality very easily.
:* Simulation : Software can provide simulation of the design. This might include single-stepping a scenario forwards/backwards or jumping to a specific location in the scenario stack of a multiple scenario simulation
:* Synchronization and Dependencies: Software can maintain relationships between cards, scenarios as design changes take place. If a card references other cards or classes, those cards are generated automatically. Also any name changes and cross references between objects are instantly updated.
:* Revision history and Version Control : Software for CRC cards supports changes to CRC cards. It is easy to model and keep track of all changes to a CRC card. This is extremely helpful in tracking the design changes in CRC cards.

==Designing Software==
The steps to design software for CRC cards are:

*Create CRC Cards : A CRC model is usually created by an individual or small group of designers during the early phase of an object-oriented development project.The figure shows the design of hierarchy of classes. These set of class used for drawing objects are shown. We can see TShape class has a superclass called TObject and two subclasses, TBox and TCircle. Lets assume we create new class TWindow derived from the superclass TObject. [[Image:Design.png|thumb|Description]]

*Assign Responsibilities : Once a set of classes are defined, behaviors can be assigned that will provide the functions of the application. For example, the TShape card has responsibilities ''Initialize'' to create it and ''Draw'' to illustrate it on the diagram.

*Add Attributes : Attributes of classes may also be identified in a CRC Card.The TShape class has attributes fPosition, fType and fSelected.

*Define and simulate Scenario : A scenario describes a sequence of steps in the design using the responsibilities of a group of collaborating classes. Collaboration between classes refers to a client object that uses a responsibility performed by a server object. Often a class must call upon several collaborating classes to implement one of its responsibilities.A scenario describes what happens in the system from a high-level, user's point of view.
[[Image:Scenario.png|thumb|Description]]

Consider situation to the right. We have defined two CRC cards with their responsibility. A scenario defines several steps. Each step in a scenario has a Client, Server and Responsibility field. For each step, a client class uses a responsibility of a server class

The Open Document scenario in the picture references the Initialize Document sub-scenario by specifying its server class ''Document'' in the server field and its scenario name in the Responsibility field. The first step in the Initialize Document sub-scenario uses ''Document'' as the server class name. By single-stepping forwards, backwards or through each sub-scenario, bugs in the design can be identified and corrected early.

*Partition the Design : As the number of CRC cards in the design grow, they can be grouped by function. By using Software for CRC cards,we can draw separate diagrams to partition the model into different subject areas.

*Inheritance Graph : An automated tool can generate an inheritance graph from information on CRC cards. This diagram can concisely illustrate the big picture of a large project that might contain hundreds of classes and dozens of diagrams.

*Verify Your Work : Creating and simulating scenarios will help verify that a design is correct and complete. A CRC software can perform other error checks to locate design problems. For example, responsibilities that are not used in any scenarios may indicate that the design is incomplete or perhaps the responsibility isn't needed. Likewise, a card that is not used by any collaboration may not be needed.

==Software Development Process for Object Oriented Development==

Software Development Life Cycles are different for a standard development process and for Object Oriented development. This difference needs to be understood in order to know how to meet the benchmarks set for the project. There are multiple processes that are used in software development, the most common ones in use being Waterfall model and Spiral model. The Waterfall model is progression based and the Spiral model is iterative.

We need to understand that the uniqueness of Object Oriented SDLCs comes from the fact that it is more user centric as compared to standard SDLCs that are more system centric. We will now see which models work for Object Oriented SDLCs (OO SDLCs) and which don’t. CRC cards play a very important role in an Object Oriented SDLC. Thus, figuring out which models work well for OO SDLCs will result in understanding which models use CRC cards and why.

====The Waterfall Model====

The Waterfall model is implemented in multiple phases with each phase having a clear demarcation in terms of its functionality and deliverable. It uses clear stepping stones to come up with deliverables for each deadline. In this case, there are multiple ways to measure progress and methods by which to audit internally and apply checkpoints.

The downside of the Waterfall model lies in the fact that it is a very rigid model that does not offer much in terms of leeway when it comes to deliverables and what each phase in the cycle has to offer. The process is also overly mechanical and over time, just ends up being boring.

Owing to the emphasis on checkpoints and deliverables with strict deadlines, in most cases the analysis and design phases are usually cut short and thus, the project may veer very far from reality. The users are involved only in the requirement gathering phase. This might result in mistranslation of the requirements of the user into what may be an amazing final product but something that the user did not even ask for.

====The Spiral Model====
This model iteratively goes through the phases of analysis, design, prototyping and testing after the initial requirements gathering phase. With each iteration, the product is improved based on the feedback from testing in the previous iteration. If required, the outcome of each phase is analyzed, revised and the next prototype is developed after the design is revised, if pertinent. The products from the first phase are not abandoned, they are revised. Evidently, this model is non-linear in nature.

After the first pass through the checkpoint, we can conclude that the work so far is adequate, but not final. The model places emphasis on the iterative process and on the development of standard prototypes at the end of each iteration. At the end of every cycle, we notice the shortcomings from the previous cycle and might end up having to redo all the work in the previous cycle. This proves to be a complete waste of time and effort. All the effort now goes into developing the end point for an older cycle, which makes the model ineffective for the current cycle.

One of the major drawbacks of such a non linear model is that the cost effectiveness and risk analysis cannot be analyzed thoroughly.

====Why CRC cards are not useful in Waterfall and Spiral Models====

The strength of OO model depends on the idea that, here, design and deployment come together. In the case of a spiral model, this works to make the spiral tighter. Since the waterfall model places over importance on deliverables and user involvement is minimal, which is one of the key focuses of OO SLDCs using CRC cards, the model is considered ineffective. The Spiral model involves multiple revisions of the same idea. When a set of cards have been developed, it would make sense to refine the idea presented in the card but not to redefine them over and over, which may be the case. This does not serve the purpose of actually convening a CRC discussion among the team to draw up cards corresponding to the user requirement. Moreover, in the case of the Spiral model, we would need to convene multiple such meetings at each iteration, which would drastically bring down the overall productivity of the team.

==CRC Cards in Software Development Process==

===Agile Methodology and CRC Cards===

Agile development is a model that has resurfaced and is gaining fame for its incremental cum iterative process. The iteration is carried over the processes of discovery, analysis, design and coding. In each iteration, the old model is worked on in each of the overlapping mini-cycles. The overlap of the cycles makes the process apparently iterative in nature. The model is considered incremental since every step acts as a value-add and this is emphasized by the capacity of classes for reuse. The idea that each phase is repeated ensures that the project is constantly working on a higher level of understanding. Moreover, the OOPS concept of reuse can be used to our advantage such that when we are continuously using OO development models in all our projects, the next implementation can be started far ahead in the SDLC.

The model focuses on analysis and design phase predominantly. Within each of these are mini phases of analysis->prototype->revision-> implementation cycles. The advantage of this model compared to other models described is that, being incremental, this also results in tightening of the spiral at the end of each iteration using concepts such as reusability and polymorphism. Thus, the progression from one point to another in the cycle is seamless from start to deployment.

CRC cards can be very effectively and efficiently used in the Agile model of OO SDLC owing to the fact that it is incremental as well as iterative and not just a repetitive process. Thus, we would not have to redefine the cards from the scratch at any point. Being incremental, we would refine our current model and proceed to refine the entire system as a whole at the end of all iterations. We would essentially be adding value to the cards written out in the previous cycle and if perfected, would never have to discard cards from any of the precious cycles.

Agile also practices active customer involvement. In every phase, the user is involved. This is one of the key characteristics of the CRC card design method. This not only ensures that the final product is as per the customer's requirements, but also that the customer is thoroughly satisfied, since they are aware of the changes and increments at each level. Another key aspect of Agile methodology is that it is feature driven. A CRC card holds details as to the feature of each class and how it collaborates with the rest of the system. Since this information is readily available to the developer and is highly fine-tuned by the end of the SDLC process, the cards can guarantee focus on 80/20 principle (i.e. pay more attention to 20% of the features which will used 80% of the times).

The power of CRC cards for OOP development is in the group session that employs them. The use of CRC cards is an excellent way for people to begin to grasp the underlying idea of object oriented approach. CRC cards are used in a few steps of the software development process such as Analysis and Design.

===CRC Cards for Analysis===

CRC cards and CRC card sessions are good at organizing and spreading domain knowledge in the analysis phase. When building an object–oriented application, the focus of the CRC card sessions is on analyzing and describing the problem. In this phase, the group identifies the objects that are relevant to the application. Before going to the CRC card session, the team must be aware of the domain classes and frameworks that exist to help them model the problem. During the session, they can decide if the existing ones can be used for the new application.

'''Advantages of using CRC cards in Analysis phase:'''

* People from all phases of the project are involved in the card sessions for problem modeling. The names of the classes and responsibilities are created, argued and agreed upon by the team members at the start itself in order to avoid conflicts later. This gives rise to common project and product vocabulary across different roles.

* Domain knowledge already known is shared in the sessions. Also, missing domain knowledge is identified.

* Role plays are conducted during these sessions that help spread knowledge about OO concepts.

* These sessions can be used to create a live prototype of what the application is supposed to do. This can be shown to clients as well so that the team receives feedback on their understanding of the requirements.

* A CRC card session will help the team walk through the requirements and identify any ambiguities.

At the end of the analysis phase, the CRC elements that will be available are:

* '''Classes:''' The classes identified in this phase directly reflect the concepts of the application that is being analyzed. It may not be modeled in terms of software system but it is useful in describing how the application works. However, at this stage the distinction between objects and classes may not be clear.

* '''Responsibilities:''' The responsibilities that are assigned to the classes in this phase are of relatively higher level.

===CRC Cards for Design===

During the CRC cards design sessions, other relevant classes are added, if any. "While an analysis must reflect the real world of the user, the design must reflect the real world of the implementers."[5] A CRC card tool may be helpful for saving, illustrating and documenting a design.

'''Advantages of using CRC cards in Design phase:'''

* These sessions help the team members concentrate on taking the design decisions for the application. These design decisions also include performance, efficiency and other constraints.

* By walking through the scenarios that were seen during the analysis phase, the implementers can give the testers an overview of how the application should work.

* Using CRC cards forces decision to be made up front in front of the team, thus any conflicts can be resolved right there.

* Design constraints such as target environment, language, UI, performance etc., can be discussed during these sessions to check if the design can be implemented.

==Summary==
Software for CRC cards are immensely helpful in designing and modeling software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.

==See Also==
*[http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language(UML)]
*[http://en.wikipedia.org/wiki/Agile_Modeling Agile Modelling]
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]

==References==
[1] [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking]

[2] [http://www.extremeprogramming.org/rules/crccards.html CRC Cards]

[3] [http://www.extremeprogramming.org/example/crcsim.html A Simulator for Coffee Maker]

[4] [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html CRC Card for ATM]

[5] "Using CRC Cards: An Informal Approach to Object-Oriented Development" by Nancy M.Wilkinson

==External Links==
* [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking] by Ward Cunningham and Kent Beck
* [http://books.google.com/books?id=SGOyQai2TboC&printsec=frontcover&dq=CRC+card+book&hl=en&ei=xSOaTKSaNISclgfRqtkK&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDYQ6AEwAA#v=onepage&q&f=false The CRC card book] by David Bellin, Susan Suchman Simone

* [http://www.agilemodeling.com/artifacts/crcModel.htm Modelling CRC Cards]
* [http://www.excelsoftware.com/quickcrcwin.html Quick CRC]

CSC/ECE 517 Fall 2012

2012-09-15T00:03:05Z

Asridha2:

*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]

CSC/ECE 517 Fall 2012/ch1 1w11 ap

2012-09-15T00:02:11Z

Asridha2: Created page with "==Introduction== CRC Cards also known as [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card Class-Responsibility-Collaboration ] ca..."

==Introduction==
 CRC Cards also known as [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card Class-Responsibility-Collaboration ] cards are a brainstorming tool to enable collaboration across different teams or individuals in contribution to design, usually used in Object Oriented Software development. This was proposed by Ward Cunningham and Kent Beck[http://c2.com/doc/oopsla89/paper.html]. The CRC card can be viewed as an index card, with the following details:
[[Image:crc-card.gif|frame|right|CRC Card Structure]]

:* The Top of the card usually bears the name of the class.
:* The Left side of the card has the responsibilities of the class.
:* The Right side of the card has the collaborating classes corresponding to each of the responsibilities listed in the left side.

Thus in general, a CRC session can be viewed as the interaction between a set of collaborating classes for a particular [http://en.wikipedia.org/wiki/Use_case Use case]. According to [http://www.extremeprogramming.org/rules/crccards.html]A CRC session proceeds with someone simulating the system by talking about which objects send messages to other objects. By stepping through the process weaknesses and problems are easily uncovered. Design alternatives can be explored quickly by simulating the design being proposed.

===A CRC Example===
To better understand how the CRC cards work together, let us consider a simple student enrollment problem,where we are required to model the students enrolled in different courses. We can easily define the Student CRC Card as having attributes such as student name, student id and responsibilities that enable a student to enroll in a course or drop the course. In this particular instance, the collaborating class would be the Course class. The Course CRC Card can in turn be visualized as having its own responsibilities, such as having attributes like Course Id, course name and the collaborating class would be the Instructor
class. The CRC cards for the Student class and the Course Class are shown below. 
[[Image:Stud_enr_Crc.jpg|frame|center|Student and Course CRC Card]]
 
There are also several practical designs that use the CRC card model to design Object oriented software design. The [http://www.extremeprogramming.org/example/crcsim.html Simulator for Coffee Maker] explores an [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] approach combined with CRC card technique to come up with a design for the coffee maker.

Another interesting approach using CRC cards explores a design for the [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html ATM Machine]

===Advantages of CRC cards===
There are quite a few advantages of CRC cards that make it a preferable model in many designs. Some of the advantages of the CRC card design method are
 
:* CRC cards can allow designers to easily make audience understand a very complex system. In essence it allows for building more complex designs by slowly building the interactions between the collaborating classes, one by one.
:* CRC cards are a simple technique and it can be easily used by anyone with very little training and does not require any expensive computing resources(a board or a paper and a pen would suffice).
:* CRC is fundamentally a brainstorming tool, enabling different people in a team to come up with the design by collaborating, enabling everyone in the team to contribute
:* CRC can be used with other formal object oriented design methodologies such as [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] (an [http://en.wikipedia.org/wiki/Agile_Modeling Agile] development Technique) and can be used along with modelling languages such as [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language(UML)]

==Why need a Software for CRC Cards==
CRC cards are limited by their scope. If we go about designing a huge project, the scope spans many classes and interactions between them. The tedious task of maintaining are CRC cards and to properly formulate interaction can get overwhelming.
Following reasons propel use for software for CRC Cards :
:* Designing Scenario: A scenario represents series of steps in which classes and objects communicate. There are be references to other cards or scenarios.
:* Modeling : Software provide an easy way to segregate cards and objects into different diagrams. Thus we can model our software with different functionality very easily.
:* Simulation : Software can provides simulation of an software design. This might include single stepping backwards, forwards a scenario or jumping to a specific location in the scenario stack of a multiple scenario simulation
:* Synchronization and Dependencies: Software can maintain relationships between cards, scenarios as design changes take place. If a card references other cards or classes, those cards are generated automatically. Also any name changes and cross references between objects are instantly updated.
:* Revision history and Version Control : Software for CRC cards supports changes to CRC cards. It is easy to model and keep track of all changes to a CRC cards. This is extremely helpful in realizing the design changes to CRC cards.

==Desining Software==
The following steps proceed while designing Software for CRC cards:

*Create CRC Cards
A CRC model is usually created by an individual or small group of designers during the early phase of an object-oriented development project.The figure shows the design of hierarchy of classes. These set of class used for drawing objects are shown. We can see TShape class has a superclass called TObject and two subclasses, TBox and TCircle. Lets assume we create new class TWindow derived from the superclass TObject. [[Image:Design.png|thumb|Description]]

*Assign Responsibilities

Once a set of classes are defined, behaviors can be assigned that will provide the functions of the application. For example, the TShape card has responsibilities Initialize to create it and Draw to illustrate it on the diagram.

*Add Attributes

Attributes of classes may also be identified in a CRC Card.The TShape class has attributes fPosition, fType and
fSelected.

*Define and simulate Scenario

A scenario describes a sequence of steps in the design using the responsibilities of a group of collaborating
classes. Collaboration between classes refers to a client object that uses a responsibility performed
by a server object. Often a class must call upon several collaborating classes to implement one of its
responsibilities.A scenario describes what happens in the system from a high-level, user point of view.
[[Image:Scenario.png|thumb|Description]]
Consider situation to the right. We have defined two CRC cards with their responsibility. A scenario deinfes several steps. Each step in a scenario has a Client, Server and Responsibility field. For each step,
a client class uses a responsibility of a server class

The Open Document scenario in the picture references the Initialize Document subscenario
by specifying its server class Document in the server field and its scenario name in the Responsibility field.
The first step in the Initialize Document subscenario uses Document as the server class name.

By single stepping forwards, backwards or through each subscenario, bugs in the design can be identified and corrected early.

*Partition the Design
As the number of CRC cards in the design grows, they can be grouped by function. Using Software for CRC cards,
separate diagrams are used to partition the model into different subject areas.

*Inheritance Graph
An automated tool can generate an inheritance graph from information on CRC cards. This diagram can
concisely illustrate the big picture of a large project that might contain hundreds of classes and dozens of diagrams.

*Verify Your Work 

Creating and simulating scenarios will help verify that a design is correct and complete. A CRC software
can perform other error checks to locate design problems.
For example, responsibilities that are not used in any scenarios may indicate that the design is incomplete
or perhaps the responsibility isn't needed.Likewise, a card that is not used by any collaboration
may not be needed.

==Summary==
Software for CRC cards are immensely helpful in designing and modeling Software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.

==See Also==
*[http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language(UML)]
*[http://en.wikipedia.org/wiki/Agile_Modeling Agile Modelling]
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]

==References==
[1] A Laboratory For Teaching Object-Oriented Thinking: [http://c2.com/doc/oopsla89/paper.html http://c2.com/doc/oopsla89/paper.html]

[2] CRC Cards: [http://www.extremeprogramming.org/rules/crccards.html http://www.extremeprogramming.org/rules/crccards.html]

[3] [http://www.extremeprogramming.org/example/crcsim.html A Simulator for Coffee Maker]

[4] [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html CRC Card for ATM]

==External Links==
* [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking] by Ward Cunningham and Kent Beck
* [http://books.google.com/books?id=SGOyQai2TboC&printsec=frontcover&dq=CRC+card+book&hl=en&ei=xSOaTKSaNISclgfRqtkK&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDYQ6AEwAA#v=onepage&q&f=false The CRC card book] by David Bellin, Susan Suchman Simone

* [http://books.google.com/books?id=baopCOstm_kC&pg=PA29&lpg=PA29&dq=creating+software+for+CRC+cards&source=bl&ots=hABGQbbmXV&sig=CTHPtCN1GmZEyTAIPWvKE--8-M4&hl=en&ei=7ReaTISDKYL68Aadtq08&sa=X&oi=book_result&ct=result&resnum=9&ved=0CEsQ6AEwCDgK#v=onepage&q&f=false Using CRC Cards: An Informal Approach to Object-Oriented Development]
* [http://www.agilemodeling.com/artifacts/crcModel.htm Modelling CRC Cards]
* [http://www.excelsoftware.com/quickcrcwin.html Quick CRC]

CSC/ECE 517 Fall 2012/ch1 1w19 sa

2012-09-14T23:22:05Z