User:Bluehat - Revision history

Bluehat: /* Number of responsibilities */

2010-09-08T17:55:50Z

Number of responsibilities

← Older revision		Revision as of 17:55, 8 September 2010
Line 131:		Line 131:

	===Number of responsibilities===		===Number of responsibilities===
	This is the count of clearly defined set of duties to each class.[6]For example class Student may have functions like Attending Lectures,		This is the count of clearly defined set of duties to each class.[6] For example class Student may have functions like Attending Lectures,
	Maintaining a certain GPA,Taking the required courses. In this case number of responsibilities is three.Responsibilities should be distributed amongst classes to cover the whole system. This would avoid an imbalance in design. We need to refine the overly complex class into a series of simpler objects. This will make the system easier to understand, implement and reuse. For most commercial transaction oriented systems, values approximately between eight and eighteen are common.		Maintaining a certain GPA,Taking the required courses. In this case number of responsibilities is three.Responsibilities should be distributed amongst classes to cover the whole system. This would avoid an imbalance in design. We need to refine the overly complex class into a series of simpler objects. This will make the system easier to understand, implement and reuse. For most commercial transaction oriented systems, values approximately between eight and eighteen are common.

Bluehat: /* Number of collaborators */

2010-09-08T17:55:38Z

Number of collaborators

← Older revision		Revision as of 17:55, 8 September 2010
Line 128:		Line 128:
	===Number of collaborators===		===Number of collaborators===

	This is the count of all the supporting classes to help a class.[6]In the diagram,there are four collaborators for class Student:Teacher,Library,Computer Labs and Gymnasium.Confusion between collaborators and subclasses may result in creation many collaborators.This will affect the encapsulation of the design.Typical value for this metric is eight.If this value is large,design may be reviewed to see if inheritance is implemented correctly.		This is the count of all the supporting classes to help a class.[6] In the diagram,there are four collaborators for class Student:Teacher,Library,Computer Labs and Gymnasium.Confusion between collaborators and subclasses may result in creation many collaborators.This will affect the encapsulation of the design.Typical value for this metric is eight.If this value is large,design may be reviewed to see if inheritance is implemented correctly.


	===Number of responsibilities===		===Number of responsibilities===

Bluehat: /* Maximum depth of inheritance */

2010-09-08T17:55:23Z

Maximum depth of inheritance

← Older revision		Revision as of 17:55, 8 September 2010
Line 124:		Line 124:
	===Maximum depth of inheritance===		===Maximum depth of inheritance===

	This metric gives an idea of the class hierarchy. It is the count of number of subclasses in the hierarchy.[6]From the diagram,it can be seen that Part Time student is a subclass of Distance Education which in turn is a subclass of student.Thus,maximum depth of inheritance in this case is two with reference to class Student. Each subclass shares the overall functions defined in class Student. For short hierarchies, this is a positive benefit of OO. If number of subclasses become too long, it becomes difficult to trace the flow of functions, resulting in overly complex systems. This makes testing, reviewing and reusing difficult.		This metric gives an idea of the class hierarchy. It is the count of number of subclasses in the hierarchy.[6] From the diagram,it can be seen that Part Time student is a subclass of Distance Education which in turn is a subclass of student.Thus,maximum depth of inheritance in this case is two with reference to class Student. Each subclass shares the overall functions defined in class Student. For short hierarchies, this is a positive benefit of OO. If number of subclasses become too long, it becomes difficult to trace the flow of functions, resulting in overly complex systems. This makes testing, reviewing and reusing difficult.


	===Number of collaborators===		===Number of collaborators===

Bluehat: /* Metrics for CRC Analysis */

2010-09-08T17:54:59Z

Metrics for CRC Analysis

← Older revision		Revision as of 17:54, 8 September 2010
Line 124:		Line 124:
	===Maximum depth of inheritance===		===Maximum depth of inheritance===

	This metric gives an idea of the class hierarchy. It is the count of number of subclasses in the hierarchy.From the diagram,it can be seen that Part Time student is a subclass of Distance Education which in turn is a subclass of student.Thus,maximum depth of inheritance in this case is two with reference to class Student. Each subclass shares the overall functions defined in class Student. For short hierarchies, this is a positive benefit of OO. If number of subclasses become too long, it becomes difficult to trace the flow of functions, resulting in overly complex systems. This makes testing, reviewing and reusing difficult.		This metric gives an idea of the class hierarchy. It is the count of number of subclasses in the hierarchy.[6]From the diagram,it can be seen that Part Time student is a subclass of Distance Education which in turn is a subclass of student.Thus,maximum depth of inheritance in this case is two with reference to class Student. Each subclass shares the overall functions defined in class Student. For short hierarchies, this is a positive benefit of OO. If number of subclasses become too long, it becomes difficult to trace the flow of functions, resulting in overly complex systems. This makes testing, reviewing and reusing difficult.


	===Number of collaborators===		===Number of collaborators===

	This is the count of all the supporting classes to help a class.In the diagram,there are four collaborators for class Student:Teacher,Library,Computer Labs and Gymnasium.Confusion between collaborators and subclasses may result in creation many collaborators.This will affect the encapsulation of the design.Typical value for this metric is eight.If this value is large,design may be reviewed to see if inheritance is implemented correctly.		This is the count of all the supporting classes to help a class.[6]In the diagram,there are four collaborators for class Student:Teacher,Library,Computer Labs and Gymnasium.Confusion between collaborators and subclasses may result in creation many collaborators.This will affect the encapsulation of the design.Typical value for this metric is eight.If this value is large,design may be reviewed to see if inheritance is implemented correctly.


	===Number of responsibilities===		===Number of responsibilities===
	This is the count of clearly defined set of duties to each class.For example class Student may have functions like Attending Lectures,		This is the count of clearly defined set of duties to each class.[6]For example class Student may have functions like Attending Lectures,
	Maintaining a certain GPA,Taking the required courses. In this case number of responsibilities is three.Responsibilities should be distributed amongst classes to cover the whole system. This would avoid an imbalance in design. We need to refine the overly complex class into a series of simpler objects. This will make the system easier to understand, implement and reuse. For most commercial transaction oriented systems, values approximately between eight and eighteen are common.		Maintaining a certain GPA,Taking the required courses. In this case number of responsibilities is three.Responsibilities should be distributed amongst classes to cover the whole system. This would avoid an imbalance in design. We need to refine the overly complex class into a series of simpler objects. This will make the system easier to understand, implement and reuse. For most commercial transaction oriented systems, values approximately between eight and eighteen are common.

Bluehat: /* Definition */

2010-09-08T17:51:49Z

Definition

← Older revision		Revision as of 17:51, 8 September 2010
Line 8:		Line 8:

	==Definition==		==Definition==
	Class Responsibility Collaboration (CRC) cards is an object-oriented design method that uses ordinary 3x5 index cards card made for each class containing responsibilities (knowledge and services) and collaborators (interactions with other classes). The cards provide an informal, intuitive way for group members to work on object design together.		Class Responsibility Collaboration (CRC) cards is an object-oriented design method that uses ordinary 3x5 index cards card made for each class containing responsibilities (knowledge and services) and collaborators (interactions with other classes). The cards provide an informal, intuitive way for group members to work on object design together.[1]
	A typical CRC card layout is shown below.		A typical CRC card layout is shown below.
	[[Image:Crccard2.jpg\|frame\|center\|CRC CARD Template]]		[[Image:Crccard2.jpg\|frame\|center\|CRC CARD Template]]

Bluehat: /* Reference */

2010-09-08T17:50:44Z

Reference

← Older revision		Revision as of 17:50, 8 September 2010
Line 175:		Line 175:

	==Reference==		==Reference==
	[1]Rubin,D.M, Introduction to CRC Cards ,Methodologies and Practices. Revised January 1998, SOFTSTAR RESEARCH, INC: http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf		[1]Rubin,D.M, Introduction to CRC Cards, Methodologies and Practices.Revised January 1998,SOFTSTAR RESEARCH,INC: http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf

	[2]Bjork,R.C, CRC cards for ATM, Object-Oriented Software Development.Retrieved September 6,2010,from Computer Science Department, Gordon College:: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html		[2]Bjork,R.C, CRC cards for ATM, Object-Oriented Software Development.Retrieved September 6,2010,from Computer Science Department, Gordon College:: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html

Bluehat: /* Reference */

2010-09-08T17:49:57Z

Reference

← Older revision		Revision as of 17:49, 8 September 2010
Line 175:		Line 175:

	==Reference==		==Reference==
	[1]Introduction to CRC Cards: http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf		[1]Rubin,D.M, Introduction to CRC Cards ,Methodologies and Practices. Revised January 1998, SOFTSTAR RESEARCH, INC: http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf

	[2]Bjork,R.C, CRC cards for ATM, Object-Oriented Software Development.Retrieved September 6,2010,from Computer Science Department, Gordon College:: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html		[2]Bjork,R.C, CRC cards for ATM, Object-Oriented Software Development.Retrieved September 6,2010,from Computer Science Department, Gordon College:: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html

Bluehat: /* CRC cards Limitations and formal object modeling methodologies(UML) */

2010-09-08T17:38:17Z

CRC cards Limitations and formal object modeling methodologies(UML)

← Older revision		Revision as of 17:38, 8 September 2010
Line 168:		Line 168:
	CRC cards are used to form initial class definitions but alone are not sufficient to be directly coded into software for large systems.It is difficult to keep track of cards as the systems grows and work on subsystems simultaneously and independently.CRC cards lack the notational power to document all the components of a system and cannot provide implementation specifications such as transition states of objects during its life cycle,interface design,data structures,performance and resource utilization. To bridge this gap,more formal object modeling methodology such as UML is used.UML captures the bigger picture.It provides detailed mapping of use cases(operations),object state transitions,inter-process communication functionality,algorithm design.UML is very effective in incremental model of SDLC where lot of details need to captured for precise addition.Information about requirements is represented in detail and whole picture of the system and users is visible.CRC cards are used as effective inputs to UML.CRC card techniques such as brainstorming and role play help enhance functional understanding which helps in preparing better UML use cases.CRC cards given the content for class diagrams,inheritance diagrams,class specifications and object specifications for UML.CRC cards can keep track of attributes that can aid listing them as a part of class specification in UML.Most CRC card software have the facility to export CRC analysis file that can be directly used as an input for UML.Following case study develops UML with the help of CRC cards:		CRC cards are used to form initial class definitions but alone are not sufficient to be directly coded into software for large systems.It is difficult to keep track of cards as the systems grows and work on subsystems simultaneously and independently.CRC cards lack the notational power to document all the components of a system and cannot provide implementation specifications such as transition states of objects during its life cycle,interface design,data structures,performance and resource utilization. To bridge this gap,more formal object modeling methodology such as UML is used.UML captures the bigger picture.It provides detailed mapping of use cases(operations),object state transitions,inter-process communication functionality,algorithm design.UML is very effective in incremental model of SDLC where lot of details need to captured for precise addition.Information about requirements is represented in detail and whole picture of the system and users is visible.CRC cards are used as effective inputs to UML.CRC card techniques such as brainstorming and role play help enhance functional understanding which helps in preparing better UML use cases.CRC cards given the content for class diagrams,inheritance diagrams,class specifications and object specifications for UML.CRC cards can keep track of attributes that can aid listing them as a part of class specification in UML.Most CRC card software have the facility to export CRC analysis file that can be directly used as an input for UML.Following case study develops UML with the help of CRC cards:

	http://www.math.gordon.edu/courses/cs211/ATMExample/		http://www.math.gordon.edu/courses/cs211/ATMExample/ [3]

	==Summary==		==Summary==

Bluehat: /* Reference */

2010-09-08T17:35:50Z

Reference

← Older revision		Revision as of 17:35, 8 September 2010
Line 177:		Line 177:
	[1]Introduction to CRC Cards: http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf		[1]Introduction to CRC Cards: http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf

	[2]CRC ~~Cards~~ for ATM : http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html		[2]Bjork,R.C, CRC cards for ATM, Object-Oriented Software Development.Retrieved September 6,2010,from Computer Science Department, Gordon College:: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html

	[3]Bjork,R.C, ATMExample, Object-Oriented Software Development.Retrieved September 5,2010,from Computer Science Department, Gordon College: http://www.math.gordon.edu/courses/cs211/ATMExample/		[3]Bjork,R.C, ATMExample, Object-Oriented Software Development.Retrieved September 5,2010,from Computer Science Department, Gordon College: http://www.math.gordon.edu/courses/cs211/ATMExample/

Bluehat: /* Reference */

2010-09-08T17:31:25Z

Reference

← Older revision		Revision as of 17:31, 8 September 2010
Line 179:		Line 179:
	[2]CRC Cards for ATM : http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html		[2]CRC Cards for ATM : http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html

	[3]~~UML methodology for ATM~~ :http://www.math.gordon.edu/courses/cs211/ATMExample/		[3]Bjork,R.C, ATMExample, Object-Oriented Software Development.Retrieved September 5,2010,from Computer Science Department, Gordon College: http://www.math.gordon.edu/courses/cs211/ATMExample/

	[4]quickCRC:http://www.excelsoftware.com/		[4]quickCRC:http://www.excelsoftware.com/