CSC/ECE 517 Fall 2012/ch2a 2w15 rr - Revision history

Rbettad at 20:31, 1 November 2012

2012-11-01T20:31:23Z

← Older revision		Revision as of 20:31, 1 November 2012
Line 1:		Line 1:
	Roles and Responsibilities		<b>Roles and Responsibilities</b>
	==Introduction==		==Introduction==
	[http://en.wikipedia.org/wiki/Object-oriented_design Object-oriented design] is a [http://en.wikipedia.org/wiki/Programming_paradigm programming paradigm] that began in the late 60's as software programs became more complex. The idea behind the approach was to build software systems by modeling them based on the real-world objects that they were trying to represent. For example, banking systems would contain customer objects, account objects and so on. Today, object-oriented design has been widely adopted <ref> [http://www.objectmentor.com/omSolutions/oops_what.html Introduction to Object Oriented Design]</ref>. When done properly, this approach leads to simple, robust, flexible and modular software. When something goes wrong, the results could be bad. Object oriented design can be seen from different perspectives. In the language-centric perspective, [http://en.wikipedia.org/wiki/Object_(computer_science) objects] are containers of data and [http://en.wikipedia.org/wiki/Method_(computer_science) methods]. The model-centric perspective views the objects as model elements reflecting the real world objects and Responsibility-centric perspective views objects as interacting elements each playing a role in object community. Each of these perspectives are outlined in the following sections.		[http://en.wikipedia.org/wiki/Object-oriented_design Object-oriented design] is a [http://en.wikipedia.org/wiki/Programming_paradigm programming paradigm] that began in the late 60's as software programs became more complex. The idea behind the approach was to build software systems by modeling them based on the real-world objects that they were trying to represent. For example, banking systems would contain customer objects, account objects and so on. Today, object-oriented design has been widely adopted <ref> [http://www.objectmentor.com/omSolutions/oops_what.html Introduction to Object Oriented Design]</ref>. When done properly, this approach leads to simple, robust, flexible and modular software. When something goes wrong, the results could be bad. Object oriented design can be seen from different perspectives. In the language-centric perspective, [http://en.wikipedia.org/wiki/Object_(computer_science) objects] are containers of data and [http://en.wikipedia.org/wiki/Method_(computer_science) methods]. The model-centric perspective views the objects as model elements reflecting the real world objects and Responsibility-centric perspective views objects as interacting elements each playing a role in object community. Each of these perspectives are outlined in the following sections.

Rbettad at 20:30, 1 November 2012

2012-11-01T20:30:58Z

← Older revision		Revision as of 20:30, 1 November 2012
Line 1:		Line 1:
			Roles and Responsibilities
	==Introduction==		==Introduction==
	[http://en.wikipedia.org/wiki/Object-oriented_design Object-oriented design] is a [http://en.wikipedia.org/wiki/Programming_paradigm programming paradigm] that began in the late 60's as software programs became more complex. The idea behind the approach was to build software systems by modeling them based on the real-world objects that they were trying to represent. For example, banking systems would contain customer objects, account objects and so on. Today, object-oriented design has been widely adopted <ref> [http://www.objectmentor.com/omSolutions/oops_what.html Introduction to Object Oriented Design]</ref>. When done properly, this approach leads to simple, robust, flexible and modular software. When something goes wrong, the results could be bad. Object oriented design can be seen from different perspectives. In the language-centric perspective, [http://en.wikipedia.org/wiki/Object_(computer_science) objects] are containers of data and [http://en.wikipedia.org/wiki/Method_(computer_science) methods]. The model-centric perspective views the objects as model elements reflecting the real world objects and Responsibility-centric perspective views objects as interacting elements each playing a role in object community. Each of these perspectives are outlined in the following sections.		[http://en.wikipedia.org/wiki/Object-oriented_design Object-oriented design] is a [http://en.wikipedia.org/wiki/Programming_paradigm programming paradigm] that began in the late 60's as software programs became more complex. The idea behind the approach was to build software systems by modeling them based on the real-world objects that they were trying to represent. For example, banking systems would contain customer objects, account objects and so on. Today, object-oriented design has been widely adopted <ref> [http://www.objectmentor.com/omSolutions/oops_what.html Introduction to Object Oriented Design]</ref>. When done properly, this approach leads to simple, robust, flexible and modular software. When something goes wrong, the results could be bad. Object oriented design can be seen from different perspectives. In the language-centric perspective, [http://en.wikipedia.org/wiki/Object_(computer_science) objects] are containers of data and [http://en.wikipedia.org/wiki/Method_(computer_science) methods]. The model-centric perspective views the objects as model elements reflecting the real world objects and Responsibility-centric perspective views objects as interacting elements each playing a role in object community. Each of these perspectives are outlined in the following sections.

Rbettad: /* Responsibility-centric perspectivehttps://practicingruby.com/articles/shared/bxstlrbnrjzt */

2012-10-26T22:30:21Z

Responsibility-centric perspectivehttps://practicingruby.com/articles/shared/bxstlrbnrjzt

← Older revision		Revision as of 22:30, 26 October 2012
Line 80:		Line 80:
	end		end
	</pre>		</pre>
	The client does not know which sort of order processor it is talking to, it just knows how to request that an order gets processed. Validations are skipped when the client is provided with a StandardOrderProcessor, and they are run when it is provided with a OrderValidationProcessor, but the client does not know or care about these details. This allows for substantial changes in order processing behavior without requiring any modifications to the client object.		The client does not know which sort of order processor it is talking to, it just knows how to request that an order gets processed. [http://en.wikipedia.org/wiki/Validation Validations] are skipped when the client is provided with a StandardOrderProcessor, and they are run when it is provided with a OrderValidationProcessor, but the client does not know or care about these details. This allows for substantial changes in order processing behavior without requiring any modifications to the client object.

	== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==		== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==

Rbettad: /* Responsibility-centric perspectivehttps://practicingruby.com/articles/shared/bxstlrbnrjzt */

2012-10-26T22:29:15Z

Responsibility-centric perspectivehttps://practicingruby.com/articles/shared/bxstlrbnrjzt

← Older revision		Revision as of 22:29, 26 October 2012
Line 34:		Line 34:

	===Responsibility-centric perspective<ref>https://practicingruby.com/articles/shared/bxstlrbnrjzt</ref>===		===Responsibility-centric perspective<ref>https://practicingruby.com/articles/shared/bxstlrbnrjzt</ref>===
	This perspective stresses on the behavior of software systems and the concepts used to do design include behavior, roles, responsibilities and protocol. Here, the primary focus is the dynamics of the program. Roles and responsibilities are the core concepts in this perspective and hence it has more coupling to behavior when compared to static elements like objects or model parts. There is a difference between behavior and responsibility, where behavior is the concrete actions taken by objects where as responsibility is to fulfill requests through any number of concrete behaviors. So, responsibility is more abstract than behavior.		This perspective stresses on the behavior of software systems and the concepts used to do design include behavior, roles, responsibilities and protocol. Here, the primary focus is the dynamics of the program. Roles and responsibilities are the core concepts in this perspective and hence it has more [http://en.wikipedia.org/wiki/Coupling_(computer_programming) coupling] to behavior when compared to static elements like objects or model parts. There is a difference between behavior and responsibility, where behavior is the concrete actions taken by objects where as responsibility is to fulfill requests through any number of concrete behaviors. So, responsibility is more [http://en.wikipedia.org/wiki/Abstract abstract] than behavior. One can look at responsibility-centric perspective as an extension of the model-centric perspective with a shift of focus (from a focus on model parts to a focus on the simulation or dynamical aspects).
	One can look at responsibility-centric perspective as an extension of the model-centric perspective with a shift of focus (from a focus on model parts to a focus on the simulation or dynamical aspects).

	The goal of this division is to formulate the description of the behavior of the system in terms of multiple interacting processes, with each process playing a separate role. For example, in an e-commerce application with a responsibility-centric design, you would be likely to find objects such as a payment processor, an inventory tracker, and a user authenticator.		The goal of this division is to formulate the description of the behavior of the system in terms of multiple interacting processes, with each process playing a separate role. For example, in an [http://en.wikipedia.org/wiki/Electronic_commerce e-commerce application] with a responsibility-centric design, you would be likely to find objects such as a [http://en.wikipedia.org/wiki/Payment_processor payment processor], an inventory tracker, and a user authenticator.

	The relationships between objects become very similar to the client/server model. A client object will make requests for the server to perform some service, and a server object will provide a public API for the set of services that it can perform. This relationship is described by a contract - that is a list of requests that can be made of the server by the client. Both objects must fulfill this contract, in that the client can only make the requests specified by the API, and the server must respond by fulfilling those requests when told.		The relationships between objects become very similar to the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. A client object will make requests for the server to perform some service, and a server object will provide a public API for the set of services that it can perform. This relationship is described by a [http://en.wikipedia.org/wiki/Contract contract] - that is a list of requests that can be made of the server by the client. Both objects must fulfill this contract, in that the client can only make the requests specified by the API, and the server must respond by fulfilling those requests when told.

	As an example, a responsibility-centric order processing service might look like what you see below:		As an example, a responsibility-centric order processing service might look like what you see below:
Line 58:		Line 57:
	</pre>		</pre>

	The goal of describing relationships between objects in this way is that it forces the API for the server object to describe what it does for the client rather than how it accomplishes it.		The goal of describing relationships between objects in this way is that it forces the [http://en.wikipedia.org/wiki/Application_programming_interface API] for the server object to describe what it does for the client rather than how it accomplishes it.
	The practical benefit of this kind of design is that it makes certain kinds of changes very easy. For example, the following code could be used as a drop-in replacement for the StandardOrderProcessor, because it implements the same contract:		The practical benefit of this kind of design is that it makes certain kinds of changes very easy. For example, the following code could be used as a drop-in replacement for the StandardOrderProcessor, because it implements the same contract:
	<pre>		<pre>

Rbettad: /* Model-centric perspectiveHenrik Baerbak Christensen, "Implications of Perspective in Teaching Objects First and Object Design", Proceedings of the 10th annual SIGCSE conference on Innovation and technology in computer science education, Department

2012-10-26T22:21:35Z

/* Model-centric perspectiveHenrik Baerbak Christensen, "Implications of Perspective in Teaching Objects First and Object Design", Proceedings of the 10th annual SIGCSE conference on Innovation and technology in computer science education, Department

← Older revision		Revision as of 22:21, 26 October 2012
Line 31:		Line 31:
	[[File:ood.jpg\|450px\|center\|thumb\|An object encapsulates scripts and information]]		[[File:ood.jpg\|450px\|center\|thumb\|An object encapsulates scripts and information]]

	One may add concepts that handles turn handling, move validation, rule-sets etc. The problem here is that in case of turn handling, it is behaviorally very different from move validation.		One may add concepts that handles turn handling, move validation, [http://en.wikipedia.org/wiki/Backgammon#Rules rule-sets] etc. The problem here is that in case of turn handling, it is behaviorally very different from move validation.

	===Responsibility-centric perspective<ref>https://practicingruby.com/articles/shared/bxstlrbnrjzt</ref>===		===Responsibility-centric perspective<ref>https://practicingruby.com/articles/shared/bxstlrbnrjzt</ref>===

Rbettad: /* Model-centric perspectiveHenrik Baerbak Christensen, "Implications of Perspective in Teaching Objects First and Object Design", Proceedings of the 10th annual SIGCSE conference on Innovation and technology in computer science education, Department

2012-10-26T22:20:43Z

← Older revision		Revision as of 22:20, 26 October 2012
Line 30:		Line 30:
	<br/>		<br/>
	[[File:ood.jpg\|450px\|center\|thumb\|An object encapsulates scripts and information]]		[[File:ood.jpg\|450px\|center\|thumb\|An object encapsulates scripts and information]]

			One may add concepts that handles turn handling, move validation, rule-sets etc. The problem here is that in case of turn handling, it is behaviorally very different from move validation.

	===Responsibility-centric perspective<ref>https://practicingruby.com/articles/shared/bxstlrbnrjzt</ref>===		===Responsibility-centric perspective<ref>https://practicingruby.com/articles/shared/bxstlrbnrjzt</ref>===

Rbettad: /* Model-centric perspectiveHenrik Baerbak Christensen, "Implications of Perspective in Teaching Objects First and Object Design", Proceedings of the 10th annual SIGCSE conference on Innovation and technology in computer science education, Department

2012-10-26T22:14:12Z

← Older revision		Revision as of 22:14, 26 October 2012
Line 29:		Line 29:
	<br/>		<br/>
	<br/>		<br/>
	[[File:ood.jpg\|450px\|center\|thumb\|An object encapsulates scripts and information<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA2&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>]]		[[File:ood.jpg\|450px\|center\|thumb\|An object encapsulates scripts and information]]

	===Responsibility-centric perspective<ref>https://practicingruby.com/articles/shared/bxstlrbnrjzt</ref>===		===Responsibility-centric perspective<ref>https://practicingruby.com/articles/shared/bxstlrbnrjzt</ref>===

Rbettad: /* Model-centric perspectiveHenrik Baerbak Christensen, "Implications of Perspective in Teaching Objects First and Object Design", Proceedings of the 10th annual SIGCSE conference on Innovation and technology in computer science education, Department

2012-10-26T22:08:36Z

← Older revision		Revision as of 22:08, 26 October 2012
Line 25:		Line 25:

	===Model-centric perspective<ref>[https://docs.google.com/viewer?a=v&q=cache:Kl7VOfRFnNEJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.86.7500%26rep%3Drep1%26type%3Dpdf+%22language+centric%22+object+oriented+design&hl=en&gl=us&pid=bl&srcid=ADGEESj-HffIDcwsyYlGssvRYS3OAEloLCID6dCIHQeZ_WQ5W-fy9B3rC4uxbUKVBGzyPVn4uBra4ot0hCS71JC3NNy7nBVXRxzR4z06p3fVQKSIjn5t_fFr3dzrMICa5qNUVRnYHEAv&sig=AHIEtbRX7G0XgBl1mKxnPINiorZvNhW32Q Henrik Baerbak Christensen, <i>"Implications of Perspective in Teaching Objects First and Object Design"</i>, Proceedings of the 10th annual <i>SIGCSE</i> conference on Innovation and technology in computer science education, Department of Computer Science, University of Aarhus, 2005.]</ref>===		===Model-centric perspective<ref>[https://docs.google.com/viewer?a=v&q=cache:Kl7VOfRFnNEJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.86.7500%26rep%3Drep1%26type%3Dpdf+%22language+centric%22+object+oriented+design&hl=en&gl=us&pid=bl&srcid=ADGEESj-HffIDcwsyYlGssvRYS3OAEloLCID6dCIHQeZ_WQ5W-fy9B3rC4uxbUKVBGzyPVn4uBra4ot0hCS71JC3NNy7nBVXRxzR4z06p3fVQKSIjn5t_fFr3dzrMICa5qNUVRnYHEAv&sig=AHIEtbRX7G0XgBl1mKxnPINiorZvNhW32Q Henrik Baerbak Christensen, <i>"Implications of Perspective in Teaching Objects First and Object Design"</i>, Proceedings of the 10th annual <i>SIGCSE</i> conference on Innovation and technology in computer science education, Department of Computer Science, University of Aarhus, 2005.]</ref>===
	In this perspective, the objects(classes, fields) and their relationships like inheritance, association, aggregation are designed by using some model. Here the program execution is a simulation of some part of the		In this perspective, the objects(classes, fields) and their relationships like [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Association_(object-oriented_programming) association], [http://en.wikipedia.org/wiki/Object_composition#Aggregation aggregation] are designed by using some model. Here the program execution is a [http://en.wikipedia.org/wiki/Simulation simulation] of some part of the world, and objects are perceived as the parts of the model. The perspective is often explained through analogies to other models like toy railways, [http://en.wikipedia.org/wiki/Traffic_simulation traffic simulations], [http://en.wikipedia.org/wiki/Computer_Games_(album) computer games] and so on. This perspective stresses objects as entities in a larger context (they are parts of a model) as opposed to the self-contained language-centric definition. This approach works fine for real life systems such as an [http://en.wikipedia.org/wiki/Order_management_system order-entry system], a library system, boat-rental and various other real world entity oriented systems. This naturally leads to a strong focus on what the relations are between the parts: association, generalization, [http://en.wikipedia.org/wiki/Object_composition composition]. Dynamics is an inherent part of the concept simulation and the explicit guideline for designing object interaction is to imitate real world or model interactions.
	world, and objects are perceived as the parts of the model. The perspective is often explained through analogies to other models like toy railways, traffic simulations, computer games~~, etc~~. This perspective stresses objects as entities in a larger context (they are parts of a model) as opposed to the self-contained language-centric definition. This approach works fine for real life systems such as an order-entry system, a library system, boat-rental and various other real world entity oriented systems. This naturally leads to a strong focus on what the relations are between the parts: association, generalization, composition. Dynamics is an inherent part of the concept simulation and the explicit guideline for designing object interaction is to imitate real world or model interactions.		Let us consider a real world example of designing a partial implementation of the board game-[http://en.wikipedia.org/wiki/Backgammon Backgammon] to understand the objected oriented using a model-centric perspective. The physical parts of Backgammon identifiable are the [http://en.wikipedia.org/wiki/Draughts checkers], points, board, [http://en.wikipedia.org/wiki/Dice dice], player, etc. The diagram below is a design of model parts (classes) and their relationships (relations).
	Let us consider a real world example of designing a partial implementation of the board game-Backgammon to understand the objected oriented using a model-centric perspective. The physical parts of Backgammon identifiable are the checkers, points, board, dice, player, etc. The diagram below is a design of model parts (classes) and their relationships (relations).
	<br/>		<br/>
	<br/>		<br/>

Rbettad: /* Language-centric perspective */

2012-10-26T21:59:23Z

Language-centric perspective

← Older revision		Revision as of 21:59, 26 October 2012
Line 8:		Line 8:
	==Object Oriented Design Perspectives==		==Object Oriented Design Perspectives==
	===Language-centric perspective===		===Language-centric perspective===
	The focus of the language-centric perspective is classes and objects as building blocks for developing software. The emphasis is on the internal structure which are the fields and methods. Thus it is inherently a compile-time or static view which means that the definition speaks in terms of what it looks like in the following code:		The focus of the language-centric perspective is [http://en.wikipedia.org/wiki/Class_(computer_science) classes] and objects as building blocks for developing software. The emphasis is on the internal structure which are the [http://en.wikipedia.org/wiki/Field_(computer_science) fields] and methods. Thus it is inherently a [http://en.wikipedia.org/wiki/Compile_time compile-time] or static view which means that the definition speaks in terms of what it looks like in the following code:
	<pre>		<pre>
	public class foo		public class foo
Line 22:		Line 22:
	</pre>		</pre>

	The implicit aspect of this view is that, an object is an entity in its own right and the definition is closed. Any object can be understood in isolation where the fields and methods are just enumerated. The advantage of this perspective is of that it is very concrete, closely related to the programming language level and therefore it is easy to understand. The disadvantage is that it does not help to structure the collaboration between objects, the dynamics, and this is typically where the hard challenges of design lie. Thus the perspective offers little guidance in the process of designing any realistic system.		The implicit aspect of this view is that, an object is an entity in its own right and the definition is closed. Any object can be understood in isolation where the fields and methods are just [http://en.wikipedia.org/wiki/Enumerated_type enumerated]. The advantage of this perspective is of that it is very concrete, closely related to the programming language level and therefore it is easy to understand. The disadvantage is that it does not help to structure the collaboration between objects, the dynamics, and this is typically where the hard challenges of design lie. Thus the perspective offers little guidance in the process of designing any realistic system.

	===Model-centric perspective<ref>[https://docs.google.com/viewer?a=v&q=cache:Kl7VOfRFnNEJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.86.7500%26rep%3Drep1%26type%3Dpdf+%22language+centric%22+object+oriented+design&hl=en&gl=us&pid=bl&srcid=ADGEESj-HffIDcwsyYlGssvRYS3OAEloLCID6dCIHQeZ_WQ5W-fy9B3rC4uxbUKVBGzyPVn4uBra4ot0hCS71JC3NNy7nBVXRxzR4z06p3fVQKSIjn5t_fFr3dzrMICa5qNUVRnYHEAv&sig=AHIEtbRX7G0XgBl1mKxnPINiorZvNhW32Q Henrik Baerbak Christensen, <i>"Implications of Perspective in Teaching Objects First and Object Design"</i>, Proceedings of the 10th annual <i>SIGCSE</i> conference on Innovation and technology in computer science education, Department of Computer Science, University of Aarhus, 2005.]</ref>===		===Model-centric perspective<ref>[https://docs.google.com/viewer?a=v&q=cache:Kl7VOfRFnNEJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.86.7500%26rep%3Drep1%26type%3Dpdf+%22language+centric%22+object+oriented+design&hl=en&gl=us&pid=bl&srcid=ADGEESj-HffIDcwsyYlGssvRYS3OAEloLCID6dCIHQeZ_WQ5W-fy9B3rC4uxbUKVBGzyPVn4uBra4ot0hCS71JC3NNy7nBVXRxzR4z06p3fVQKSIjn5t_fFr3dzrMICa5qNUVRnYHEAv&sig=AHIEtbRX7G0XgBl1mKxnPINiorZvNhW32Q Henrik Baerbak Christensen, <i>"Implications of Perspective in Teaching Objects First and Object Design"</i>, Proceedings of the 10th annual <i>SIGCSE</i> conference on Innovation and technology in computer science education, Department of Computer Science, University of Aarhus, 2005.]</ref>===

Rbettad: /* Background */

2012-10-26T21:53:56Z

Background

← Older revision		Revision as of 21:53, 26 October 2012
Line 3:		Line 3:

	==Background==		==Background==
	The history of object oriented design has many branches, and many people have contributed to this domain. The 1960s and 1970s saw the emergence of object oriented programming languages, such as Simula and Smalltalk, with key contributors such as Kristen Nygaard and Alan Kay, the visionary computer scientist who ~~founded~~ Smalltalk.<ref>[http://www.informit.com/articles/article.aspx?p=360440&seqNum=8 History of Object Oriented Design]</ref>		The history of object oriented design has many branches, and many people have contributed to this domain. The 1960s and 1970s saw the emergence of [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages object oriented programming languages], such as [http://en.wikipedia.org/wiki/Simula Simula] and [http://en.wikipedia.org/wiki/Smalltalk Smalltalk], with key contributors such as Kristen Nygaard and Alan Kay, the visionary computer scientist who found Smalltalk.<ref>[http://www.informit.com/articles/article.aspx?p=360440&seqNum=8 History of Object Oriented Design]</ref>
	But object oriented design was informal through that period, and it was only form 1982 that it became popular. Contributors in this domain include Grady Booch, Kent Beck, Peter Coad, Don Firesmith, Ivar Jacobson (a UML founder), Steve Mellor, Bertrand Meyer, Jim Rumbaugh (a UML founder) and Rebecca Wirfs-Brock among others~~. Each of these perspectives are outlined in the following sections~~.		But object oriented design was informal through that period, and it was only form 1982 that it became popular. Contributors in this domain include Grady Booch, Kent Beck, Peter Coad, Don Firesmith, Ivar Jacobson (a UML founder), Steve Mellor, Bertrand Meyer, Jim Rumbaugh (a UML founder) and Rebecca Wirfs-Brock among others.

	==Object Oriented Design Perspectives==		==Object Oriented Design Perspectives==