Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T03:18:34Z

Dragon9786: /* Service Lookup */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Closed Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
The '''Data Driver design''' covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

''In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.'' [3]

== Service Lookup ==

The '''Service Lookup''' technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure. From the figure we can also see how the responsibilities are seperated and how a change can be implemented without affecting the client (or multiple clients if more than one is involved).

[[Image:Service_Lookup.jpg|frame|center]]

== Interpreter-Driven Design ==
'''Interpreter-driven designs''' are design principles that some kind of interpreters which uses internal rules that read from an external source and execute them. The external sources could be script or language interpreters that read and run programs, virtual machines, neural network engines that execute nets, constraint logic engines that read and reason with constraint sets.

The advantage of this design approach is that we can write logic expressions externally to influence a system. Because the whole logic is externalized, the system is protected from the changes to the logic.

== Reflective or Meta-Level Designs ==
'''Reflective or Meta-Level Designs''' is also a special case of data driven designs. In [2], the ''java.beans.Introspector'' example is used to explain this design principle. To obtain a Bean-Info object in java using this, the getter method of the corresponding property is first called (i.e. ''getX() for a property X'') and then calling the ''Method.invoke.Reflective algorithms''. These use '''introspection''' and '''metalanguage''' services to protect the system from the impact of logic or external code variations.

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =
*[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 '''Design Pattern''']
*[http://en.wikipedia.org/wiki/Delegation_pattern '''Delegation Pattern''']
*[http://en.wikipedia.org/wiki/Open_Closed_Principle '''Open-Closed Principle''']

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T03:18:23Z

Dragon9786: /* Data Driven Design */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Closed Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
The '''Data Driver design''' covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

''In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.'' [3]

== Service Lookup ==

The Service Lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure. From the figure we can also see how the responsibilities are seperated and how a change can be implemented without affecting the client (or multiple clients if more than one is involved).

[[Image:Service_Lookup.jpg|frame|center]]

== Interpreter-Driven Design ==
'''Interpreter-driven designs''' are design principles that some kind of interpreters which uses internal rules that read from an external source and execute them. The external sources could be script or language interpreters that read and run programs, virtual machines, neural network engines that execute nets, constraint logic engines that read and reason with constraint sets.

The advantage of this design approach is that we can write logic expressions externally to influence a system. Because the whole logic is externalized, the system is protected from the changes to the logic.

== Reflective or Meta-Level Designs ==
'''Reflective or Meta-Level Designs''' is also a special case of data driven designs. In [2], the ''java.beans.Introspector'' example is used to explain this design principle. To obtain a Bean-Info object in java using this, the getter method of the corresponding property is first called (i.e. ''getX() for a property X'') and then calling the ''Method.invoke.Reflective algorithms''. These use '''introspection''' and '''metalanguage''' services to protect the system from the impact of logic or external code variations.

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =
*[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 '''Design Pattern''']
*[http://en.wikipedia.org/wiki/Delegation_pattern '''Delegation Pattern''']
*[http://en.wikipedia.org/wiki/Open_Closed_Principle '''Open-Closed Principle''']

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T03:17:34Z

Dragon9786: /* Reflective or Meta-Level Designs */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Closed Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

''In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.'' [3]

== Service Lookup ==

The Service Lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure. From the figure we can also see how the responsibilities are seperated and how a change can be implemented without affecting the client (or multiple clients if more than one is involved).

[[Image:Service_Lookup.jpg|frame|center]]

== Interpreter-Driven Design ==
'''Interpreter-driven designs''' are design principles that some kind of interpreters which uses internal rules that read from an external source and execute them. The external sources could be script or language interpreters that read and run programs, virtual machines, neural network engines that execute nets, constraint logic engines that read and reason with constraint sets.

The advantage of this design approach is that we can write logic expressions externally to influence a system. Because the whole logic is externalized, the system is protected from the changes to the logic.

== Reflective or Meta-Level Designs ==
'''Reflective or Meta-Level Designs''' is also a special case of data driven designs. In [2], the ''java.beans.Introspector'' example is used to explain this design principle. To obtain a Bean-Info object in java using this, the getter method of the corresponding property is first called (i.e. ''getX() for a property X'') and then calling the ''Method.invoke.Reflective algorithms''. These use '''introspection''' and '''metalanguage''' services to protect the system from the impact of logic or external code variations.

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =
*[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 '''Design Pattern''']
*[http://en.wikipedia.org/wiki/Delegation_pattern '''Delegation Pattern''']
*[http://en.wikipedia.org/wiki/Open_Closed_Principle '''Open-Closed Principle''']

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T03:10:14Z

Dragon9786: /* Interpreter-Driven Design */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Closed Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

''In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.'' [3]

== Service Lookup ==

The Service Lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure. From the figure we can also see how the responsibilities are seperated and how a change can be implemented without affecting the client (or multiple clients if more than one is involved).

[[Image:Service_Lookup.jpg|frame|center]]

== Interpreter-Driven Design ==
'''Interpreter-driven designs''' are design principles that some kind of interpreters which uses internal rules that read from an external source and execute them. The external sources could be script or language interpreters that read and run programs, virtual machines, neural network engines that execute nets, constraint logic engines that read and reason with constraint sets.

The advantage of this design approach is that we can write logic expressions externally to influence a system. Because the whole logic is externalized, the system is protected from the changes to the logic.

== Reflective or Meta-Level Designs ==
Reflective or Meta-Level Designs is also a special case of data driven designs.

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =
*[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 '''Design Pattern''']
*[http://en.wikipedia.org/wiki/Delegation_pattern '''Delegation Pattern''']
*[http://en.wikipedia.org/wiki/Open_Closed_Principle '''Open-Closed Principle''']

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T03:09:58Z

Dragon9786: /* Reflective or Meta-Level Designs */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Closed Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

''In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.'' [3]

== Service Lookup ==

The Service Lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure. From the figure we can also see how the responsibilities are seperated and how a change can be implemented without affecting the client (or multiple clients if more than one is involved).

[[Image:Service_Lookup.jpg|frame|center]]

== Interpreter-Driven Design ==
Interpreter-driven designs are design principles that some kind of interpreters which uses internal rules that read from an external source and execute them. The external sources could be script or language interpreters that read and run programs, virtual machines, neural network engines that execute nets, constraint logic engines that read and reason with constraint sets.

The advantage of this design approach is that we can write logic expressions externally to influence a system. Because the whole logic is externalized, the system is protected from the changes to the logic.

== Reflective or Meta-Level Designs ==
Reflective or Meta-Level Designs is also a special case of data driven designs.

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =
*[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 '''Design Pattern''']
*[http://en.wikipedia.org/wiki/Delegation_pattern '''Delegation Pattern''']
*[http://en.wikipedia.org/wiki/Open_Closed_Principle '''Open-Closed Principle''']

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T03:07:38Z

Dragon9786: /* Interpreter-Driven Design */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Closed Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

''In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.'' [3]

== Service Lookup ==

The Service Lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure. From the figure we can also see how the responsibilities are seperated and how a change can be implemented without affecting the client (or multiple clients if more than one is involved).

[[Image:Service_Lookup.jpg|frame|center]]

== Interpreter-Driven Design ==
Interpreter-driven designs are design principles that some kind of interpreters which uses internal rules that read from an external source and execute them. The external sources could be script or language interpreters that read and run programs, virtual machines, neural network engines that execute nets, constraint logic engines that read and reason with constraint sets.

The advantage of this design approach is that we can write logic expressions externally to influence a system. Because the whole logic is externalized, the system is protected from the changes to the logic.

== Reflective or Meta-Level Designs ==

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =
*[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 '''Design Pattern''']
*[http://en.wikipedia.org/wiki/Delegation_pattern '''Delegation Pattern''']
*[http://en.wikipedia.org/wiki/Open_Closed_Principle '''Open-Closed Principle''']

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:48:14Z

Dragon9786: /* See Also */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Closed Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

''In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.'' [3]

== Service Lookup ==

The Service Lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure. From the figure we can also see how the responsibilities are seperated and how a change can be implemented without affecting the client (or multiple clients if more than one is involved).

[[Image:Service_Lookup.jpg|frame|center]]

== Interpreter-Driven Design ==
== Reflective or Meta-Level Designs ==

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =
*[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 '''Design Pattern''']
*[http://en.wikipedia.org/wiki/Delegation_pattern '''Delegation Pattern''']
*[http://en.wikipedia.org/wiki/Open_Closed_Principle '''Open-Closed Principle''']

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:47:46Z

Dragon9786: /* Protected Variation Pattern */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Closed Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

''In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.'' [3]

== Service Lookup ==

The Service Lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure. From the figure we can also see how the responsibilities are seperated and how a change can be implemented without affecting the client (or multiple clients if more than one is involved).

[[Image:Service_Lookup.jpg|frame|center]]

== Interpreter-Driven Design ==
== Reflective or Meta-Level Designs ==

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =
*[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 '''Design Pattern''']
*[http://en.wikipedia.org/wiki/Delegation_pattern '''Delegation Pattern''']

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:46:39Z

Dragon9786: /* See Also */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Close Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

''In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.'' [3]

== Service Lookup ==

The Service Lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure. From the figure we can also see how the responsibilities are seperated and how a change can be implemented without affecting the client (or multiple clients if more than one is involved).

[[Image:Service_Lookup.jpg|frame|center]]

== Interpreter-Driven Design ==
== Reflective or Meta-Level Designs ==

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =
*[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 '''Design Pattern''']
*[http://en.wikipedia.org/wiki/Delegation_pattern '''Delegation Pattern''']

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:45:01Z

Dragon9786: /* Data Driven Design */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Close Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

''In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.'' [3]

== Service Lookup ==

The Service Lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure. From the figure we can also see how the responsibilities are seperated and how a change can be implemented without affecting the client (or multiple clients if more than one is involved).

[[Image:Service_Lookup.jpg|frame|center]]

== Interpreter-Driven Design ==
== Reflective or Meta-Level Designs ==

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:44:18Z

Dragon9786: /* Service Lookup */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Close Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.

== Service Lookup ==

The Service Lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure. From the figure we can also see how the responsibilities are seperated and how a change can be implemented without affecting the client (or multiple clients if more than one is involved).

[[Image:Service_Lookup.jpg|frame|center]]

== Interpreter-Driven Design ==
== Reflective or Meta-Level Designs ==

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:41:55Z

Dragon9786: /* Service Lookup */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Close Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.

== Service Lookup ==

The Service Lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure

[[Image:Service_Lookup.jpg|frame|center]]

== Interpreter-Driven Design ==
== Reflective or Meta-Level Designs ==

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =

File:Service Lookup.jpg

2010-12-02T02:36:21Z

Dragon9786: Image showing a lookup service used to obtain a service

Image showing a lookup service used to obtain a service

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:35:19Z

Dragon9786: /* Service Lookup */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Close Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.

== Service Lookup ==

The Service lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as [http://en.wikipedia.org/wiki/JNDI '''JNDI'''] can be used to do service lookups to obtain services like [http://en.wikipedia.org/wiki/Jini Jini].

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services.

== Interpreter-Driven Design ==
== Reflective or Meta-Level Designs ==

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:29:58Z

Dragon9786: /* Uniform Access */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Close Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as '''Ada, Eiffel, and C#''' support uniform access. For example, consider a '''Rectangle class''' with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.

== Service Lookup ==
== Interpreter-Driven Design ==
== Reflective or Meta-Level Designs ==

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:28:51Z

Dragon9786: /* Data Driven Design */

= Introduction =
The '''Protected Variations pattern''' [5] is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 Interfaces], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] and [http://en.wikipedia.org/wiki/Indirection Indirection].'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Close Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by [http://en.wikipedia.org/wiki/Information_hiding '''Information Hiding'''] in [3].

== An Example ==
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation'''].
This can be seen as implementing the Protected Variation pattern, in that

*If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.

*It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.

= Other Mechanisms motivated by PV =
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.

Even Components such as brokers and virtual machines are complex examples of indirection.[2]

== Uniform Access ==
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as Ada, Eiffel, and C# support uniform access. For example, consider a Rectangle class with public fields length and width as below

class Rectangle{
public:
float length;
float width
private:
......
}

Now a reference such as '''Rectangle.length''' might either refer to the public field or might internally call a method '''length():float''' depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.

== Data Driven Design ==
This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, ''from an external source in order to change the behavior of or “parameterize” a system in some way at runtime.'' [2]

Impelementations such as '''style sheets, metadata for object-relational mapping, property files''' etc belong to this category.

In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it.

== Service Lookup ==
== Interpreter-Driven Design ==
== Reflective or Meta-Level Designs ==

= Advantages =
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:

* Cost for changes is lowered.
* There is low coupling when the Protected Variations pattern is used.
* Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
* If there are clients accessing a service from an object, new features or services can be added without affecting the clients.

= References =
[1] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 '''Wikipedia GRASP patterns''']

[2] ''Protected variation: the importance of being closed'', Larman.C, ISSN: 0740-7459, 89 - 91

[3] ''“On the Criteria to Be Used in Decomposing Systems into Modules”'', Comm. ACM, vol.12, no. 2, Dec. 1972

[4] Object- Oriented Software Construction (IEEE Press, 1988)

[5] ''“Prioritizing Forces in Software Design”'', Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996

= See Also =

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:22:40Z

Dragon9786: /* Uniform Access */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:14:03Z

Dragon9786: /* Uniform Access */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:11:42Z

Dragon9786: /* Advantages */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T02:03:52Z

Dragon9786: /* Conclusion */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:57:04Z

Dragon9786: /* References */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:53:05Z

Dragon9786: /* Other Mechanisms motivated by PV */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:42:36Z

Dragon9786:

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:40:50Z

Dragon9786: /* An Example */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:40:30Z

Dragon9786: /* An Example */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:36:13Z

Dragon9786: /* Protected Variation Pattern */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:32:40Z

Dragon9786: /* An Example */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:31:45Z

Dragon9786: /* An Example */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:29:55Z

Dragon9786: /* An Example */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:23:18Z

Dragon9786: /* References */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:21:44Z

Dragon9786: /* Introduction */

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:20:47Z

Dragon9786: /* Protected Variation Pattern */

= Introduction =
The protected variations pattern is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, interfaces, polymorphism and indirection.'''. Also the Protected Variation pattern in principle is very similar to the '''"Open-Close Principle"''' discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by '''Information Hiding''' in [3].

== An Example ==
Craig Larman in [2] discusses an example of the Protected Variations Pattern.

= Conclusion =

= References =
[1] Wikipedia GRASP patterns

[2] Protected variation: the importance of being closed, Larman.C, ISSN: 0740-7459, 89 - 91

[3] “On the Criteria to Be Used in Decomposing Systems into Modules” Comm. ACM, vol.12, no. 2, Dec. 1972

= See Also =

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T01:17:44Z

Dragon9786: /* Protected Variations Pattern */

= Introduction =
The protected variations pattern is one of the '''GRASP''' patterns. '''General Responsibility Assignment Software Patterns (or Principles)''', abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

= Protected Variation Pattern =
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.

That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.

Some of the standard practices motivated by this pattern are '''Data encapsulation, interfaces, polymorphism and indirection.'''

== An Example ==
Craig Larman in [2] discusses an example of the Protected Variations Pattern.

= Conclusion =

= References =
[1] Wikipedia GRASP patterns

[2] Protected variation: the importance of being closed, Larman.C, ISSN: 0740-7459, 89 - 91

[3] “On the Criteria to Be Used in Decomposing Systems into Modules” Comm. ACM, vol.12, no. 2, Dec. 1972

= See Also =

CSC/ECE 517 Fall 2010/ch7 7e GS

2010-12-02T00:14:59Z

Dragon9786:

= Protected Variations Pattern =
GRASP stands for General Responsibility Assignment Software Patterns and defines nine patterns, of which '''protected variations ''' is one [1].
<blockquote>The protected variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.[1]</blockquote>

CSC/ECE 517 Fall 2010/ch1 S10 ms

2010-12-02T00:13:45Z

Dragon9786:

*[[CSC/ECE 517 Fall 2010/ch1 1a vc]]

*[[CSC/ECE 517 Fall 2010/ch1 1a br]]

*[[CSC/ECE 517 Fall 2010/ch1 1b mg]]

*[[CSC/ECE 517 Fall 2010/ch1 1c JF]]

*[[CSC/ECE 517 Fall 2010/ch1 1e az]]

*[[CSC/ECE 517 Fall 2010/ch1 1e bb]]

*[[CSC/ECE 517 Fall 2010/ch1 1f vn]]

*[[CSC/ECE 517 Fall 2010/ch1 25 ag]]

*[[CSC/ECE 517 Fall 2010/ch2 2b dg]]

*[[CSC/ECE 517 Fall 2010/ch1 2e RI]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 aa]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 km]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 GP]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MS]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MM]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 PH]]

*[[CSC/ECE 517 Fall 2010/ch2 2a CB]]

*[[CSC/ECE 517 Fall 2010/ch2 2a mw]]

*[[CSC/ECE 517 Fall 2010/ch2 2c ck]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 GP]]

*[[CSC/ECE 517 Fall 2010/ch2 S24 NS]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 SS]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 NR]]

*[[CSC/ECE 517 Fall 2010/ch2 S20 TT]]

*[[CSC/ECE 517 Fall 2010/ch2 2d AS]]

*[[CSC/ECE 517 Fall 2010/ch2 S24 rm]]

*[[CSC/ECE 517 Fall 2010/ch3 3a SN]]

*[[CSC/ECE 517 Fall 2010/ch3 3b ka]]

*[[CSC/ECE 517 Fall 2010/ch3 3e br]]

*[[CSC/ECE 517 Fall 2010/ch3 3f lj]]

*[[CSC/ECE 517 Fall 2010/ch3 3h az]]

*[[CSC/ECE 517 Fall 2010/ch3 3h PW]]

*[[CSC/ECE 517 Fall 2010/ch3 3i IC]]

*[[CSC/ECE 517 Fall 2010/ch3 3i MM]]

*[[CSC/ECE 517 Fall 2010/ch3 3j KS]]

*[[CSC/ECE 517 Fall 2010/ch3 S30 SK]]

*[[CSC/ECE 517 Fall 2010/ch3 4b mt]]

*[[CSC/ECE 517 Fall 2010/ch4 4e ms]]

*[[CSC/ECE 517 Fall 2010/ch4 4f sv]]

*[[CSC/ECE 517 Fall 2010/ch4 4g HW]]

*[[CSC/ECE 517 Fall 2010/ch4 4g km]]

*[[CSC/ECE 517 Fall 2010/ch4 4h am]]

*[[CSC/ECE 517 Fall 2010/ch5 5b mt]]

*[[CSC/ECE 517 Fall 2010/ch5 5b jz]]

*[[CSC/ECE 517 Fall 2010/ch5 5c ck]]

*[[CSC/ECE 517 Fall 2010/ch5 5c IC]]

*[[CSC/ECE 517 Fall 2010/ch5 5f SN]]

*[[CSC/ECE 517 Fall 2010/ch5 5a KR]]

*[[CSC/ECE 517 Fall 2010/ch5 5b RR]]

*[[CSC/ECE 517 Fall 2010/ch5 5e ms]]

*[[CSC/ECE 517 Fall 2010/chd 6d isb]]

*[[CSC/ECE 517 Fall 2010/ch6 6b SK]]

*[[CSC/ECE 517 Fall 2010/ch6 6c AW]]

*[[CSC/ECE 517 Fall 2010/ch6 6d bb]]

*[[CSC/ECE 517 Fall 2010/ch6 6h AS]]

*[[CSC/ECE 517 Fall 2010/ch6 6f AZ]]

*[[CSC/ECE 517 Fall 2010/ch6 6b AK]]

*[[CSC/ECE 517 Fall 2010/ch6 6g ss]]

*[[CSC/ECE 517 Fall 2010/ch6 6d NM]]

*[[ CSC/ECE 517 Fall 2010/ch6 6a PC]]

*[[ CSC/ECE 517 Fall 2010/ch2 4d RB]]

*[[ CSC/ECE 517 Fall 2010/ch7 7e GP]]

*[[ CSC/ECE 517 Fall 2010/ch7 7e GS]]

*[[ CSC/ECE 517 Fall 2010/ch7 7f PW]]

*[[ CSC/ECE 517 Fall 2010/ch7 7g ms]]

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T17:49:00Z

Dragon9786:

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

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

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

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

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

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

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

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

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

*Assign Responsibilities

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

*Add Attributes

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

*Define and simulate Scenario

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

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

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

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

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

*Verify Your Work 

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

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

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T17:46:13Z

Dragon9786:

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

There are also several practical designs that use the CRC card model to design Object oriented software design. The [http://www.extremeprogramming.org/example/crcsim.html Simulator for Coffee Maker] explores an [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] approach combined with CRC card technique to come up with a design for the coffee maker.

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

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

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

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

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

*Assign Responsibilities

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

*Add Attributes

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

*Define and simulate Scenario

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

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

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

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

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

*Verify Your Work 

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

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

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T17:44:30Z

Dragon9786: /* A CRC Example */

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

There are also several practical designs that use the CRC card model to design Object oriented software design. The [http://www.extremeprogramming.org/example/crcsim.html Simulator for Coffee Maker] explores an [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] approach combined with CRC card technique to come up with a design for the coffee maker.

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

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

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

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

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

*Assign Responsibilities

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

*Add Attributes

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

*Define and simulate Scenario

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

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

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

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

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

*Verify Your Work 

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

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

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

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

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

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

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

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

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

File:Stud enr Crc.jpg

2010-09-22T17:38:44Z

Dragon9786:

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T17:27:12Z

Dragon9786:

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

There are also several practical designs that use the CRC card model to design Object oriented software design. The [http://www.extremeprogramming.org/example/crcsim.html Simulator for Coffee Maker] explores an [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] approach combined with CRC card technique to come up with a design for the coffee maker.

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

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

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

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

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

*Assign Responsibilities

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

*Add Attributes

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

*Define and simulate Scenario

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

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

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

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

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

*Verify Your Work 

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

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

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T17:23:48Z

Dragon9786: /* A CRC Example */

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

There are also several practical designs that use the CRC card model to design Object oriented software design. The [http://www.extremeprogramming.org/example/crcsim.html Simulator for Coffee Maker] explores an [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] approach combined with CRC card technique to come up with a design for the coffee maker.

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

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

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

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

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

*Assign Responsibilities

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

*Add Attributes

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

*Define and simulate Scenario

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

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

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

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

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

*Verify Your Work 

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

==Summary==
Software for CRC cards are immensely helpful in designing and modeling Software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.
==References==
[1] A Laboratory For Teaching Object-Oriented Thinking: [http://c2.com/doc/oopsla89/paper.html http://c2.com/doc/oopsla89/paper.html]

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

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

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

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

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T16:47:54Z

Dragon9786: /* Advantages of 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 an example.

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

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

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

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

*Assign Responsibilities

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

*Add Attributes

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

*Define and simulate Scenario

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

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

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

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

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

*Verify Your Work 

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

==Summary==
Software for CRC cards are immensely helpful in designing and modeling Software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.
==References==
[1] A Laboratory For Teaching Object-Oriented Thinking: [http://c2.com/doc/oopsla89/paper.html http://c2.com/doc/oopsla89/paper.html]

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

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

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

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

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T16:47:34Z

Dragon9786: /* See Also */

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

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

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

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

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

*Assign Responsibilities

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

*Add Attributes

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

*Define and simulate Scenario

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

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

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

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

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

*Verify Your Work 

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

==Summary==
Software for CRC cards are immensely helpful in designing and modeling Software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.
==References==
[1] A Laboratory For Teaching Object-Oriented Thinking: [http://c2.com/doc/oopsla89/paper.html http://c2.com/doc/oopsla89/paper.html]

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

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

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

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

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T16:44:13Z

Dragon9786: /* Advantages of 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 an example.

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

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

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

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

*Assign Responsibilities

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

*Add Attributes

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

*Define and simulate Scenario

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

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

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

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

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

*Verify Your Work 

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

==Summary==
Software for CRC cards are immensely helpful in designing and modeling Software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.
==References==
[1] A Laboratory For Teaching Object-Oriented Thinking: [http://c2.com/doc/oopsla89/paper.html http://c2.com/doc/oopsla89/paper.html]

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

==See Also==

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

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

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T16:27:31Z

Dragon9786: /* Advantages of 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 an example.

===Advantages of CRC cards===
There are quite a few advantages of CRC cards that make it a preferable model in many designs. Some of the advantages of the CRC card design method are
 
:* CRC cards can allow designers to easily make audience understand a very complex system. In essence it allows for building more complex designs by slowly building the interactions between the collaborating classes, one by one.
:* CRC cards are a simple technique and it can be easily used by anyone with very little training and does not require any expensive computing resources(a board or a paper and a pen would suffice).
:* CRC is fundamentally a brainstorming tool, enabling different people in a team to come up with the design by collaborating, enabling everyone in the team to contribute

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

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

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

*Assign Responsibilities

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

*Add Attributes

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

*Define and simulate Scenario

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

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

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

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

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

*Verify Your Work 

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

==Summary==
Software for CRC cards are immensely helpful in designing and modeling Software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.
==References==
[1] A Laboratory For Teaching Object-Oriented Thinking: [http://c2.com/doc/oopsla89/paper.html http://c2.com/doc/oopsla89/paper.html]

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

==See Also==

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

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

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T16:16:12Z

Dragon9786: /* Why need a Software for CRC Cards */

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

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

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

===A CRC Example===
To better understand how the CRC cards work together, let us consider an example.

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

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

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

*Assign Responsibilities

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

*Add Attributes

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

*Define and simulate Scenario

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

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

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

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

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

*Verify Your Work 

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

==Summary==
Software for CRC cards are immensely helpful in designing and modeling Software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.
==References==
[1] A Laboratory For Teaching Object-Oriented Thinking: [http://c2.com/doc/oopsla89/paper.html http://c2.com/doc/oopsla89/paper.html]

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

==See Also==

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

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

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T16:11:14Z

Dragon9786:

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

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

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

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

*Assign Responsibilities

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

*Add Attributes

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

*Define and simulate Scenario

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

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

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

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

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

*Verify Your Work 

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

==Summary==
Software for CRC cards are immensely helpful in designing and modeling Software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.
==References==
[1] A Laboratory For Teaching Object-Oriented Thinking: [http://c2.com/doc/oopsla89/paper.html http://c2.com/doc/oopsla89/paper.html]

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

==See Also==

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

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

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T16:10:00Z

Dragon9786: /* Desining Software */

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T16:08:19Z

Dragon9786: /* Desining Software */

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

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

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

===A CRC Example===
To better understand how the CRC cards work together, let us consider an example.

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

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

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

2) 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.

3) Add Attributes

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

 4) Define and simulate Scenario

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

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

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

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

 6) 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.

 7) Verify Your Work 

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

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

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

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

==See Also==

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

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

:* [http://www.excelsoftware.com/quickcrcwin.html Quick CRC]

CSC/ECE 517 Fall 2010/ch1 2b dg

2010-09-22T16:03:20Z

Dragon9786: /* 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 an example.

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

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

1) 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]]

2) 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.

3) Add Attributes

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

 4) Define and simulate Scenario

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

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

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

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

 6)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.

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

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

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

==See Also==

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

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

:* [http://www.excelsoftware.com/quickcrcwin.html Quick CRC]