Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-27T00:34:57Z

Pgjalisa: /* Also see */

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture for a post:

post_one:
title: one
description: post_one_desc
category: category_one

post_two:
title: two
description: post_two_desc
category: category_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category
one, post_one_desc, category_one
two, post_two_desc, category_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

The following example shows how a factory can be defined using Factory Girl:

Factory.define :post do |p|
p.title 'Fixtures and Factories'
p.description 'This a wiki for fixtures and factories'
p.category 'OOLS'
end

=Fixtures vs. Factories=

Fixtures allow known data to be statically pre-loaded into database tables before testing. Factories create only whatever is needed on a case by case basis.

==Fixtures Advantages==

* Easy to view all the data in one place
* Data is truly static
* Simple and clean

==Fixtures Disadvantages==

* Inserting data into the database for each run slows down the testing process
* Introduces dependency on fixture data
* Data customization is more complex
* Fixtures cannot be parameterized

==Factories Advantages==

* Maintains independence of tests
* Better overall performance since data is created only on a per need basis
* Tests and data are well isolated

==Factories Disadvantages==

* Complex relationships might be hard to capture
* Performance might sometimes be degraded, due to the create operations.

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-26T23:09:35Z

Pgjalisa: /* Factories */

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture for a post:

post_one:
title: one
description: post_one_desc
category: category_one

post_two:
title: two
description: post_two_desc
category: category_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category
one, post_one_desc, category_one
two, post_two_desc, category_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

The following example shows how a factory can be defined using Factory Girl:

Factory.define :post do |p|
p.title 'Fixtures and Factories'
p.description 'This a wiki for fixtures and factories'
p.category 'OOLS'
end

=Fixtures vs. Factories=

==Fixtures Advantages==

==Fixtures Disadvantages==

==Factories Advantages==

==Factories Disadvantages==

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-26T22:48:17Z

Pgjalisa:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture for a post:

post_one:
title: one
description: post_one_desc
category: category_one

post_two:
title: two
description: post_two_desc
category: category_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category
one, post_one_desc, category_one
two, post_two_desc, category_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

Factory.define :post do |p|
p.title 'Fixtues and Factories'
p.description 'This a wiki for fixtures and factories'
p.category 'OOLS'
end

=Fixtures vs. Factories=

==Fixtures Advantages==

==Fixtures Disadvantages==

==Factories Advantages==

==Factories Disadvantages==

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-26T22:01:39Z

Pgjalisa: /* Factories */

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture:

post_one:
title: one
description: post_one_desc
category: category_one
user: user_one

post_two:
title: two
description: post_two_desc
category: category_two
user: user_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category, user
one, post_one_desc, category_one, user_one
two, post_two_desc, category_two, user_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

Factory.define :user do |u|
u.first_name 'John'
u.last_name 'Doe'
u.admin false
end

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-24T04:43:47Z

Pgjalisa: /* Fixtures */

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture:

post_one:
title: one
description: post_one_desc
category: category_one
user: user_one

post_two:
title: two
description: post_two_desc
category: category_two
user: user_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category, user
one, post_one_desc, category_one, user_one
two, post_two_desc, category_two, user_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem.

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-24T04:43:02Z

Pgjalisa: /* Fixtures */

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:
1. YAML fixtures
2. CSV fixtures
3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture:

post_one:
title: one
description: post_one_desc
category: category_one
user: user_one

post_two:
title: two
description: post_two_desc
category: category_two
user: user_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category, user
one, post_one_desc, category_one, user_one
two, post_two_desc, category_two, user_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem.

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-24T04:27:11Z

Pgjalisa: /* Factories */

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:
1. YAML fixtures
2. CSV fixtures
3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture:

post_one:
title: one
description: post_one_desc
category: category_one
user: user_one

post_two:
title: two
description: post_two_desc
category: category_two
user: user_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category, user
one, post_one_desc, category_one, user_one
two, post_two_desc, category_two, user_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem.

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-24T04:00:33Z

Pgjalisa: /* YAML Fixtures */

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-24T01:09:31Z

Pgjalisa: /* YAML Fixtures */

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T22:18:49Z

Pgjalisa: /* Introduction */

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T22:16:48Z

Pgjalisa: /* Introduction */

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T21:54:02Z

Pgjalisa: /* Introduction */

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T20:08:15Z

Pgjalisa:

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T14:27:29Z

Pgjalisa: /* Factories */

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction to Testing=

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:
1. YAML fixtures
2. CSV fixtures
3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. This file ends with the .yml extension.

The following example shows the format of a YAML fixture:

post_one:
title: one
description: post_one_desc
category: category_one
user: user_one

post_two:
title: two
description: post_two_desc
category: category_two
user: user_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category, user
one, post_one_desc, category_one, user_one
two, post_two_desc, category_two, user_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T07:33:54Z

Pgjalisa: /* Single-file fixtures */

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T07:33:05Z

Pgjalisa: /* Fixtures */

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction to Testing=

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:
1. YAML fixtures
2. CSV fixtures
3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. This file ends with the .yml extension.

The following example shows the format of a YAML fixture:

post_one:
title: one
description: post_one_desc
category: category_one
user: user_one

post_two:
title: two
description: post_two_desc
category: category_two
user: user_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category, user
one, post_one_desc, category_one, user_one
two, post_two_desc, category_two, user_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case.

For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T07:32:11Z

Pgjalisa: /* Fixtures */

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction to Testing=

=Fixtures=
Fixtures are sample data on which all the tests run.

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case.

For example:

# this will return the Hash for the fixture named david
users(:david)

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:
1. YAML fixtures
2. CSV fixtures
3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. This file ends with the .yml extension.

The following example shows the format of a YAML fixture:

post_one:
title: one
description: post_one_desc
category: category_one
user: user_one

post_two:
title: two
description: post_two_desc
category: category_two
user: user_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category, user
one, post_one_desc, category_one, user_one
two, post_two_desc, category_two, user_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

=Factories=

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T07:30:00Z

Pgjalisa: /* YAML Fixtures */

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction to Testing=

=Fixtures=
Fixtures are sample data on which all the tests run. There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:
1. YAML fixtures
2. CSV fixtures
3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. This file ends with the .yml extension.

The following example shows the format of a YAML fixture:

post_one:
title: one
description: post_one_desc
category: category_one
user: user_one

post_two:
title: two
description: post_two_desc
category: category_two
user: user_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category, user
one, post_one_desc, category_one, user_one
two, post_two_desc, category_two, user_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

=Factories=

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T07:29:44Z

Pgjalisa: /* YAML Fixtures */

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction to Testing=

=Fixtures=
Fixtures are sample data on which all the tests run. There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:
1. YAML fixtures
2. CSV fixtures
3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. This file ends with the .yml extension.

The following example shows the format of a YAML fixture:

post_one:
title: one
description: post_one_desc
category: category_one
user: user_one
post_two:
title: two
description: post_two_desc
category: category_two
user: user_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category, user
one, post_one_desc, category_one, user_one
two, post_two_desc, category_two, user_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

=Factories=

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T07:29:22Z

Pgjalisa:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction to Testing=

=Fixtures=
Fixtures are sample data on which all the tests run. There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:
1. YAML fixtures
2. CSV fixtures
3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. This file ends with the .yml extension.

The following example shows the format of a YAML fixture:

post_one:
title: one
description: post_one_desc
category: category_one
user: user_one

post_two:
title: two
description: post_two_desc
category: category_two
user: user_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category, user
one, post_one_desc, category_one, user_one
two, post_two_desc, category_two, user_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

=Factories=

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T07:22:48Z

Pgjalisa:

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T05:36:13Z

Pgjalisa:

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T05:16:33Z

Pgjalisa:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction to Testing=

=Fixtures=
Fixtures are sample data on which all the tests run. There can be 3 types of fixtures[]:
1. YAML fixtures
2. CSV fixtures
3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language. <ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>

==CSV fixtures==

==Single-file fixtures==

=Factories=

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T05:09:55Z

Pgjalisa: /* Fixtures */

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction to Testing=

=Fixtures=
Fixtures are sample data on which all the tests run. There can be 3 types of fixtures[]:
1. YAML fixtures
2. CSV fixtures
3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language.[]

==CSV fixtures==

==Single-file fixtures==

=Factories=

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T04:54:14Z

Pgjalisa:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction to Testing=

=Fixtures=
Fixtures are sample data on which all the tests run. There can be 3 types of fixtures:
1. YAML fixtures
2. CSV fixtures
3. Single-file fixtures

==YAML Fixtures==

==CSV fixtures==

==Single-file fixtures==

=Factories=

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T03:20:03Z

Pgjalisa:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction to Testing=

=Fixtures=

=Factories=

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T03:19:42Z

Pgjalisa:

==<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>==

=Introduction to Testing=

=Fixtures=

=Factories=

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T03:19:20Z

Pgjalisa: /* SaaS - 5.5 - Fixtures and Factories */

=Introduction to Testing=

=Fixtures=

=Factories=

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T03:19:04Z

Pgjalisa:

==<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>==

=Introduction to Testing=

=Fixtures=

=Factories=

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T03:18:26Z

Pgjalisa: /* */

== <big>'''SaaS - 5.5 - Fixtures and Factories'''</big> ==

=Introduction to Testing=

=Fixtures=

=Factories=

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T03:18:05Z

Pgjalisa:

== ==
<big>'''SaaS - 5.5 - Fixtures and Factories'''</big> 

=Introduction to Testing=

=Fixtures=

=Factories=

=References=

=Also see=

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T03:16:23Z

Pgjalisa:

== Fixtures and factories ==

CSC/ECE 517 Fall 2012

2012-10-23T03:15:03Z

Pgjalisa:

*[[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 1w4 aj]]
*[[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/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[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 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w16 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w8 vp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w18 as]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w3 jm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w23 sr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w11_aa]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w15 rr]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w33 pv]]

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-23T03:09:34Z

Pgjalisa: Created page with "Fixtures and factories"

Fixtures and factories

CSC/ECE 517 Fall 2012/ch1 1w11 ap

2012-09-15T03:27:27Z

Pgjalisa: /* Software Development Process for Object Oriented Development */

==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[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:26:13Z

Pgjalisa: /* References */

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

[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:25:51Z

Pgjalisa: /* External Links */

==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://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:25:18Z

Pgjalisa: /* External Links */

==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://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]

CSC/ECE 517 Fall 2012/ch1 1w11 ap

2012-09-15T03:25:04Z

Pgjalisa: /* External Links */

==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://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/]

CSC/ECE 517 Fall 2012/ch1 1w11 ap

2012-09-15T03:18:44Z

Pgjalisa: /* Agile Methodology and 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 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 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/ch1 1w11 ap

2012-09-15T03:17:55Z

Pgjalisa: /* Why Waterfall and Spiral Models are not useful */

==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 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 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/ch1 1w11 ap

2012-09-15T03:03:47Z

Pgjalisa: /* Why Waterfall and Spiral Models are not useful */

==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 Waterfall and Spiral Models are not useful====

The strength of OO model depends on the idea that 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 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/ch1 1w11 ap

2012-09-15T03:03:32Z

Pgjalisa: /* CRC Cards in Software Development Process */

==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 Waterfall and Spiral Models are not useful====

The strength of OO model depends on the idea that 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 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/ch1 1w11 ap

2012-09-15T03:00:53Z

Pgjalisa: /* Why Waterfall and Spiral Models are not useful */

==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 Waterfall and Spiral Models are not useful====

The strength of OO model depends on the idea that 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==

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/ch1 1w11 ap

2012-09-15T03:00:26Z

Pgjalisa: /* CRC Cards in Software Development Process */

==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 Waterfall and Spiral Models are not useful====

The strength of OO model depends on the idea that 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.

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/ch1 1w11 ap

2012-09-15T03:00:11Z

Pgjalisa: /* CRC Cards in Software Development Process */

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

==CRC Cards in Software Development Process==

==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 Waterfall and Spiral Models are not useful====

The strength of OO model depends on the idea that 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.

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/ch1 1w11 ap

2012-09-15T02:55:47Z

Pgjalisa: /* CRC Cards in Software Development Process */

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

==CRC Cards in Software Development Process==

===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 Waterfall and Spiral Models are not useful====
The strength of OO model depends on the idea that 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.

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/ch1 1w11 ap

2012-09-15T02:51:16Z

Pgjalisa: /* CRC Cards in Software Development */

CSC/ECE 517 Fall 2012/ch1 1w11 ap

2012-09-15T02:44:32Z

Pgjalisa: /* Summary */

CSC/ECE 517 Fall 2012/ch1 1w11 ap

2012-09-15T02:41:32Z

Pgjalisa: /* CRC Cards in Software Development */