Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T17:05:35Z

Rchakar:

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities <ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false</ref>===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

Responsibilities come from statements or implications of system behavior found in use cases. There is a gap between use case descriptions and object responsibilities. Responsibilities are general statements about what an object knows, does, or decides. Use case descriptions are statements about our system's behavior and how actors interact with it. Use cases describe our software from the perspective of an outside observer. They don't tell how something is accomplished. Use cases provide a rough idea of how our system will work and the tasks involved. As
designers we bridge this gap by transforming descriptions found in use cases into explicit statements about actions, information, or decision-making responsibilities. This is a three-step process:
*Identify things the system does and information it manages.
*Restate these as responsibilities.
*Break them down into smaller parts if necessary, and assign them to appropriate objects.

=== Behavior <ref>http://csis.pace.edu/~bergin/patterns/design.html</ref>===
Behavior means activity. It also means having information that other objects may need. In this case the behavior is providing that information.
In Mancala, the players play the game, for example. A pit might "know" how many pebbles it contains and it might be asked by another object like a player how many it holds.

<pre>"Taking turn" is the behavior a player in 2 player games.</pre>

=== Protocols <ref>http://en.wikipedia.org/wiki/Protocol_(object-oriented_programming)</ref>===
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], a '''protocol''' or '''interface''' is a common means for unrelated objects to communicate with each other. When objects do collaborate, they are designed to follow certain protocols and observe specific conventions: Make requests only for advertised services. Provide appropriate information. Use services under certain conditions. Finally, accept the consequences of using them. Object contracts should describe all these terms.

The protocol is a description of:
* The messages that are understood by the object.
* The arguments that these messages may be supplied with.
* The types of results that these messages return.
* The [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants] that are preserved despite modifications to the state of an object.
* The exceptional situations that will be required to be handled by clients to the object.

==Conclusion==
In this article we have discussed different object-oriented design perspectives, such as, language-centric, model-centric and responsibility-centric. We have also described the concepts of behavior, responsibilities, roles and protocols. The highlight of the second part is the relation between role and object.

==References==
<references />

==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T16:57:03Z

Rchakar:

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities <ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false</ref>===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

Responsibilities come from statements or implications of system behavior found in use cases. There is a gap between use case descriptions and object responsibilities. Responsibilities are general statements about what an object knows, does, or decides. Use case descriptions are statements about our system's behavior and how actors interact with it. Use cases describe our software from the perspective of an outside observer. They don't tell how something is accomplished. Use cases provide a rough idea of how our system will work and the tasks involved. As
designers we bridge this gap by transforming descriptions found in use cases into explicit statements about actions, information, or decision-making responsibilities. This is a three-step process:
*Identify things the system does and information it manages.
*Restate these as responsibilities.
*Break them down into smaller parts if necessary, and assign them to appropriate objects.

=== Behavior <ref>http://csis.pace.edu/~bergin/patterns/design.html</ref>===
Behavior means activity. It also means having information that other objects may need. In this case the behavior is providing that information.
In Mancala, the players play the game, for example. A pit might "know" how many pebbles it contains and it might be asked by another object like a player how many it holds.

<pre>"Taking turn" is the behavior a player in 2 player games.</pre>

=== Protocols <ref>http://en.wikipedia.org/wiki/Protocol_(object-oriented_programming)</ref>===
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], a '''protocol''' or '''interface''' is a common means for unrelated objects to communicate with each other. When objects do collaborate, they are designed to follow certain protocols and observe specific conventions: Make requests only for advertised services. Provide appropriate information. Use services under certain conditions. Finally, accept the consequences of using them. Object contracts should describe all these terms.

The protocol is a description of:
* The messages that are understood by the object.
* The arguments that these messages may be supplied with.
* The types of results that these messages return.
* The [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants] that are preserved despite modifications to the state of an object.
* The exceptional situations that will be required to be handled by clients to the object.

==Conclusion==
In this article we have discussed different object-oriented design perspectives, such as, language-centric, model-centric and responsibility-centric. We have also described the concepts of behavior, responsibilities, roles and protocols.

==References==
<references />

==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T16:37:21Z

Rchakar: /* Behavior http://csis.pace.edu/~bergin/patterns/design.html */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities <ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false</ref>===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

Responsibilities come from statements or implications of system behavior found in use cases. There is a gap between use case descriptions and object responsibilities. Responsibilities are general statements about what an object knows, does, or decides. Use case descriptions are statements about our system's behavior and how actors interact with it. Use cases describe our software from the perspective of an outside observer. They don't tell how something is accomplished. Use cases provide a rough idea of how our system will work and the tasks involved. As
designers we bridge this gap by transforming descriptions found in use cases into explicit statements about actions, information, or decision-making responsibilities. This is a three-step process:
*Identify things the system does and information it manages.
*Restate these as responsibilities.
*Break them down into smaller parts if necessary, and assign them to appropriate objects.

=== Behavior <ref>http://csis.pace.edu/~bergin/patterns/design.html</ref>===
Behavior means activity. It also means having information that other objects may need. In this case the behavior is providing that information.
In Mancala, the players play the game, for example. A pit might "know" how many pebbles it contains and it might be asked by another object like a player how many it holds.

<pre>"Taking turn" is the behavior a player in 2 player games.</pre>

=== Protocols <ref>http://en.wikipedia.org/wiki/Protocol_(object-oriented_programming)</ref>===
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], a '''protocol''' or '''interface''' is a common means for unrelated objects to communicate with each other. When objects do collaborate, they are designed to follow certain protocols and observe specific conventions: Make requests only for advertised services. Provide appropriate information. Use services under certain conditions. Finally, accept the consequences of using them. Object contracts should describe all these terms.

The protocol is a description of:
* The messages that are understood by the object.
* The arguments that these messages may be supplied with.
* The types of results that these messages return.
* The [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants] that are preserved despite modifications to the state of an object.
* The exceptional situations that will be required to be handled by clients to the object.

==References==
<references />

==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T08:15:35Z

Rchakar: /* Behavior */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities <ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false</ref>===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

Responsibilities come from statements or implications of system behavior found in use cases. There is a gap between use case descriptions and object responsibilities. Responsibilities are general statements about what an object knows, does, or decides. Use case descriptions are statements about our system's behavior and how actors interact with it. Use cases describe our software from the perspective of an outside observer. They don't tell how something is accomplished. Use cases provide a rough idea of how our system will work and the tasks involved. As
designers we bridge this gap by transforming descriptions found in use cases into explicit statements about actions, information, or decision-making responsibilities. This is a three-step process:
*Identify things the system does and information it manages.
*Restate these as responsibilities.
*Break them down into smaller parts if necessary, and assign them to appropriate objects.

=== Behavior <ref>http://csis.pace.edu/~bergin/patterns/design.html</ref>===
Behavior means activity. It also means having information that other objects may need. In this case the behavior is providing that information.
In Mancala, the players play the game, for example. A pit might "know" how many pebbles it contains and it might be asked by another object like a player how many it holds.

<pre>For example, in Mancala the player has behavior "take turn."</pre>

=== Protocols <ref>http://en.wikipedia.org/wiki/Protocol_(object-oriented_programming)</ref>===
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], a '''protocol''' or '''interface''' is a common means for unrelated objects to communicate with each other. When objects do collaborate, they are designed to follow certain protocols and observe specific conventions: Make requests only for advertised services. Provide appropriate information. Use services under certain conditions. Finally, accept the consequences of using them. Object contracts should describe all these terms.

The protocol is a description of:
* The messages that are understood by the object.
* The arguments that these messages may be supplied with.
* The types of results that these messages return.
* The [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants] that are preserved despite modifications to the state of an object.
* The exceptional situations that will be required to be handled by clients to the object.

==References==
<references />

==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T08:06:51Z

Rchakar: /* Object Oriented Design Concepts http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities <ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false</ref>===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

Responsibilities come from statements or implications of system behavior found in use cases. There is a gap between use case descriptions and object responsibilities. Responsibilities are general statements about what an object knows, does, or decides. Use case descriptions are statements about our system's behavior and how actors interact with it. Use cases describe our software from the perspective of an outside observer. They don't tell how something is accomplished. Use cases provide a rough idea of how our system will work and the tasks involved. As
designers we bridge this gap by transforming descriptions found in use cases into explicit statements about actions, information, or decision-making responsibilities. This is a three-step process:
*Identify things the system does and information it manages.
*Restate these as responsibilities.
*Break them down into smaller parts if necessary, and assign them to appropriate objects.

=== Behavior ===

=== Protocols <ref>http://en.wikipedia.org/wiki/Protocol_(object-oriented_programming)</ref>===
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], a '''protocol''' or '''interface''' is a common means for unrelated objects to communicate with each other. When objects do collaborate, they are designed to follow certain protocols and observe specific conventions: Make requests only for advertised services. Provide appropriate information. Use services under certain conditions. Finally, accept the consequences of using them. Object contracts should describe all these terms.

The protocol is a description of:
* The messages that are understood by the object.
* The arguments that these messages may be supplied with.
* The types of results that these messages return.
* The [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants] that are preserved despite modifications to the state of an object.
* The exceptional situations that will be required to be handled by clients to the object.

==References==
<references />

==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T08:06:05Z

Rchakar:

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities <ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false</ref>===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

Responsibilities come from statements or implications of system behavior found in use cases. There is a gap between use case descriptions and object responsibilities. Responsibilities are general statements about what an object knows, does, or decides. Use case descriptions are statements about our system's behavior and how actors interact with it. Use cases describe our software from the perspective of an outside observer. They don't tell how something is accomplished. Use cases provide a rough idea of how our system will work and the tasks involved. As
designers we bridge this gap by transforming descriptions found in use cases into explicit statements about actions, information, or decision-making responsibilities. This is a three-step process:
*Identify things the system does and information it manages.
*Restate these as responsibilities.
*Break them down into smaller parts if necessary, and assign them to appropriate objects.

=== Behavior ===

=== Protocols <ref>http://en.wikipedia.org/wiki/Protocol_(object-oriented_programming)</ref>===
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], a '''protocol''' or '''interface''' is a common means for unrelated objects to communicate with each other. When objects do collaborate, they are designed to follow certain protocols and observe specific conventions: Make requests only for advertised services. Provide appropriate information. Use services under certain conditions. Finally, accept the consequences of using them. Object contracts should describe all these terms.

The protocol is a description of:
* The messages that are understood by the object.
* The arguments that these messages may be supplied with.
* The types of results that these messages return.
* The [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants] that are preserved despite modifications to the state of an object.
* The exceptional situations that will be required to be handled by clients to the object.

==References==
<references />

==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T08:05:42Z

Rchakar: /* Protocols */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities <ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false</ref>===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

Responsibilities come from statements or implications of system behavior found in use cases. There is a gap between use case descriptions and object responsibilities. Responsibilities are general statements about what an object knows, does, or decides. Use case descriptions are statements about our system's behavior and how actors interact with it. Use cases describe our software from the perspective of an outside observer. They don't tell how something is accomplished. Use cases provide a rough idea of how our system will work and the tasks involved. As
designers we bridge this gap by transforming descriptions found in use cases into explicit statements about actions, information, or decision-making responsibilities. This is a three-step process:
*Identify things the system does and information it manages.
*Restate these as responsibilities.
*Break them down into smaller parts if necessary, and assign them to appropriate objects.

=== Behavior ===

=== Protocols <ref>http://en.wikipedia.org/wiki/Protocol_(object-oriented_programming)</ref>===
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], a '''protocol''' or '''interface''' is a common means for unrelated objects to communicate with each other. When objects do collaborate, they are designed to follow certain protocols and observe specific conventions: Make requests only for advertised services. Provide appropriate information. Use services under certain conditions. Finally, accept the consequences of using them. Object contracts should describe all these terms.

The protocol is a description of:
* The messages that are understood by the object.
* The arguments that these messages may be supplied with.
* The types of results that these messages return.
* The [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants] that are preserved despite modifications to the state of an object.
* The exceptional situations that will be required to be handled by clients to the object.

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T07:26:04Z

Rchakar: /* Object Oriented Design Concepts http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities <ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false</ref>===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

Responsibilities come from statements or implications of system behavior found in use cases. There is a gap between use case descriptions and object responsibilities. Responsibilities are general statements about what an object knows, does, or decides. Use case descriptions are statements about our system's behavior and how actors interact with it. Use cases describe our software from the perspective of an outside observer. They don't tell how something is accomplished. Use cases provide a rough idea of how our system will work and the tasks involved. As
designers we bridge this gap by transforming descriptions found in use cases into explicit statements about actions, information, or decision-making responsibilities. This is a three-step process:
*Identify things the system does and information it manages.
*Restate these as responsibilities.
*Break them down into smaller parts if necessary, and assign them to appropriate objects.

=== Behavior ===

=== Protocols ===

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T07:24:38Z

Rchakar: /* Object Oriented Design Concepts http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities <ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false</ref>===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

Responsibilities come from statements or implications of system behavior found in use cases. There is a gap between use case descriptions and object responsibilities. Responsibilities are general statements about what an object knows, does, or decides. Use case descriptions are statements about our system's behavior and how actors interact with it. Use cases describe our software from the perspective of an outside observer. They don't tell how something is accomplished. Use cases provide a rough idea of how our system will work and the tasks involved. As
designers we bridge this gap by transforming descriptions found in use cases into explicit statements about actions, information, or decision-making responsibilities. This is a three-step process:
*Identify things the system does and information it manages.
*Restate these as responsibilities.
*Break them down into smaller parts if necessary, and assign them to appropriate objects.

=== Behavior ===

=== Protocols ===

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T07:24:06Z

Rchakar: /* Object Oriented Design Concepts http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities <ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false</ref>===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

Responsibilities come from statements or implications of system behavior found in use cases. There is a gap between use case descriptions and object responsibilities. Responsibilities are general statements about what an object knows, does, or decides. Use case descriptions are statements about our system's behavior and how actors interact with it. Use cases describe our software from the perspective of an outside observer. They don't tell how something is accomplished. Use cases provide a rough idea of how our system will work and the tasks involved. As
designers we bridge this gap by transforming descriptions found in use cases into explicit statements about actions, information, or decision-making responsibilities. This is a three-step process:
*Identify things the system does and information it manages.
*Restate these as responsibilities.
*Break them down into smaller parts if necessary, and assign them to appropriate objects.

=== Behavior ===

=== Protocols ===

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T07:22:07Z

Rchakar: /* Responsibilities http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities <ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false</ref>===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

Responsibilities come from statements or implications of system behavior found in use cases. There is a gap between use case descriptions and object responsibilities. Responsibilities are general statements about what an object knows, does, or decides. Use case descriptions are statements about our system's behavior and how actors interact with it. Use cases describe our software from the perspective of an outside observer. They don't tell how something is accomplished. Use cases provide a rough idea of how our system will work and the tasks involved. As
designers we bridge this gap by transforming descriptions found in use cases into explicit statements about actions, information, or decision-making responsibilities. This is a three-step process:
*Identify things the system does and information it manages.
*Restate these as responsibilities.
*Break them down into smaller parts if necessary, and assign them to appropriate objects.

=== Behavior ===

=== Protocols ===

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:56:10Z

Rchakar: /* Responsibilities */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities <ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA5&source=gbs_toc_r&cad=4#v=onepage&q&f=false</ref>===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

=== Behavior ===

=== Protocols ===

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:52:29Z

Rchakar: /* Responsibilities */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities ===
An application implements a system of responsibilities. Responsibilities are assigned to roles. Roles collaborate to carry out their responsibilities. A good application is structured to effectively fulfill these responsibilities. We start design by inventing objects, assigning responsibilities to them for knowing information and doing the application's work. Collectively, these objects work together to fulfill the larger responsibilities of the application.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
An object embodies a set of roles with a designated set of responsibilities.
</pre>

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

=== Behavior ===

=== Protocols ===

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:49:46Z

Rchakar: /* Object Oriented Design Concepts http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities ===

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

=== Behavior ===

=== Protocols ===

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:49:26Z

Rchakar: /* Responsibilities */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities ===

Responsibilities are general statements about software objects. They include three major items:
*The actions an object performs
*The knowledge an object maintains
*Major decisions an object makes that affect others

<pre>
Physical objects, unlike our intelligent software objects, typically do work or hold on to things or information. A phone book is a physical object but it takes no action. A thermostat exists, and it makes decisions and sends control signals. A teakettle exists, but it does little more than act as a reservoir (and occasionally whistles to send a signal). Physical objects usually don't make informed decisions. However, a dog is man's best friend and companion and does many different things on its own behalf. Our software objects lie somewhere between these extremes: They aren't sentient beings, but they can be more or less lively, depending on what responsibilities we give them.
</pre>

=== Behavior ===

=== Protocols ===

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:46:35Z

Rchakar: /* Object Oriented Design Concepts http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Responsibilities ===

=== Behavior ===

=== Protocols ===

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:46:03Z

Rchakar: /* Roles (relation with objects) */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Behavior ===

=== Responsibilities ===

=== Roles ''(relation with objects)'' ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Protocols ===

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:45:32Z

Rchakar: /* Roles */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Behavior ===

=== Responsibilities ===

=== Roles (relation with objects) ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Protocols ===

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:39:53Z

Rchakar: /* Roles */

==Introduction==
Object-oriented design is a programming model 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, objects are containers of data and 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.

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

==Object Oriented Design Perspectives==
===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:
<pre>
public class foo
{
private int x;
public static double y;

public int double (int x)
{
return (3*x);
}
}
</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.<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, "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 of Computer Science, University of Aarhus, 2005.]</ref>

===Model-centric perspective===
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
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-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).

===Responsibility-centric perspective===
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.
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 Backgammon example can again be

== Object Oriented Design Concepts <ref>http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C</ref>==
[[File:AnObject.jpg|350px|right|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>]]

A software application is constructed from parts. These parts -software objects- interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on (see Figure 4a). If an object is designed to remember certain facts, it can use them to respond differently to future requests.

Building an object-oriented application means inventing appropriate machinery. We represent real-world information, processes, interactions, relationships, even errors, by inventing objects that don't exist in the real world. We give life and intelligence to inanimate things. We take difficult-to-comprehend real-world objects and split them into simpler, more manageable software ones. We invent new objects. Each has a specific role to play in the application. Our measure of success lies in how clearly we invent a software reality that satisfies our application's requirements—and not in how closely it resembles the real world.<ref>http://books.google.com/books?id=vUF72vN5MY8C&pg=PA3&source=gbs_toc_r&cad=4#v=onepage&q&f=false Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock, Alan McKean</ref>

'''For example''', filling out and filing a form seems simple. But to perform that task in software, behind the simple forms, the application is validating the data against business rules, reading and refreshing the persistent data, guaranteeing the consistency of the information, and managing simultaneous access by dozens of users. Software objects display information, coordinate activities, compute, or connect to services.

{| class="wikitable"
! Concept
! Short description
|-
|An object || an implementation of one or more roles.
|-
|A role || a set of related responsibilities.
|-
|A responsibility || an obligation to perform a task or know information
|}

=== Behavior ===

=== Responsibilities ===

=== Roles ===
An object has a specific purpose - a role it plays within a given context. Objects that play the same role can be interchanged. For example, there are several providers that can deliver letters and packages: DHL, FedEx, UPS, Post, Airborne. They all have the same purpose, if not the same way of carrying out their business. We choose from among them according to the requirements that you have for delivery. We pick among the mail carriers that meet your requirements.

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
A role is a set of responsibilities that can be used interchangeably.
</pre>

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. Stereotypes are characterizations of the roles needed by an application. Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:
*Information holder - knows and provides information
*Structurer - maintains relationships between objects and information about those relationships
*Service provider - performs work and, in general, offers computing services
*Coordinator - reacts to events by delegating tasks to others
*Controller - makes decisions and closely directs others' actions
*Interfacer - transforms information and requests between distinct parts of our system
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word">
Just as an actor tries to play a believable part in a play, an object takes on a character in an application by assuming responsibilities that define a meaningful role.
</pre>

=== Protocols ===

==References==
<references />
==Additional Reading==
*[http://books.google.com/books?id=VQaf_vOTDzMC&pg=PA244&lpg=PA244&dq=%22language+centric%22+%22model-centric%22+%22responsibility+centric%22+object+oriented+design&source=bl&ots=tY3C6nStiA&sig=bEO2VyjGTobxQ362Yaubi542ZTc&hl=en&sa=X&ei=f3KFUJ2-D4Ho8QTC_IHQBA&ved=0CEMQ6AEwAg#v=onepage&q=%22language%20centric%22%20%22model-centric%22%20%22responsibility%20centric%22%20object%20oriented%20design&f=false Flexible,Reliable Software using Patterns and Agile Development]
*[http://books.google.com/books?id=YnGz2ghKF-gC&pg=PA60&lpg=PA60&dq=%22language-centric%22+object+oriented+design&source=bl&ots=ko8xV4SZJs&sig=yemCujDGu_BEySZ_k32Kc0KVbgM&hl=en&sa=X&ei=K8WFUOykNYW89gTcx4GQAg&ved=0CFEQ6AEwBA#v=onepage&q=%22language-centric%22%20object%20oriented%20design&f=false Jibitesh Mishra, Ashok Mohanty, "Software Engineering"]
*[http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/ReadMe.html An Introduction to Object Oriented Programming]

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:36:58Z

Rchakar: /* Roles */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:32:10Z

Rchakar: /* Roles */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:30:03Z

Rchakar: /* Roles */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:29:25Z

Rchakar: /* Roles */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T06:23:32Z

Rchakar: /* Roles */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T04:58:31Z

Rchakar: /* Object Oriented Design Concepts http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T04:51:50Z

Rchakar: /* Object Oriented Design Concepts http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T04:49:19Z

Rchakar: /* Object Oriented Design Concepts http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T04:44:03Z

Rchakar: /* Object Oriented Design Concepts http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T04:39:49Z

Rchakar: /* Object Oriented Design Concepts */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T04:36:59Z

Rchakar: /* Object Oriented Design Concepts */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T04:26:43Z

Rchakar: /* Object Oriented Design Concepts */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T04:26:25Z

Rchakar: /* Object Oriented Design Concepts */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T04:26:11Z

Rchakar: /* Object Oriented Design Concepts */

File:AnObject.jpg

2012-10-23T04:23:39Z

Rchakar:

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T04:11:16Z

Rchakar: /* Roles http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T03:58:28Z

Rchakar: /* Object Oriented Design Concepts http://books.google.com/books/about/Object_Design.html?id=vUF72vN5MY8C */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T03:57:16Z

Rchakar: /* Object Oriented Design Concepts */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T03:52:39Z

Rchakar: /* Object Oriented Design Concepts */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T03:52:03Z

Rchakar: /* Roles */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T03:49:41Z

Rchakar: /* Object Oriented Design Concepts */

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-23T03:45:57Z

Rchakar:

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-22T16:03:12Z

Rchakar:

'''Roles and Responsibilities'''

CSC/ECE 517 Fall 2012/ch2a 2w15 rr

2012-10-22T16:02:07Z

Rchakar: Created page with "Roles and Responsibilities"

Roles and Responsibilities

CSC/ECE 517 Fall 2012

2012-10-22T15:37:11Z

Rchakar:

*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

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

CSC/ECE 517 Fall 2012/ch1 1w1 rk

2012-09-08T01:28:29Z

Rchakar: /* Git (Version control)http://en.wikipedia.org/wiki/Git_(software) */

==Introduction==
A [http://en.wikipedia.org/wiki/Revision_control version control] system '''(VCS)''' is a process for managing software codes,files and directory structures and corresponding updates made to them during software development, web development etc. project or during subsequent project maintenances. Version control is also known as revision control, source control or [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM)[6].

Any software development project is a dynamic and fast paced environment. In a typical setting, development for a project is performed simultaneously by many developers. Thus, incorporating all the changes made, either simultaneously or at different times, poses a new type of challenge.

This wikibook chapter focuses mainly on the development history of different version control systems.

==Why version control systems are needed?==
The major issues in a dynamic development environment can be described as:
* Obviously, '''merging''' of a lot of files. If we consider somebody to do merging manually, The sheer volume of communication required is overwhelming. This communication can be among the developers themselves in a small team or between the team leader in charge of merging and the rest of the group.

* '''Accountability:''' if one of the developers breaks the code flow during development, It is tough to detect and naturally nobody steps forward to take the blame. A version control system can precisely indicate who caused the break in the code.

* If a certain code implementation doesn't work as expected, '''Reverting''' to last satisfactory state may be required.

* Development on stale code may result in '''Code loss'''. for example, two developers downloaded a certain file at 10AM. One of the developers modified foo_1() method and uploaded modified file at 10:30AM.The other developer modified foo_2() method and uploaded the same file at 10:45AM. Since the functions are in the same file, the second upload will overwrite the file uploaded by first developer at 10:30AM causing loss of his part of work.

* Even a lone coder might need to '''review''' why he or she made a certain change in code. Comments during code check-in can be a useful resource in such situation.

* Version control provides a form of '''documentation''' which makes tracking easy. i.e.-'''tagging''' is a kind of snapshot of all files and documents at a particular stage of development, usually during a stable release. This allows the developers to work with the exact files that were included in that release for bug-fixing purpose.

* '''Sandboxing / Branching:''' Version control makes it possible to perform temporary code changes in an isolated area, usually in branch folder, for testing purpose. If the outcome is satisfactory then the code can be merged with the existing code, otherwise it can be discarded without having any impact on the main code.

* Now a days, software development teams are spread across different countries and work at different time zones. Use of a version control system for project aggregation becomes unavoidable.

==Evolution of version control systems==

VCS' can be broadly categorized into three groups based on the repository model. The sequence below follows the evolution of version control systems as well:

==='''Local repository model''' <ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>===
Local version control systems had one storage location of the files. It was called local because it didn't support networked commands or access like the other later softwares. So, all the developers had to use same computer system to access or modify files.

===='''Source Code Control System (SCCS)'''<ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>====
It is one of the pioneer source code revision softwares.[5] SCCS was developed at Bell Labs in 1972 by Marc J. Rochkind. Although it was originally developed for OS/MVT, SCCS was included in [http://en.wikipedia.org/wiki/Source_Code_Control_System some UNIX distributions.] SCCS ruled as the dominant VCS until ''Revision Control System'' was released.
:SCCS was the dominant version control system for Unix until the release of the [http://en.wikipedia.org/wiki/Revision_Control_System Revision Control System (RCS)]. Today, SCCS is generally considered obsolete. However, its file format is still used internally by a few other revision control programs, including [http://en.wikipedia.org/wiki/BitKeeper BitKeeper] and [http://en.wikipedia.org/wiki/TeamWare TeamWare]. The latter is a frontend to SCCS. [http://en.wikipedia.org/wiki/Sablime Sablime] has been developed from a modified version of SCCS but uses a history file format that is incompatible with SCCS. The SCCS file format uses a storage technique called [http://en.wikipedia.org/wiki/Interleaved_deltas interleaved deltas] (or the weave). This storage technique is now considered by many [http://en.wikipedia.org/wiki/Revision_control revision control] system developers as foundational to advanced merging and versioning techniques, such as the "Precise [http://en.wikipedia.org/wiki/Codeville Codeville]" ("pcdv") merge.
:'''What does a source code control system do?'''
:If you are creating or maintaining a text file---perhaps a document, or a script, or a program---a source code control system can do several things for you:
:*It can keep track of the changes made to the file: what was changed, when it was changed, and by whom.
:*It provides a version numbering scheme so you can tell which versions of a file are more recent.
:*It can retrieve previous versions of your file, so that you can retreat to an older version if you decide that the current version is a bad idea, or if you want to see some text that has since been changed or deleted.
:*If you accidentally delete the current file, you can get back the last version.
:*If several people are working with the same file, a source code control system can help you coordinate your work and keep track of who did what, and when.

SCCS is also known for the <code>sccsid</code> string, for example:

static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/11/93";

This string contains the file name, date, and can also contain a comment. After compilation, this string can be found in binary and object files by looking for the pattern "@(#)" and can be used determine which source code files were used during compilation.

===='''Control System(RCS)'''<ref>http://en.wikipedia.org/wiki/Revision_Control_System Revision</ref>====
It automated storing, retrieval, logging, identification, and merging frequent revisions of texts. RCS was first released in 1982 by Walter F. Tichy as an alternative to SCCS. It quickly gained popularity and almost replaced SCCS.[9]
:RCS performed better by storing the most recent copy of file and then storing only reverse differences called "deltas".One of the shortcomings of RCS was that only one person at a time could edit the file. RCS could manage only single files, not a whole project or directory.
:Ref.[3] is a comprehensive book on CSSC and RCS.

==='''Client-server model'''===
The [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server model] utilizes a single centralized repository for the version control which is accessible to the developers through network or internet. The below diagram [http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html] provides a high level overview of the model.
[[Image:Client_Server_Model.png |center|]]
===='''Concurrent Versions System (CVS)'''<ref>http://en.wikipedia.org/wiki/Concurrent_Versions_System</ref>====
It was one of the early client-server model based scheme. Dick Grune started developing CVS from 1984-1985 to allow his students to collaborate in a project according to their schedule. CVS was publicly released at 1986.The main improvement for CVS over RCS was that CVS could manage the whole project while RCS could only work on a file at a time.At the beginning, CVS was script based and called RCS at background. Later it was developed into a full fledged program. A lot of the IDE's (Emacs, Eclipse/aptana,Netbeans, Komodo, PHPEdit etc.) support CVS. CVSNT is a cross platform port of CVS with some modification. CVS, which was the defacto standard for version controlling for a long time is almost replaced today by SVN. There were many disadvantages of CVS which hindered its stay in the industry further. Prominent ones were
#CVS check-in is not an [http://en.wikipedia.org/wiki/Atomic_commit atomic] operation. For example, given the files 1.c, 2.c, 3.c, 4.c and if someone runs '''cvs ci 1.c 3.c''' and someone else runs cvs update at the same time, the person running update might get only the change to `3.c' and not the change to `1.c'. So, if check-in process was disturbed, it could result in damage of existing project at repository.
#CVS only tracks modification on a file-by-file basis.
#CVS was designed with only text files in mind. No native support for other formats. Extensive modification are necessary at the client and the server to support other file types.
#Conflict resolution in CVS, if not absent, is definitely not good. Conflict markers used in CVS may go unnoticed and those file might find their way into the repository.
#Slow

===='''Subversion (SVN)'''<ref>http://en.wikipedia.org/wiki/Subversion_%28software%29</ref>====
As the complexity of projects increased, the shortcomings of CVS became more and more prominent. This led to the development of Subversion. CollabNet started developing svn as a successor of CVS with added [http://en.wikipedia.org/wiki/Subversion_(software)#Features functionality][2][7]. Different open source projects (i.e.-[http://en.wikipedia.org/wiki/Apache_Software_Foundation Apache Software Foundation],[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby],[http://en.wikipedia.org/wiki/SourceForge SourceForge],[http://en.wikipedia.org/wiki/Tigris.org Tigris.org], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/Python_(programming_language) Python] and [http://en.wikipedia.org/wiki/MediaWiki MediaWiki]) use Subversion. Subversion is an open source software due to it's Apache license[1].
[[Image:Subversion_project_visualization.svg.png|650px|thumb|center|Visualization of a very simple Subversion project. Source:wikimedia commons, Explanation of terms can be found at http://en.wikipedia.org/wiki/Apache_Subversion, "Branching and tagging" and at http://en.wikipedia.org/wiki/Revision_control, #"Common vocabulary"]]

'''Features:''' <ref>http://en.wikipedia.org/wiki/Apache_Subversion#Features</ref>
* [http://en.wikipedia.org/wiki/Commit_(data_management) Commits] as true [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomic operations] (interrupted commit operations in CVS would cause repository inconsistency or corruption).
* Renamed/copied/moved/removed files retain full revision history.
* The system maintains [http://en.wikipedia.org/wiki/Software_versioning versioning] for directories, renames, and file [http://en.wikipedia.org/wiki/Metadata metadata] (but not for timestamps). Users can move and/or copy entire directory-trees very quickly, while retaining full revision history.
* Versioning of [http://en.wikipedia.org/wiki/Symbolic_link symbolic link]s.
* Native support for binary files, with space-efficient binary-diff storage.
* [http://en.wikipedia.org/wiki/Apache_HTTP_Server Apache HTTP Server] as network server, [http://en.wikipedia.org/wiki/WebDAV WebDAV]/[http://en.wikipedia.org/wiki/WebDAV#Extensions_and_derivatives Delta-V] for protocol. There is also an independent server [http://en.wikipedia.org/wiki/Process_(computing) process] called svnserve that uses a custom protocol over [http://en.wikipedia.org/wiki/Internet_Protocol_Suite TCP/IP].
* Branching as a cheap operation, independent of file size (though Subversion itself does not distinguish between a branch and a directory)
* Natively [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client–server], [http://en.wikipedia.org/wiki/Abstraction_layer layered] [http://en.wikipedia.org/wiki/Library_(computing) library] design.
* Client/server protocol sends diffs in both directions.
* Costs proportional to change size, not to data size.
* Parsable output, including XML log output.
* Open source licensed — Apache License in the projected 1.7 release; prior versions use a derivative of the Apache Software License, v1.1
* Internationalized program messages.
* File locking for unmergeable files ("reserved checkouts").
* Path-based authorization.
* Language bindings for C#, PHP, Python, Perl, Ruby, and Java.
* Full MIME support — users can view or change the MIME type of each file, with the software knowing which MIME types can have their differences from previous versions shown.
* Merge tracking - Merges between branches will be tracked, this allows automatically merging between branches without telling Subversion what (doesn't) need to be merged.

=====Eclipse Subversive - Subversion (SVN) Team Provider<ref>http://www.eclipse.org/subversive/</ref>=====
The Subversive project is aimed to integrate the Subversion (SVN) version control system with the Eclipse platform. Using the Subversive plug-in, you can work with projects stored in Subversion repositories directly from the Eclipse workbench in a way similar to work with other Eclipse version control providers, such as CVS and Git.

'''Subversive Features''': Subversive plug-in provides access to Subversion repositories from the Eclipse workbench.

*'''Full-Scale SVN Client'''
:Subversive is designed to be used as a full-featured SVN client, so you can update, commit, merge changes, work with SVN properties, view change history and perform other operations with SVN directly from the Eclipse environment.

*'''Advanced SVN Features'''
:Subversive includes several features that extend functionality of the standard SVN client. In particular, Subversive can show the SVN repository content grouped by the logical structures of trunk, branch and tag and display changes on a visual revisions graph.

*'''Seamless Integration with Eclipse'''
:Subversive is an official Eclipse project and an integral part of Eclipse Simultaneous releases. The project follows all Eclipse guidelines and requirements to deliver a quality SVN team provider plug-in similar to CVS and Git implementations.

*'''Support of the Latest SVN Versions'''
:Subversive evolves together with the Subversion project to provide Eclipse users with the features that appeared in new versions of the SVN implementation. You can use the new SVN functionality in Eclipse by installing the Early Access version of Subversive.

===='''Configuration Management Version Control (CMVC)'''<ref>http://en.wikipedia.org/wiki/IBM_Configuration_Management_Version_Control_(CMVC)</ref>====
It was developed by IBM Corporation in the mid-late 1990s and was derived in part from software purchased from HP and from IBM's internal-use-only system, IDSS. CMVC was superseded by IBM Rational ClearCase and ClearQuest. The system was used to manage the IBM OS/2 and IBM AIX source code repositories in the 1990s. It is still widely used within IBM by various teams.

One of the drawbacks of CMVC is that, once a file is checked-out by a user, it remains locked to all the other users until the either the new version is checked-in or the lock is released explicitly by the owner (user) of the lock. Some proprietary client-server based version control softwares are:
::*[http://en.wikipedia.org/wiki/Autodesk_Vault Autodesk Vault] was specifically developed for Autodesk applications.
::*[http://en.wikipedia.org/wiki/IBM_Rational_ClearCase ClearCase] was developed by IBM Rational Software. It's a Source Code Control (SCC) compliant software.
::*[http://en.wikipedia.org/wiki/Visual_SourceSafe Visual SourceSafe] is developed by Microsoft targeting small development team.
::*[http://en.wikipedia.org/wiki/Visual_Studio_Team_System Visual Studio Team System] is also developed by Microsoft targeting larger groups.

===Distributed model===
'''Distributed Version Control (DVCS)''', or '''Decentralized Version Control''' systems can have many central repositories.This is a peer to peer approach. The concept started developing at late 90's. In DVCS. Each developer works with his or her local repository and the changes are synchronized between repositories upon commit. DVCS are better suited for large teams with partially independent developers. i.e.- opensource software development.[8]
#[http://en.wikipedia.org/wiki/Monotone_%28software%29 Monotone] and [http://en.wikipedia.org/wiki/GNU_arch GNU arch] were the first generation DVCS (release:2001-2003) followed by [http://en.wikipedia.org/wiki/Darcs Darcs] (stable release:2010).[http://en.wikipedia.org/wiki/Mercurial Mercurial] , [http://en.wikipedia.org/wiki/Git_%28software%29 Git] and [http://en.wikipedia.org/wiki/Bazaar_%28software%29 Bazaar] (2005-2007) are well adopted among developers.
#[http://en.wikipedia.org/wiki/BitKeeper BitKeeper],[http://en.wikipedia.org/wiki/Code_Co-op Code Co-op], [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] are some proprietary DVCS softwares.

It should be noted that many distributed version control softwares support client-server model too.One of the benefits of DVCS is that a developer can save the source code as long as he wants even if the central repository (in client-server model) is discarded at the end of a project.

[[Image:timeline.jpg|650px|thumb|center|A generalized timeline. Source:http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av]]

====Git (Version control)<ref>http://en.wikipedia.org/wiki/Git_(software)</ref>====

Git development began after many Linux kernel developers chose to give up access to BitKeeper, a proprietary SCM system that had previously been used to maintain the project. The copyright holder of BitKeeper, Larry McVoy, had withdrawn free use of the product after he claimed that Andrew Tridgell had reverse-engineered the BitKeeper protocols.

[[Image:220px-Git_data_flow_simplified.png|650px|thumb|right|Some data flows and storage levels in the Git revision control system.]]
Git was created by [http://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] (the founder of Linux) because he really didn’t like Concurrent Versions System (CVS), which, at the time, was the most popular version control system. Torvalds wanted something to help keep versions of the kernel he was working on and he figured that he would have to build a system of his own.

Git is an open source project, and since Torvalds’ initial development, there have been many other primary authors and contributors to the project.

'''Advantages of Using Git'''
*Git is super easy to install:
*Git is easier to learn compared to other systems:
*Git is fast:
*Git is decentralized:

'''Disadvantages of Using Git'''
*'''Git has a learning curve:''' It’s one of the easier version control systems to use, any new thing you introduce to your workflow will need some learning time. Learning Git will be similar to learning a new software application such as Word or Excel.

The following Web sites provide free source code hosting for Git repositories:<ref>https://git.wiki.kernel.org/articles/g/i/t/GitHosting_2036.html</ref>
* [http://en.wikipedia.org/wiki/BerliOS BerliOS]
* [http://en.wikipedia.org/wiki/Bitbucket Bitbucket]
* [http://en.wikipedia.org/wiki/CodePlex CodePlex]<ref>{{cite news|last=Bright|first=Peter|title=Microsoft brings git support to its CodePlex hosting service|url=http://arstechnica.com/microsoft/news/2012/03/microsoft-brings-git-support-to-its-codeplex-hosting-service.ars|accessdate=23 March 2012|newspaper=Ars Technica|date=22 March 2012}}</ref>
* [http://en.wikipedia.org/wiki/GitHub GitHub]
* [http://en.wikipedia.org/wiki/Gitorious Gitorious]
* [http://en.wikipedia.org/wiki/GNU_Savannah GNU Savannah]
* [http://en.wikipedia.org/wiki/Google_Code Google Code]
* [http://en.wikipedia.org/wiki/JavaForge JavaForge] (with pull requests to control source code contribution)
* [http://en.wikipedia.org/wiki/SourceForge SourceForge]

== File Sharing Models ==
Every system that implement version controlling have to address one fundamental problem: How will the files in the repository be safely shared across users but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

Consider the scenario with two users A and B. Both of them check out the same file (same version). User A after making his modification, suppose, commits the file first. A few moments later B completes his modification. B does not have any clue about A's check-in and he happily commits his code to the repository. Now B has accidentally overwritten the changes made by A leaving the system in an inconsistent state. This problem can be solved in two different ways: 
* Lock-Modify-Unlock
* Copy-Modify-Merge 
While CMVC follows the lock-modify-unlock solution, svn follows copy-modify-merge allowing users to modify the same piece of code concurrently. 
The problem with the lock-modify-unlock model is that it's a bit restrictive and often becomes a roadblock for users:

* Locking may cause unnecessary delay and is not desired when it comes to teams/projects which have a small cycle time between releases. For example: Suppose say, user A checks out a file (locks it) and some interrupt in his work causes him to switch to another task of higher priority. There is a possibility that he forgets completely about the file that he checked out. Now, if another user B wants to edit the same file, he cannot do so, without having the administrator unlock the file for him, his hands are tied!

* Locking may cause unnecessary serialization: What if two different users A and B want to edit different non-intersecting portions of the same file? With proper merging solution in place, they could have done it easily without bothering about what the other user does with the file.

* Locking may create a false sense of security: As with any model, lock-modify-unlock approach too allows two different users to work on separate files simultaneously. However the model does not define how dependencies between files are dealt with. For example: Suppose A locks and edits file f1, while B simultaneously locks and edits file f2. If there is a function call in f1 whose definition exists in f2 but the definition is removed or the function name is changed after editing f2, they don't work together anymore. Thus, locking files by itself does not provide security against such deliberate changes. Lot of manual synchronization is needed to avoid such situations which is only going to cause delay in the development of the project.

==Use of version control in other areas ==

Now a days, many document editing softwares have adopted version control. Wikis, GoogleDoc, Microsoft Office and OpenOffice.org suite are some example softwares that can save previous document editing history.

==Other considerations==

Most open source softwares have [http://linuxmafia.com/faq/Apps/vcs.html distributions for Linux] OS. In most open source cases, Linux and windows versions are released concurrently.
Many VCS' have plugins for common IDEs like Eclipse, Visual Studio, Oracle JDeveloper etc. NetBeans IDE and Xcode has integrated version control support.

==References==
<references/>

==Additional References==

1. [http://subversion.apache.org/news.html#news-20100217. Apache Software Foundation Announcements, "Subversion becomes Apache Subversion".(2010-02-17) Accessed:September 2010 ]

2. [http://svnbook.red-bean.com/ Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. "Version Control with Subversion", an O'Reilly book available online. Accessed:September 2010]

3. [http://shop.oreilly.com/product/9781565921177.do Don Bolinger, Tan Bronson: Applying RCS and SCCS. O'Reilly Media. ISBN:978-1-56592-117-7]

4. [http://www.ericsink.com/scm/source_control.html Eric Sink: A collection of articles on source control and best practices, Accessed:September 2010]

5. [http://basepath.com/aup/talks/SCCS-Slideshow.pdf M. J. Rochkind: The Source Code Control System.] In IEEE Transactions on Software Engineering SE-1:4 (Dec. 1975), pages 364–370.

6. [http://onlinelibrary.wiley.com/doi/10.1002/bltj.2039/pdf Martin, Robert L. (2002). "Software configuration management for the 21st century". Bell Labs technical journal, Volume 2, Issue 1, page- 154.]

7. Mike Mason; Pragmatic Version Control Using Subversion; Pragmatic Bookshelf; ISBN 0-9745140-6-3 (1st edition, paperback, 2005)

8. [http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ Noah Gift,Adam Shand: Introduction to distributed version control systems (compare how to use Bazaar, Mercurial, and Git) (Apr 2009), IBM Technical Library, Accessed:September 2010 ]

9.[http://onlinelibrary.wiley.com/doi/10.1002/spe.4380150703/abstract Walter F. Tichy; Rcs - a system for version control; In Software: Practice and Experience. Volume 15, Issue 7,(July 1985) pages 637–654 ]

==See also==
[http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision control]

[http://en.wikipedia.org/wiki/List_of_revision_control_software Wikipedia: List of revision control software]

[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Wikipedia: Detail comparison of revision control softwares]

[http://www.nongnu.org/cvs/ CVS webpage]

[http://www.cs.vu.nl/~dick/ Dick Grune's website on CVS history]

[http://groups.google.com/group/mod.sources/msg/2ebab72ac0744fb8?dmode=source The original usenet post on CVS] archived at google groups.

[http://linuxmafia.com/faq/Apps/vcs.html Linux availability of various version control softwares]

CSC/ECE 517 Fall 2012/ch1 1w1 rk

2012-09-08T01:28:15Z

Rchakar: /* Git (Version control)http://en.wikipedia.org/wiki/Git_(software) */

==Introduction==
A [http://en.wikipedia.org/wiki/Revision_control version control] system '''(VCS)''' is a process for managing software codes,files and directory structures and corresponding updates made to them during software development, web development etc. project or during subsequent project maintenances. Version control is also known as revision control, source control or [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM)[6].

Any software development project is a dynamic and fast paced environment. In a typical setting, development for a project is performed simultaneously by many developers. Thus, incorporating all the changes made, either simultaneously or at different times, poses a new type of challenge.

This wikibook chapter focuses mainly on the development history of different version control systems.

==Why version control systems are needed?==
The major issues in a dynamic development environment can be described as:
* Obviously, '''merging''' of a lot of files. If we consider somebody to do merging manually, The sheer volume of communication required is overwhelming. This communication can be among the developers themselves in a small team or between the team leader in charge of merging and the rest of the group.

* '''Accountability:''' if one of the developers breaks the code flow during development, It is tough to detect and naturally nobody steps forward to take the blame. A version control system can precisely indicate who caused the break in the code.

* If a certain code implementation doesn't work as expected, '''Reverting''' to last satisfactory state may be required.

* Development on stale code may result in '''Code loss'''. for example, two developers downloaded a certain file at 10AM. One of the developers modified foo_1() method and uploaded modified file at 10:30AM.The other developer modified foo_2() method and uploaded the same file at 10:45AM. Since the functions are in the same file, the second upload will overwrite the file uploaded by first developer at 10:30AM causing loss of his part of work.

* Even a lone coder might need to '''review''' why he or she made a certain change in code. Comments during code check-in can be a useful resource in such situation.

* Version control provides a form of '''documentation''' which makes tracking easy. i.e.-'''tagging''' is a kind of snapshot of all files and documents at a particular stage of development, usually during a stable release. This allows the developers to work with the exact files that were included in that release for bug-fixing purpose.

* '''Sandboxing / Branching:''' Version control makes it possible to perform temporary code changes in an isolated area, usually in branch folder, for testing purpose. If the outcome is satisfactory then the code can be merged with the existing code, otherwise it can be discarded without having any impact on the main code.

* Now a days, software development teams are spread across different countries and work at different time zones. Use of a version control system for project aggregation becomes unavoidable.

==Evolution of version control systems==

VCS' can be broadly categorized into three groups based on the repository model. The sequence below follows the evolution of version control systems as well:

==='''Local repository model''' <ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>===
Local version control systems had one storage location of the files. It was called local because it didn't support networked commands or access like the other later softwares. So, all the developers had to use same computer system to access or modify files.

===='''Source Code Control System (SCCS)'''<ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>====
It is one of the pioneer source code revision softwares.[5] SCCS was developed at Bell Labs in 1972 by Marc J. Rochkind. Although it was originally developed for OS/MVT, SCCS was included in [http://en.wikipedia.org/wiki/Source_Code_Control_System some UNIX distributions.] SCCS ruled as the dominant VCS until ''Revision Control System'' was released.
:SCCS was the dominant version control system for Unix until the release of the [http://en.wikipedia.org/wiki/Revision_Control_System Revision Control System (RCS)]. Today, SCCS is generally considered obsolete. However, its file format is still used internally by a few other revision control programs, including [http://en.wikipedia.org/wiki/BitKeeper BitKeeper] and [http://en.wikipedia.org/wiki/TeamWare TeamWare]. The latter is a frontend to SCCS. [http://en.wikipedia.org/wiki/Sablime Sablime] has been developed from a modified version of SCCS but uses a history file format that is incompatible with SCCS. The SCCS file format uses a storage technique called [http://en.wikipedia.org/wiki/Interleaved_deltas interleaved deltas] (or the weave). This storage technique is now considered by many [http://en.wikipedia.org/wiki/Revision_control revision control] system developers as foundational to advanced merging and versioning techniques, such as the "Precise [http://en.wikipedia.org/wiki/Codeville Codeville]" ("pcdv") merge.
:'''What does a source code control system do?'''
:If you are creating or maintaining a text file---perhaps a document, or a script, or a program---a source code control system can do several things for you:
:*It can keep track of the changes made to the file: what was changed, when it was changed, and by whom.
:*It provides a version numbering scheme so you can tell which versions of a file are more recent.
:*It can retrieve previous versions of your file, so that you can retreat to an older version if you decide that the current version is a bad idea, or if you want to see some text that has since been changed or deleted.
:*If you accidentally delete the current file, you can get back the last version.
:*If several people are working with the same file, a source code control system can help you coordinate your work and keep track of who did what, and when.

SCCS is also known for the <code>sccsid</code> string, for example:

static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/11/93";

This string contains the file name, date, and can also contain a comment. After compilation, this string can be found in binary and object files by looking for the pattern "@(#)" and can be used determine which source code files were used during compilation.

===='''Control System(RCS)'''<ref>http://en.wikipedia.org/wiki/Revision_Control_System Revision</ref>====
It automated storing, retrieval, logging, identification, and merging frequent revisions of texts. RCS was first released in 1982 by Walter F. Tichy as an alternative to SCCS. It quickly gained popularity and almost replaced SCCS.[9]
:RCS performed better by storing the most recent copy of file and then storing only reverse differences called "deltas".One of the shortcomings of RCS was that only one person at a time could edit the file. RCS could manage only single files, not a whole project or directory.
:Ref.[3] is a comprehensive book on CSSC and RCS.

==='''Client-server model'''===
The [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server model] utilizes a single centralized repository for the version control which is accessible to the developers through network or internet. The below diagram [http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html] provides a high level overview of the model.
[[Image:Client_Server_Model.png |center|]]
===='''Concurrent Versions System (CVS)'''<ref>http://en.wikipedia.org/wiki/Concurrent_Versions_System</ref>====
It was one of the early client-server model based scheme. Dick Grune started developing CVS from 1984-1985 to allow his students to collaborate in a project according to their schedule. CVS was publicly released at 1986.The main improvement for CVS over RCS was that CVS could manage the whole project while RCS could only work on a file at a time.At the beginning, CVS was script based and called RCS at background. Later it was developed into a full fledged program. A lot of the IDE's (Emacs, Eclipse/aptana,Netbeans, Komodo, PHPEdit etc.) support CVS. CVSNT is a cross platform port of CVS with some modification. CVS, which was the defacto standard for version controlling for a long time is almost replaced today by SVN. There were many disadvantages of CVS which hindered its stay in the industry further. Prominent ones were
#CVS check-in is not an [http://en.wikipedia.org/wiki/Atomic_commit atomic] operation. For example, given the files 1.c, 2.c, 3.c, 4.c and if someone runs '''cvs ci 1.c 3.c''' and someone else runs cvs update at the same time, the person running update might get only the change to `3.c' and not the change to `1.c'. So, if check-in process was disturbed, it could result in damage of existing project at repository.
#CVS only tracks modification on a file-by-file basis.
#CVS was designed with only text files in mind. No native support for other formats. Extensive modification are necessary at the client and the server to support other file types.
#Conflict resolution in CVS, if not absent, is definitely not good. Conflict markers used in CVS may go unnoticed and those file might find their way into the repository.
#Slow

===='''Subversion (SVN)'''<ref>http://en.wikipedia.org/wiki/Subversion_%28software%29</ref>====
As the complexity of projects increased, the shortcomings of CVS became more and more prominent. This led to the development of Subversion. CollabNet started developing svn as a successor of CVS with added [http://en.wikipedia.org/wiki/Subversion_(software)#Features functionality][2][7]. Different open source projects (i.e.-[http://en.wikipedia.org/wiki/Apache_Software_Foundation Apache Software Foundation],[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby],[http://en.wikipedia.org/wiki/SourceForge SourceForge],[http://en.wikipedia.org/wiki/Tigris.org Tigris.org], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/Python_(programming_language) Python] and [http://en.wikipedia.org/wiki/MediaWiki MediaWiki]) use Subversion. Subversion is an open source software due to it's Apache license[1].
[[Image:Subversion_project_visualization.svg.png|650px|thumb|center|Visualization of a very simple Subversion project. Source:wikimedia commons, Explanation of terms can be found at http://en.wikipedia.org/wiki/Apache_Subversion, "Branching and tagging" and at http://en.wikipedia.org/wiki/Revision_control, #"Common vocabulary"]]

'''Features:''' <ref>http://en.wikipedia.org/wiki/Apache_Subversion#Features</ref>
* [http://en.wikipedia.org/wiki/Commit_(data_management) Commits] as true [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomic operations] (interrupted commit operations in CVS would cause repository inconsistency or corruption).
* Renamed/copied/moved/removed files retain full revision history.
* The system maintains [http://en.wikipedia.org/wiki/Software_versioning versioning] for directories, renames, and file [http://en.wikipedia.org/wiki/Metadata metadata] (but not for timestamps). Users can move and/or copy entire directory-trees very quickly, while retaining full revision history.
* Versioning of [http://en.wikipedia.org/wiki/Symbolic_link symbolic link]s.
* Native support for binary files, with space-efficient binary-diff storage.
* [http://en.wikipedia.org/wiki/Apache_HTTP_Server Apache HTTP Server] as network server, [http://en.wikipedia.org/wiki/WebDAV WebDAV]/[http://en.wikipedia.org/wiki/WebDAV#Extensions_and_derivatives Delta-V] for protocol. There is also an independent server [http://en.wikipedia.org/wiki/Process_(computing) process] called svnserve that uses a custom protocol over [http://en.wikipedia.org/wiki/Internet_Protocol_Suite TCP/IP].
* Branching as a cheap operation, independent of file size (though Subversion itself does not distinguish between a branch and a directory)
* Natively [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client–server], [http://en.wikipedia.org/wiki/Abstraction_layer layered] [http://en.wikipedia.org/wiki/Library_(computing) library] design.
* Client/server protocol sends diffs in both directions.
* Costs proportional to change size, not to data size.
* Parsable output, including XML log output.
* Open source licensed — Apache License in the projected 1.7 release; prior versions use a derivative of the Apache Software License, v1.1
* Internationalized program messages.
* File locking for unmergeable files ("reserved checkouts").
* Path-based authorization.
* Language bindings for C#, PHP, Python, Perl, Ruby, and Java.
* Full MIME support — users can view or change the MIME type of each file, with the software knowing which MIME types can have their differences from previous versions shown.
* Merge tracking - Merges between branches will be tracked, this allows automatically merging between branches without telling Subversion what (doesn't) need to be merged.

=====Eclipse Subversive - Subversion (SVN) Team Provider<ref>http://www.eclipse.org/subversive/</ref>=====
The Subversive project is aimed to integrate the Subversion (SVN) version control system with the Eclipse platform. Using the Subversive plug-in, you can work with projects stored in Subversion repositories directly from the Eclipse workbench in a way similar to work with other Eclipse version control providers, such as CVS and Git.

'''Subversive Features''': Subversive plug-in provides access to Subversion repositories from the Eclipse workbench.

*'''Full-Scale SVN Client'''
:Subversive is designed to be used as a full-featured SVN client, so you can update, commit, merge changes, work with SVN properties, view change history and perform other operations with SVN directly from the Eclipse environment.

*'''Advanced SVN Features'''
:Subversive includes several features that extend functionality of the standard SVN client. In particular, Subversive can show the SVN repository content grouped by the logical structures of trunk, branch and tag and display changes on a visual revisions graph.

*'''Seamless Integration with Eclipse'''
:Subversive is an official Eclipse project and an integral part of Eclipse Simultaneous releases. The project follows all Eclipse guidelines and requirements to deliver a quality SVN team provider plug-in similar to CVS and Git implementations.

*'''Support of the Latest SVN Versions'''
:Subversive evolves together with the Subversion project to provide Eclipse users with the features that appeared in new versions of the SVN implementation. You can use the new SVN functionality in Eclipse by installing the Early Access version of Subversive.

===='''Configuration Management Version Control (CMVC)'''<ref>http://en.wikipedia.org/wiki/IBM_Configuration_Management_Version_Control_(CMVC)</ref>====
It was developed by IBM Corporation in the mid-late 1990s and was derived in part from software purchased from HP and from IBM's internal-use-only system, IDSS. CMVC was superseded by IBM Rational ClearCase and ClearQuest. The system was used to manage the IBM OS/2 and IBM AIX source code repositories in the 1990s. It is still widely used within IBM by various teams.

One of the drawbacks of CMVC is that, once a file is checked-out by a user, it remains locked to all the other users until the either the new version is checked-in or the lock is released explicitly by the owner (user) of the lock. Some proprietary client-server based version control softwares are:
::*[http://en.wikipedia.org/wiki/Autodesk_Vault Autodesk Vault] was specifically developed for Autodesk applications.
::*[http://en.wikipedia.org/wiki/IBM_Rational_ClearCase ClearCase] was developed by IBM Rational Software. It's a Source Code Control (SCC) compliant software.
::*[http://en.wikipedia.org/wiki/Visual_SourceSafe Visual SourceSafe] is developed by Microsoft targeting small development team.
::*[http://en.wikipedia.org/wiki/Visual_Studio_Team_System Visual Studio Team System] is also developed by Microsoft targeting larger groups.

===Distributed model===
'''Distributed Version Control (DVCS)''', or '''Decentralized Version Control''' systems can have many central repositories.This is a peer to peer approach. The concept started developing at late 90's. In DVCS. Each developer works with his or her local repository and the changes are synchronized between repositories upon commit. DVCS are better suited for large teams with partially independent developers. i.e.- opensource software development.[8]
#[http://en.wikipedia.org/wiki/Monotone_%28software%29 Monotone] and [http://en.wikipedia.org/wiki/GNU_arch GNU arch] were the first generation DVCS (release:2001-2003) followed by [http://en.wikipedia.org/wiki/Darcs Darcs] (stable release:2010).[http://en.wikipedia.org/wiki/Mercurial Mercurial] , [http://en.wikipedia.org/wiki/Git_%28software%29 Git] and [http://en.wikipedia.org/wiki/Bazaar_%28software%29 Bazaar] (2005-2007) are well adopted among developers.
#[http://en.wikipedia.org/wiki/BitKeeper BitKeeper],[http://en.wikipedia.org/wiki/Code_Co-op Code Co-op], [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] are some proprietary DVCS softwares.

It should be noted that many distributed version control softwares support client-server model too.One of the benefits of DVCS is that a developer can save the source code as long as he wants even if the central repository (in client-server model) is discarded at the end of a project.

[[Image:timeline.jpg|650px|thumb|center|A generalized timeline. Source:http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av]]

====Git (Version control)<ref>http://en.wikipedia.org/wiki/Git_(software)</ref>====

Git development began after many Linux kernel developers chose to give up access to BitKeeper, a proprietary SCM system that had previously been used to maintain the project. The copyright holder of BitKeeper, Larry McVoy, had withdrawn free use of the product after he claimed that Andrew Tridgell had reverse-engineered the BitKeeper protocols.

[[Image:220px-Git_data_flow_simplified.png|600px|thumb|right|Some data flows and storage levels in the Git revision control system.]]
Git was created by [http://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] (the founder of Linux) because he really didn’t like Concurrent Versions System (CVS), which, at the time, was the most popular version control system. Torvalds wanted something to help keep versions of the kernel he was working on and he figured that he would have to build a system of his own.

Git is an open source project, and since Torvalds’ initial development, there have been many other primary authors and contributors to the project.

'''Advantages of Using Git'''
*Git is super easy to install:
*Git is easier to learn compared to other systems:
*Git is fast:
*Git is decentralized:

'''Disadvantages of Using Git'''
*'''Git has a learning curve:''' It’s one of the easier version control systems to use, any new thing you introduce to your workflow will need some learning time. Learning Git will be similar to learning a new software application such as Word or Excel.

The following Web sites provide free source code hosting for Git repositories:<ref>https://git.wiki.kernel.org/articles/g/i/t/GitHosting_2036.html</ref>
* [http://en.wikipedia.org/wiki/BerliOS BerliOS]
* [http://en.wikipedia.org/wiki/Bitbucket Bitbucket]
* [http://en.wikipedia.org/wiki/CodePlex CodePlex]<ref>{{cite news|last=Bright|first=Peter|title=Microsoft brings git support to its CodePlex hosting service|url=http://arstechnica.com/microsoft/news/2012/03/microsoft-brings-git-support-to-its-codeplex-hosting-service.ars|accessdate=23 March 2012|newspaper=Ars Technica|date=22 March 2012}}</ref>
* [http://en.wikipedia.org/wiki/GitHub GitHub]
* [http://en.wikipedia.org/wiki/Gitorious Gitorious]
* [http://en.wikipedia.org/wiki/GNU_Savannah GNU Savannah]
* [http://en.wikipedia.org/wiki/Google_Code Google Code]
* [http://en.wikipedia.org/wiki/JavaForge JavaForge] (with pull requests to control source code contribution)
* [http://en.wikipedia.org/wiki/SourceForge SourceForge]

== File Sharing Models ==
Every system that implement version controlling have to address one fundamental problem: How will the files in the repository be safely shared across users but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

Consider the scenario with two users A and B. Both of them check out the same file (same version). User A after making his modification, suppose, commits the file first. A few moments later B completes his modification. B does not have any clue about A's check-in and he happily commits his code to the repository. Now B has accidentally overwritten the changes made by A leaving the system in an inconsistent state. This problem can be solved in two different ways: 
* Lock-Modify-Unlock
* Copy-Modify-Merge 
While CMVC follows the lock-modify-unlock solution, svn follows copy-modify-merge allowing users to modify the same piece of code concurrently. 
The problem with the lock-modify-unlock model is that it's a bit restrictive and often becomes a roadblock for users:

* Locking may cause unnecessary delay and is not desired when it comes to teams/projects which have a small cycle time between releases. For example: Suppose say, user A checks out a file (locks it) and some interrupt in his work causes him to switch to another task of higher priority. There is a possibility that he forgets completely about the file that he checked out. Now, if another user B wants to edit the same file, he cannot do so, without having the administrator unlock the file for him, his hands are tied!

* Locking may cause unnecessary serialization: What if two different users A and B want to edit different non-intersecting portions of the same file? With proper merging solution in place, they could have done it easily without bothering about what the other user does with the file.

* Locking may create a false sense of security: As with any model, lock-modify-unlock approach too allows two different users to work on separate files simultaneously. However the model does not define how dependencies between files are dealt with. For example: Suppose A locks and edits file f1, while B simultaneously locks and edits file f2. If there is a function call in f1 whose definition exists in f2 but the definition is removed or the function name is changed after editing f2, they don't work together anymore. Thus, locking files by itself does not provide security against such deliberate changes. Lot of manual synchronization is needed to avoid such situations which is only going to cause delay in the development of the project.

==Use of version control in other areas ==

Now a days, many document editing softwares have adopted version control. Wikis, GoogleDoc, Microsoft Office and OpenOffice.org suite are some example softwares that can save previous document editing history.

==Other considerations==

Most open source softwares have [http://linuxmafia.com/faq/Apps/vcs.html distributions for Linux] OS. In most open source cases, Linux and windows versions are released concurrently.
Many VCS' have plugins for common IDEs like Eclipse, Visual Studio, Oracle JDeveloper etc. NetBeans IDE and Xcode has integrated version control support.

==References==
<references/>

==Additional References==

1. [http://subversion.apache.org/news.html#news-20100217. Apache Software Foundation Announcements, "Subversion becomes Apache Subversion".(2010-02-17) Accessed:September 2010 ]

2. [http://svnbook.red-bean.com/ Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. "Version Control with Subversion", an O'Reilly book available online. Accessed:September 2010]

3. [http://shop.oreilly.com/product/9781565921177.do Don Bolinger, Tan Bronson: Applying RCS and SCCS. O'Reilly Media. ISBN:978-1-56592-117-7]

4. [http://www.ericsink.com/scm/source_control.html Eric Sink: A collection of articles on source control and best practices, Accessed:September 2010]

5. [http://basepath.com/aup/talks/SCCS-Slideshow.pdf M. J. Rochkind: The Source Code Control System.] In IEEE Transactions on Software Engineering SE-1:4 (Dec. 1975), pages 364–370.

6. [http://onlinelibrary.wiley.com/doi/10.1002/bltj.2039/pdf Martin, Robert L. (2002). "Software configuration management for the 21st century". Bell Labs technical journal, Volume 2, Issue 1, page- 154.]

7. Mike Mason; Pragmatic Version Control Using Subversion; Pragmatic Bookshelf; ISBN 0-9745140-6-3 (1st edition, paperback, 2005)

8. [http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ Noah Gift,Adam Shand: Introduction to distributed version control systems (compare how to use Bazaar, Mercurial, and Git) (Apr 2009), IBM Technical Library, Accessed:September 2010 ]

9.[http://onlinelibrary.wiley.com/doi/10.1002/spe.4380150703/abstract Walter F. Tichy; Rcs - a system for version control; In Software: Practice and Experience. Volume 15, Issue 7,(July 1985) pages 637–654 ]

==See also==
[http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision control]

[http://en.wikipedia.org/wiki/List_of_revision_control_software Wikipedia: List of revision control software]

[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Wikipedia: Detail comparison of revision control softwares]

[http://www.nongnu.org/cvs/ CVS webpage]

[http://www.cs.vu.nl/~dick/ Dick Grune's website on CVS history]

[http://groups.google.com/group/mod.sources/msg/2ebab72ac0744fb8?dmode=source The original usenet post on CVS] archived at google groups.

[http://linuxmafia.com/faq/Apps/vcs.html Linux availability of various version control softwares]

CSC/ECE 517 Fall 2012/ch1 1w1 rk

2012-09-08T01:27:52Z

Rchakar: /* Git (Version control)http://en.wikipedia.org/wiki/Git_(software) */

==Introduction==
A [http://en.wikipedia.org/wiki/Revision_control version control] system '''(VCS)''' is a process for managing software codes,files and directory structures and corresponding updates made to them during software development, web development etc. project or during subsequent project maintenances. Version control is also known as revision control, source control or [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM)[6].

Any software development project is a dynamic and fast paced environment. In a typical setting, development for a project is performed simultaneously by many developers. Thus, incorporating all the changes made, either simultaneously or at different times, poses a new type of challenge.

This wikibook chapter focuses mainly on the development history of different version control systems.

==Why version control systems are needed?==
The major issues in a dynamic development environment can be described as:
* Obviously, '''merging''' of a lot of files. If we consider somebody to do merging manually, The sheer volume of communication required is overwhelming. This communication can be among the developers themselves in a small team or between the team leader in charge of merging and the rest of the group.

* '''Accountability:''' if one of the developers breaks the code flow during development, It is tough to detect and naturally nobody steps forward to take the blame. A version control system can precisely indicate who caused the break in the code.

* If a certain code implementation doesn't work as expected, '''Reverting''' to last satisfactory state may be required.

* Development on stale code may result in '''Code loss'''. for example, two developers downloaded a certain file at 10AM. One of the developers modified foo_1() method and uploaded modified file at 10:30AM.The other developer modified foo_2() method and uploaded the same file at 10:45AM. Since the functions are in the same file, the second upload will overwrite the file uploaded by first developer at 10:30AM causing loss of his part of work.

* Even a lone coder might need to '''review''' why he or she made a certain change in code. Comments during code check-in can be a useful resource in such situation.

* Version control provides a form of '''documentation''' which makes tracking easy. i.e.-'''tagging''' is a kind of snapshot of all files and documents at a particular stage of development, usually during a stable release. This allows the developers to work with the exact files that were included in that release for bug-fixing purpose.

* '''Sandboxing / Branching:''' Version control makes it possible to perform temporary code changes in an isolated area, usually in branch folder, for testing purpose. If the outcome is satisfactory then the code can be merged with the existing code, otherwise it can be discarded without having any impact on the main code.

* Now a days, software development teams are spread across different countries and work at different time zones. Use of a version control system for project aggregation becomes unavoidable.

==Evolution of version control systems==

VCS' can be broadly categorized into three groups based on the repository model. The sequence below follows the evolution of version control systems as well:

==='''Local repository model''' <ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>===
Local version control systems had one storage location of the files. It was called local because it didn't support networked commands or access like the other later softwares. So, all the developers had to use same computer system to access or modify files.

===='''Source Code Control System (SCCS)'''<ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>====
It is one of the pioneer source code revision softwares.[5] SCCS was developed at Bell Labs in 1972 by Marc J. Rochkind. Although it was originally developed for OS/MVT, SCCS was included in [http://en.wikipedia.org/wiki/Source_Code_Control_System some UNIX distributions.] SCCS ruled as the dominant VCS until ''Revision Control System'' was released.
:SCCS was the dominant version control system for Unix until the release of the [http://en.wikipedia.org/wiki/Revision_Control_System Revision Control System (RCS)]. Today, SCCS is generally considered obsolete. However, its file format is still used internally by a few other revision control programs, including [http://en.wikipedia.org/wiki/BitKeeper BitKeeper] and [http://en.wikipedia.org/wiki/TeamWare TeamWare]. The latter is a frontend to SCCS. [http://en.wikipedia.org/wiki/Sablime Sablime] has been developed from a modified version of SCCS but uses a history file format that is incompatible with SCCS. The SCCS file format uses a storage technique called [http://en.wikipedia.org/wiki/Interleaved_deltas interleaved deltas] (or the weave). This storage technique is now considered by many [http://en.wikipedia.org/wiki/Revision_control revision control] system developers as foundational to advanced merging and versioning techniques, such as the "Precise [http://en.wikipedia.org/wiki/Codeville Codeville]" ("pcdv") merge.
:'''What does a source code control system do?'''
:If you are creating or maintaining a text file---perhaps a document, or a script, or a program---a source code control system can do several things for you:
:*It can keep track of the changes made to the file: what was changed, when it was changed, and by whom.
:*It provides a version numbering scheme so you can tell which versions of a file are more recent.
:*It can retrieve previous versions of your file, so that you can retreat to an older version if you decide that the current version is a bad idea, or if you want to see some text that has since been changed or deleted.
:*If you accidentally delete the current file, you can get back the last version.
:*If several people are working with the same file, a source code control system can help you coordinate your work and keep track of who did what, and when.

SCCS is also known for the <code>sccsid</code> string, for example:

static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/11/93";

This string contains the file name, date, and can also contain a comment. After compilation, this string can be found in binary and object files by looking for the pattern "@(#)" and can be used determine which source code files were used during compilation.

===='''Control System(RCS)'''<ref>http://en.wikipedia.org/wiki/Revision_Control_System Revision</ref>====
It automated storing, retrieval, logging, identification, and merging frequent revisions of texts. RCS was first released in 1982 by Walter F. Tichy as an alternative to SCCS. It quickly gained popularity and almost replaced SCCS.[9]
:RCS performed better by storing the most recent copy of file and then storing only reverse differences called "deltas".One of the shortcomings of RCS was that only one person at a time could edit the file. RCS could manage only single files, not a whole project or directory.
:Ref.[3] is a comprehensive book on CSSC and RCS.

==='''Client-server model'''===
The [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server model] utilizes a single centralized repository for the version control which is accessible to the developers through network or internet. The below diagram [http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html] provides a high level overview of the model.
[[Image:Client_Server_Model.png |center|]]
===='''Concurrent Versions System (CVS)'''<ref>http://en.wikipedia.org/wiki/Concurrent_Versions_System</ref>====
It was one of the early client-server model based scheme. Dick Grune started developing CVS from 1984-1985 to allow his students to collaborate in a project according to their schedule. CVS was publicly released at 1986.The main improvement for CVS over RCS was that CVS could manage the whole project while RCS could only work on a file at a time.At the beginning, CVS was script based and called RCS at background. Later it was developed into a full fledged program. A lot of the IDE's (Emacs, Eclipse/aptana,Netbeans, Komodo, PHPEdit etc.) support CVS. CVSNT is a cross platform port of CVS with some modification. CVS, which was the defacto standard for version controlling for a long time is almost replaced today by SVN. There were many disadvantages of CVS which hindered its stay in the industry further. Prominent ones were
#CVS check-in is not an [http://en.wikipedia.org/wiki/Atomic_commit atomic] operation. For example, given the files 1.c, 2.c, 3.c, 4.c and if someone runs '''cvs ci 1.c 3.c''' and someone else runs cvs update at the same time, the person running update might get only the change to `3.c' and not the change to `1.c'. So, if check-in process was disturbed, it could result in damage of existing project at repository.
#CVS only tracks modification on a file-by-file basis.
#CVS was designed with only text files in mind. No native support for other formats. Extensive modification are necessary at the client and the server to support other file types.
#Conflict resolution in CVS, if not absent, is definitely not good. Conflict markers used in CVS may go unnoticed and those file might find their way into the repository.
#Slow

===='''Subversion (SVN)'''<ref>http://en.wikipedia.org/wiki/Subversion_%28software%29</ref>====
As the complexity of projects increased, the shortcomings of CVS became more and more prominent. This led to the development of Subversion. CollabNet started developing svn as a successor of CVS with added [http://en.wikipedia.org/wiki/Subversion_(software)#Features functionality][2][7]. Different open source projects (i.e.-[http://en.wikipedia.org/wiki/Apache_Software_Foundation Apache Software Foundation],[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby],[http://en.wikipedia.org/wiki/SourceForge SourceForge],[http://en.wikipedia.org/wiki/Tigris.org Tigris.org], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/Python_(programming_language) Python] and [http://en.wikipedia.org/wiki/MediaWiki MediaWiki]) use Subversion. Subversion is an open source software due to it's Apache license[1].
[[Image:Subversion_project_visualization.svg.png|650px|thumb|center|Visualization of a very simple Subversion project. Source:wikimedia commons, Explanation of terms can be found at http://en.wikipedia.org/wiki/Apache_Subversion, "Branching and tagging" and at http://en.wikipedia.org/wiki/Revision_control, #"Common vocabulary"]]

'''Features:''' <ref>http://en.wikipedia.org/wiki/Apache_Subversion#Features</ref>
* [http://en.wikipedia.org/wiki/Commit_(data_management) Commits] as true [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomic operations] (interrupted commit operations in CVS would cause repository inconsistency or corruption).
* Renamed/copied/moved/removed files retain full revision history.
* The system maintains [http://en.wikipedia.org/wiki/Software_versioning versioning] for directories, renames, and file [http://en.wikipedia.org/wiki/Metadata metadata] (but not for timestamps). Users can move and/or copy entire directory-trees very quickly, while retaining full revision history.
* Versioning of [http://en.wikipedia.org/wiki/Symbolic_link symbolic link]s.
* Native support for binary files, with space-efficient binary-diff storage.
* [http://en.wikipedia.org/wiki/Apache_HTTP_Server Apache HTTP Server] as network server, [http://en.wikipedia.org/wiki/WebDAV WebDAV]/[http://en.wikipedia.org/wiki/WebDAV#Extensions_and_derivatives Delta-V] for protocol. There is also an independent server [http://en.wikipedia.org/wiki/Process_(computing) process] called svnserve that uses a custom protocol over [http://en.wikipedia.org/wiki/Internet_Protocol_Suite TCP/IP].
* Branching as a cheap operation, independent of file size (though Subversion itself does not distinguish between a branch and a directory)
* Natively [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client–server], [http://en.wikipedia.org/wiki/Abstraction_layer layered] [http://en.wikipedia.org/wiki/Library_(computing) library] design.
* Client/server protocol sends diffs in both directions.
* Costs proportional to change size, not to data size.
* Parsable output, including XML log output.
* Open source licensed — Apache License in the projected 1.7 release; prior versions use a derivative of the Apache Software License, v1.1
* Internationalized program messages.
* File locking for unmergeable files ("reserved checkouts").
* Path-based authorization.
* Language bindings for C#, PHP, Python, Perl, Ruby, and Java.
* Full MIME support — users can view or change the MIME type of each file, with the software knowing which MIME types can have their differences from previous versions shown.
* Merge tracking - Merges between branches will be tracked, this allows automatically merging between branches without telling Subversion what (doesn't) need to be merged.

=====Eclipse Subversive - Subversion (SVN) Team Provider<ref>http://www.eclipse.org/subversive/</ref>=====
The Subversive project is aimed to integrate the Subversion (SVN) version control system with the Eclipse platform. Using the Subversive plug-in, you can work with projects stored in Subversion repositories directly from the Eclipse workbench in a way similar to work with other Eclipse version control providers, such as CVS and Git.

'''Subversive Features''': Subversive plug-in provides access to Subversion repositories from the Eclipse workbench.

*'''Full-Scale SVN Client'''
:Subversive is designed to be used as a full-featured SVN client, so you can update, commit, merge changes, work with SVN properties, view change history and perform other operations with SVN directly from the Eclipse environment.

*'''Advanced SVN Features'''
:Subversive includes several features that extend functionality of the standard SVN client. In particular, Subversive can show the SVN repository content grouped by the logical structures of trunk, branch and tag and display changes on a visual revisions graph.

*'''Seamless Integration with Eclipse'''
:Subversive is an official Eclipse project and an integral part of Eclipse Simultaneous releases. The project follows all Eclipse guidelines and requirements to deliver a quality SVN team provider plug-in similar to CVS and Git implementations.

*'''Support of the Latest SVN Versions'''
:Subversive evolves together with the Subversion project to provide Eclipse users with the features that appeared in new versions of the SVN implementation. You can use the new SVN functionality in Eclipse by installing the Early Access version of Subversive.

===='''Configuration Management Version Control (CMVC)'''<ref>http://en.wikipedia.org/wiki/IBM_Configuration_Management_Version_Control_(CMVC)</ref>====
It was developed by IBM Corporation in the mid-late 1990s and was derived in part from software purchased from HP and from IBM's internal-use-only system, IDSS. CMVC was superseded by IBM Rational ClearCase and ClearQuest. The system was used to manage the IBM OS/2 and IBM AIX source code repositories in the 1990s. It is still widely used within IBM by various teams.

One of the drawbacks of CMVC is that, once a file is checked-out by a user, it remains locked to all the other users until the either the new version is checked-in or the lock is released explicitly by the owner (user) of the lock. Some proprietary client-server based version control softwares are:
::*[http://en.wikipedia.org/wiki/Autodesk_Vault Autodesk Vault] was specifically developed for Autodesk applications.
::*[http://en.wikipedia.org/wiki/IBM_Rational_ClearCase ClearCase] was developed by IBM Rational Software. It's a Source Code Control (SCC) compliant software.
::*[http://en.wikipedia.org/wiki/Visual_SourceSafe Visual SourceSafe] is developed by Microsoft targeting small development team.
::*[http://en.wikipedia.org/wiki/Visual_Studio_Team_System Visual Studio Team System] is also developed by Microsoft targeting larger groups.

===Distributed model===
'''Distributed Version Control (DVCS)''', or '''Decentralized Version Control''' systems can have many central repositories.This is a peer to peer approach. The concept started developing at late 90's. In DVCS. Each developer works with his or her local repository and the changes are synchronized between repositories upon commit. DVCS are better suited for large teams with partially independent developers. i.e.- opensource software development.[8]
#[http://en.wikipedia.org/wiki/Monotone_%28software%29 Monotone] and [http://en.wikipedia.org/wiki/GNU_arch GNU arch] were the first generation DVCS (release:2001-2003) followed by [http://en.wikipedia.org/wiki/Darcs Darcs] (stable release:2010).[http://en.wikipedia.org/wiki/Mercurial Mercurial] , [http://en.wikipedia.org/wiki/Git_%28software%29 Git] and [http://en.wikipedia.org/wiki/Bazaar_%28software%29 Bazaar] (2005-2007) are well adopted among developers.
#[http://en.wikipedia.org/wiki/BitKeeper BitKeeper],[http://en.wikipedia.org/wiki/Code_Co-op Code Co-op], [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] are some proprietary DVCS softwares.

It should be noted that many distributed version control softwares support client-server model too.One of the benefits of DVCS is that a developer can save the source code as long as he wants even if the central repository (in client-server model) is discarded at the end of a project.

[[Image:timeline.jpg|650px|thumb|center|A generalized timeline. Source:http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av]]

====Git (Version control)<ref>http://en.wikipedia.org/wiki/Git_(software)</ref>====
[[Image:220px-Git_data_flow_simplified.png|600px|thumb|right|Some data flows and storage levels in the Git revision control system.]]
Git development began after many Linux kernel developers chose to give up access to BitKeeper, a proprietary SCM system that had previously been used to maintain the project. The copyright holder of BitKeeper, Larry McVoy, had withdrawn free use of the product after he claimed that Andrew Tridgell had reverse-engineered the BitKeeper protocols.

Git was created by [http://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] (the founder of Linux) because he really didn’t like Concurrent Versions System (CVS), which, at the time, was the most popular version control system. Torvalds wanted something to help keep versions of the kernel he was working on and he figured that he would have to build a system of his own.

Git is an open source project, and since Torvalds’ initial development, there have been many other primary authors and contributors to the project.

'''Advantages of Using Git'''
*Git is super easy to install:
*Git is easier to learn compared to other systems:
*Git is fast:
*Git is decentralized:

'''Disadvantages of Using Git'''
*'''Git has a learning curve:''' It’s one of the easier version control systems to use, any new thing you introduce to your workflow will need some learning time. Learning Git will be similar to learning a new software application such as Word or Excel.

The following Web sites provide free source code hosting for Git repositories:<ref>https://git.wiki.kernel.org/articles/g/i/t/GitHosting_2036.html</ref>
* [http://en.wikipedia.org/wiki/BerliOS BerliOS]
* [http://en.wikipedia.org/wiki/Bitbucket Bitbucket]
* [http://en.wikipedia.org/wiki/CodePlex CodePlex]<ref>{{cite news|last=Bright|first=Peter|title=Microsoft brings git support to its CodePlex hosting service|url=http://arstechnica.com/microsoft/news/2012/03/microsoft-brings-git-support-to-its-codeplex-hosting-service.ars|accessdate=23 March 2012|newspaper=Ars Technica|date=22 March 2012}}</ref>
* [http://en.wikipedia.org/wiki/GitHub GitHub]
* [http://en.wikipedia.org/wiki/Gitorious Gitorious]
* [http://en.wikipedia.org/wiki/GNU_Savannah GNU Savannah]
* [http://en.wikipedia.org/wiki/Google_Code Google Code]
* [http://en.wikipedia.org/wiki/JavaForge JavaForge] (with pull requests to control source code contribution)
* [http://en.wikipedia.org/wiki/SourceForge SourceForge]

== File Sharing Models ==
Every system that implement version controlling have to address one fundamental problem: How will the files in the repository be safely shared across users but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

Consider the scenario with two users A and B. Both of them check out the same file (same version). User A after making his modification, suppose, commits the file first. A few moments later B completes his modification. B does not have any clue about A's check-in and he happily commits his code to the repository. Now B has accidentally overwritten the changes made by A leaving the system in an inconsistent state. This problem can be solved in two different ways: 
* Lock-Modify-Unlock
* Copy-Modify-Merge 
While CMVC follows the lock-modify-unlock solution, svn follows copy-modify-merge allowing users to modify the same piece of code concurrently. 
The problem with the lock-modify-unlock model is that it's a bit restrictive and often becomes a roadblock for users:

* Locking may cause unnecessary delay and is not desired when it comes to teams/projects which have a small cycle time between releases. For example: Suppose say, user A checks out a file (locks it) and some interrupt in his work causes him to switch to another task of higher priority. There is a possibility that he forgets completely about the file that he checked out. Now, if another user B wants to edit the same file, he cannot do so, without having the administrator unlock the file for him, his hands are tied!

* Locking may cause unnecessary serialization: What if two different users A and B want to edit different non-intersecting portions of the same file? With proper merging solution in place, they could have done it easily without bothering about what the other user does with the file.

* Locking may create a false sense of security: As with any model, lock-modify-unlock approach too allows two different users to work on separate files simultaneously. However the model does not define how dependencies between files are dealt with. For example: Suppose A locks and edits file f1, while B simultaneously locks and edits file f2. If there is a function call in f1 whose definition exists in f2 but the definition is removed or the function name is changed after editing f2, they don't work together anymore. Thus, locking files by itself does not provide security against such deliberate changes. Lot of manual synchronization is needed to avoid such situations which is only going to cause delay in the development of the project.

==Use of version control in other areas ==

Now a days, many document editing softwares have adopted version control. Wikis, GoogleDoc, Microsoft Office and OpenOffice.org suite are some example softwares that can save previous document editing history.

==Other considerations==

Most open source softwares have [http://linuxmafia.com/faq/Apps/vcs.html distributions for Linux] OS. In most open source cases, Linux and windows versions are released concurrently.
Many VCS' have plugins for common IDEs like Eclipse, Visual Studio, Oracle JDeveloper etc. NetBeans IDE and Xcode has integrated version control support.

==References==
<references/>

==Additional References==

1. [http://subversion.apache.org/news.html#news-20100217. Apache Software Foundation Announcements, "Subversion becomes Apache Subversion".(2010-02-17) Accessed:September 2010 ]

2. [http://svnbook.red-bean.com/ Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. "Version Control with Subversion", an O'Reilly book available online. Accessed:September 2010]

3. [http://shop.oreilly.com/product/9781565921177.do Don Bolinger, Tan Bronson: Applying RCS and SCCS. O'Reilly Media. ISBN:978-1-56592-117-7]

4. [http://www.ericsink.com/scm/source_control.html Eric Sink: A collection of articles on source control and best practices, Accessed:September 2010]

5. [http://basepath.com/aup/talks/SCCS-Slideshow.pdf M. J. Rochkind: The Source Code Control System.] In IEEE Transactions on Software Engineering SE-1:4 (Dec. 1975), pages 364–370.

6. [http://onlinelibrary.wiley.com/doi/10.1002/bltj.2039/pdf Martin, Robert L. (2002). "Software configuration management for the 21st century". Bell Labs technical journal, Volume 2, Issue 1, page- 154.]

7. Mike Mason; Pragmatic Version Control Using Subversion; Pragmatic Bookshelf; ISBN 0-9745140-6-3 (1st edition, paperback, 2005)

8. [http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ Noah Gift,Adam Shand: Introduction to distributed version control systems (compare how to use Bazaar, Mercurial, and Git) (Apr 2009), IBM Technical Library, Accessed:September 2010 ]

9.[http://onlinelibrary.wiley.com/doi/10.1002/spe.4380150703/abstract Walter F. Tichy; Rcs - a system for version control; In Software: Practice and Experience. Volume 15, Issue 7,(July 1985) pages 637–654 ]

==See also==
[http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision control]

[http://en.wikipedia.org/wiki/List_of_revision_control_software Wikipedia: List of revision control software]

[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Wikipedia: Detail comparison of revision control softwares]

[http://www.nongnu.org/cvs/ CVS webpage]

[http://www.cs.vu.nl/~dick/ Dick Grune's website on CVS history]

[http://groups.google.com/group/mod.sources/msg/2ebab72ac0744fb8?dmode=source The original usenet post on CVS] archived at google groups.

[http://linuxmafia.com/faq/Apps/vcs.html Linux availability of various version control softwares]

CSC/ECE 517 Fall 2012/ch1 1w1 rk

2012-09-08T01:25:08Z

Rchakar: /* Git (Version control)http://en.wikipedia.org/wiki/Git_(software) */

==Introduction==
A [http://en.wikipedia.org/wiki/Revision_control version control] system '''(VCS)''' is a process for managing software codes,files and directory structures and corresponding updates made to them during software development, web development etc. project or during subsequent project maintenances. Version control is also known as revision control, source control or [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM)[6].

Any software development project is a dynamic and fast paced environment. In a typical setting, development for a project is performed simultaneously by many developers. Thus, incorporating all the changes made, either simultaneously or at different times, poses a new type of challenge.

This wikibook chapter focuses mainly on the development history of different version control systems.

==Why version control systems are needed?==
The major issues in a dynamic development environment can be described as:
* Obviously, '''merging''' of a lot of files. If we consider somebody to do merging manually, The sheer volume of communication required is overwhelming. This communication can be among the developers themselves in a small team or between the team leader in charge of merging and the rest of the group.

* '''Accountability:''' if one of the developers breaks the code flow during development, It is tough to detect and naturally nobody steps forward to take the blame. A version control system can precisely indicate who caused the break in the code.

* If a certain code implementation doesn't work as expected, '''Reverting''' to last satisfactory state may be required.

* Development on stale code may result in '''Code loss'''. for example, two developers downloaded a certain file at 10AM. One of the developers modified foo_1() method and uploaded modified file at 10:30AM.The other developer modified foo_2() method and uploaded the same file at 10:45AM. Since the functions are in the same file, the second upload will overwrite the file uploaded by first developer at 10:30AM causing loss of his part of work.

* Even a lone coder might need to '''review''' why he or she made a certain change in code. Comments during code check-in can be a useful resource in such situation.

* Version control provides a form of '''documentation''' which makes tracking easy. i.e.-'''tagging''' is a kind of snapshot of all files and documents at a particular stage of development, usually during a stable release. This allows the developers to work with the exact files that were included in that release for bug-fixing purpose.

* '''Sandboxing / Branching:''' Version control makes it possible to perform temporary code changes in an isolated area, usually in branch folder, for testing purpose. If the outcome is satisfactory then the code can be merged with the existing code, otherwise it can be discarded without having any impact on the main code.

* Now a days, software development teams are spread across different countries and work at different time zones. Use of a version control system for project aggregation becomes unavoidable.

==Evolution of version control systems==

VCS' can be broadly categorized into three groups based on the repository model. The sequence below follows the evolution of version control systems as well:

==='''Local repository model''' <ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>===
Local version control systems had one storage location of the files. It was called local because it didn't support networked commands or access like the other later softwares. So, all the developers had to use same computer system to access or modify files.

===='''Source Code Control System (SCCS)'''<ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>====
It is one of the pioneer source code revision softwares.[5] SCCS was developed at Bell Labs in 1972 by Marc J. Rochkind. Although it was originally developed for OS/MVT, SCCS was included in [http://en.wikipedia.org/wiki/Source_Code_Control_System some UNIX distributions.] SCCS ruled as the dominant VCS until ''Revision Control System'' was released.
:SCCS was the dominant version control system for Unix until the release of the [http://en.wikipedia.org/wiki/Revision_Control_System Revision Control System (RCS)]. Today, SCCS is generally considered obsolete. However, its file format is still used internally by a few other revision control programs, including [http://en.wikipedia.org/wiki/BitKeeper BitKeeper] and [http://en.wikipedia.org/wiki/TeamWare TeamWare]. The latter is a frontend to SCCS. [http://en.wikipedia.org/wiki/Sablime Sablime] has been developed from a modified version of SCCS but uses a history file format that is incompatible with SCCS. The SCCS file format uses a storage technique called [http://en.wikipedia.org/wiki/Interleaved_deltas interleaved deltas] (or the weave). This storage technique is now considered by many [http://en.wikipedia.org/wiki/Revision_control revision control] system developers as foundational to advanced merging and versioning techniques, such as the "Precise [http://en.wikipedia.org/wiki/Codeville Codeville]" ("pcdv") merge.
:'''What does a source code control system do?'''
:If you are creating or maintaining a text file---perhaps a document, or a script, or a program---a source code control system can do several things for you:
:*It can keep track of the changes made to the file: what was changed, when it was changed, and by whom.
:*It provides a version numbering scheme so you can tell which versions of a file are more recent.
:*It can retrieve previous versions of your file, so that you can retreat to an older version if you decide that the current version is a bad idea, or if you want to see some text that has since been changed or deleted.
:*If you accidentally delete the current file, you can get back the last version.
:*If several people are working with the same file, a source code control system can help you coordinate your work and keep track of who did what, and when.

SCCS is also known for the <code>sccsid</code> string, for example:

static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/11/93";

This string contains the file name, date, and can also contain a comment. After compilation, this string can be found in binary and object files by looking for the pattern "@(#)" and can be used determine which source code files were used during compilation.

===='''Control System(RCS)'''<ref>http://en.wikipedia.org/wiki/Revision_Control_System Revision</ref>====
It automated storing, retrieval, logging, identification, and merging frequent revisions of texts. RCS was first released in 1982 by Walter F. Tichy as an alternative to SCCS. It quickly gained popularity and almost replaced SCCS.[9]
:RCS performed better by storing the most recent copy of file and then storing only reverse differences called "deltas".One of the shortcomings of RCS was that only one person at a time could edit the file. RCS could manage only single files, not a whole project or directory.
:Ref.[3] is a comprehensive book on CSSC and RCS.

==='''Client-server model'''===
The [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server model] utilizes a single centralized repository for the version control which is accessible to the developers through network or internet. The below diagram [http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html] provides a high level overview of the model.
[[Image:Client_Server_Model.png |center|]]
===='''Concurrent Versions System (CVS)'''<ref>http://en.wikipedia.org/wiki/Concurrent_Versions_System</ref>====
It was one of the early client-server model based scheme. Dick Grune started developing CVS from 1984-1985 to allow his students to collaborate in a project according to their schedule. CVS was publicly released at 1986.The main improvement for CVS over RCS was that CVS could manage the whole project while RCS could only work on a file at a time.At the beginning, CVS was script based and called RCS at background. Later it was developed into a full fledged program. A lot of the IDE's (Emacs, Eclipse/aptana,Netbeans, Komodo, PHPEdit etc.) support CVS. CVSNT is a cross platform port of CVS with some modification. CVS, which was the defacto standard for version controlling for a long time is almost replaced today by SVN. There were many disadvantages of CVS which hindered its stay in the industry further. Prominent ones were
#CVS check-in is not an [http://en.wikipedia.org/wiki/Atomic_commit atomic] operation. For example, given the files 1.c, 2.c, 3.c, 4.c and if someone runs '''cvs ci 1.c 3.c''' and someone else runs cvs update at the same time, the person running update might get only the change to `3.c' and not the change to `1.c'. So, if check-in process was disturbed, it could result in damage of existing project at repository.
#CVS only tracks modification on a file-by-file basis.
#CVS was designed with only text files in mind. No native support for other formats. Extensive modification are necessary at the client and the server to support other file types.
#Conflict resolution in CVS, if not absent, is definitely not good. Conflict markers used in CVS may go unnoticed and those file might find their way into the repository.
#Slow

===='''Subversion (SVN)'''<ref>http://en.wikipedia.org/wiki/Subversion_%28software%29</ref>====
As the complexity of projects increased, the shortcomings of CVS became more and more prominent. This led to the development of Subversion. CollabNet started developing svn as a successor of CVS with added [http://en.wikipedia.org/wiki/Subversion_(software)#Features functionality][2][7]. Different open source projects (i.e.-[http://en.wikipedia.org/wiki/Apache_Software_Foundation Apache Software Foundation],[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby],[http://en.wikipedia.org/wiki/SourceForge SourceForge],[http://en.wikipedia.org/wiki/Tigris.org Tigris.org], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/Python_(programming_language) Python] and [http://en.wikipedia.org/wiki/MediaWiki MediaWiki]) use Subversion. Subversion is an open source software due to it's Apache license[1].
[[Image:Subversion_project_visualization.svg.png|650px|thumb|center|Visualization of a very simple Subversion project. Source:wikimedia commons, Explanation of terms can be found at http://en.wikipedia.org/wiki/Apache_Subversion, "Branching and tagging" and at http://en.wikipedia.org/wiki/Revision_control, #"Common vocabulary"]]

'''Features:''' <ref>http://en.wikipedia.org/wiki/Apache_Subversion#Features</ref>
* [http://en.wikipedia.org/wiki/Commit_(data_management) Commits] as true [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomic operations] (interrupted commit operations in CVS would cause repository inconsistency or corruption).
* Renamed/copied/moved/removed files retain full revision history.
* The system maintains [http://en.wikipedia.org/wiki/Software_versioning versioning] for directories, renames, and file [http://en.wikipedia.org/wiki/Metadata metadata] (but not for timestamps). Users can move and/or copy entire directory-trees very quickly, while retaining full revision history.
* Versioning of [http://en.wikipedia.org/wiki/Symbolic_link symbolic link]s.
* Native support for binary files, with space-efficient binary-diff storage.
* [http://en.wikipedia.org/wiki/Apache_HTTP_Server Apache HTTP Server] as network server, [http://en.wikipedia.org/wiki/WebDAV WebDAV]/[http://en.wikipedia.org/wiki/WebDAV#Extensions_and_derivatives Delta-V] for protocol. There is also an independent server [http://en.wikipedia.org/wiki/Process_(computing) process] called svnserve that uses a custom protocol over [http://en.wikipedia.org/wiki/Internet_Protocol_Suite TCP/IP].
* Branching as a cheap operation, independent of file size (though Subversion itself does not distinguish between a branch and a directory)
* Natively [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client–server], [http://en.wikipedia.org/wiki/Abstraction_layer layered] [http://en.wikipedia.org/wiki/Library_(computing) library] design.
* Client/server protocol sends diffs in both directions.
* Costs proportional to change size, not to data size.
* Parsable output, including XML log output.
* Open source licensed — Apache License in the projected 1.7 release; prior versions use a derivative of the Apache Software License, v1.1
* Internationalized program messages.
* File locking for unmergeable files ("reserved checkouts").
* Path-based authorization.
* Language bindings for C#, PHP, Python, Perl, Ruby, and Java.
* Full MIME support — users can view or change the MIME type of each file, with the software knowing which MIME types can have their differences from previous versions shown.
* Merge tracking - Merges between branches will be tracked, this allows automatically merging between branches without telling Subversion what (doesn't) need to be merged.

=====Eclipse Subversive - Subversion (SVN) Team Provider<ref>http://www.eclipse.org/subversive/</ref>=====
The Subversive project is aimed to integrate the Subversion (SVN) version control system with the Eclipse platform. Using the Subversive plug-in, you can work with projects stored in Subversion repositories directly from the Eclipse workbench in a way similar to work with other Eclipse version control providers, such as CVS and Git.

'''Subversive Features''': Subversive plug-in provides access to Subversion repositories from the Eclipse workbench.

*'''Full-Scale SVN Client'''
:Subversive is designed to be used as a full-featured SVN client, so you can update, commit, merge changes, work with SVN properties, view change history and perform other operations with SVN directly from the Eclipse environment.

*'''Advanced SVN Features'''
:Subversive includes several features that extend functionality of the standard SVN client. In particular, Subversive can show the SVN repository content grouped by the logical structures of trunk, branch and tag and display changes on a visual revisions graph.

*'''Seamless Integration with Eclipse'''
:Subversive is an official Eclipse project and an integral part of Eclipse Simultaneous releases. The project follows all Eclipse guidelines and requirements to deliver a quality SVN team provider plug-in similar to CVS and Git implementations.

*'''Support of the Latest SVN Versions'''
:Subversive evolves together with the Subversion project to provide Eclipse users with the features that appeared in new versions of the SVN implementation. You can use the new SVN functionality in Eclipse by installing the Early Access version of Subversive.

===='''Configuration Management Version Control (CMVC)'''<ref>http://en.wikipedia.org/wiki/IBM_Configuration_Management_Version_Control_(CMVC)</ref>====
It was developed by IBM Corporation in the mid-late 1990s and was derived in part from software purchased from HP and from IBM's internal-use-only system, IDSS. CMVC was superseded by IBM Rational ClearCase and ClearQuest. The system was used to manage the IBM OS/2 and IBM AIX source code repositories in the 1990s. It is still widely used within IBM by various teams.

One of the drawbacks of CMVC is that, once a file is checked-out by a user, it remains locked to all the other users until the either the new version is checked-in or the lock is released explicitly by the owner (user) of the lock. Some proprietary client-server based version control softwares are:
::*[http://en.wikipedia.org/wiki/Autodesk_Vault Autodesk Vault] was specifically developed for Autodesk applications.
::*[http://en.wikipedia.org/wiki/IBM_Rational_ClearCase ClearCase] was developed by IBM Rational Software. It's a Source Code Control (SCC) compliant software.
::*[http://en.wikipedia.org/wiki/Visual_SourceSafe Visual SourceSafe] is developed by Microsoft targeting small development team.
::*[http://en.wikipedia.org/wiki/Visual_Studio_Team_System Visual Studio Team System] is also developed by Microsoft targeting larger groups.

===Distributed model===
'''Distributed Version Control (DVCS)''', or '''Decentralized Version Control''' systems can have many central repositories.This is a peer to peer approach. The concept started developing at late 90's. In DVCS. Each developer works with his or her local repository and the changes are synchronized between repositories upon commit. DVCS are better suited for large teams with partially independent developers. i.e.- opensource software development.[8]
#[http://en.wikipedia.org/wiki/Monotone_%28software%29 Monotone] and [http://en.wikipedia.org/wiki/GNU_arch GNU arch] were the first generation DVCS (release:2001-2003) followed by [http://en.wikipedia.org/wiki/Darcs Darcs] (stable release:2010).[http://en.wikipedia.org/wiki/Mercurial Mercurial] , [http://en.wikipedia.org/wiki/Git_%28software%29 Git] and [http://en.wikipedia.org/wiki/Bazaar_%28software%29 Bazaar] (2005-2007) are well adopted among developers.
#[http://en.wikipedia.org/wiki/BitKeeper BitKeeper],[http://en.wikipedia.org/wiki/Code_Co-op Code Co-op], [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] are some proprietary DVCS softwares.

It should be noted that many distributed version control softwares support client-server model too.One of the benefits of DVCS is that a developer can save the source code as long as he wants even if the central repository (in client-server model) is discarded at the end of a project.

[[Image:timeline.jpg|650px|thumb|center|A generalized timeline. Source:http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av]]

====Git (Version control)<ref>http://en.wikipedia.org/wiki/Git_(software)</ref>====
[[Image:220px-Git_data_flow_simplified.png|600px|thumb|right|Some data flows and storage levels in the Git revision control system.]]
Git development began after many Linux kernel developers chose to give up access to BitKeeper, a proprietary SCM system that had previously been used to maintain the project. The copyright holder of BitKeeper, Larry McVoy, had withdrawn free use of the product after he claimed that Andrew Tridgell had reverse-engineered the BitKeeper protocols.

Git was created by [http://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] (the founder of Linux) because he really didn’t like Concurrent Versions System (CVS), which, at the time, was the most popular version control system. Torvalds wanted something to help keep versions of the kernel he was working on and he figured that he would have to build a system of his own.

Git is an open source project, and since Torvalds’ initial development, there have been many other primary authors and contributors to the project.

'''Advantages of Using Git'''
*Git is super easy to install:
*Git is easier to learn compared to other systems:
*Git is fast:
*Git is decentralized:

'''Disadvantages of Using Git'''
*'''Git has a learning curve:''' It’s one of the easier version control systems to use, any new thing you introduce to your workflow will need some learning time. Learning Git will be similar to learning a new software application such as Word or Excel.

.

== File Sharing Models ==
Every system that implement version controlling have to address one fundamental problem: How will the files in the repository be safely shared across users but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

Consider the scenario with two users A and B. Both of them check out the same file (same version). User A after making his modification, suppose, commits the file first. A few moments later B completes his modification. B does not have any clue about A's check-in and he happily commits his code to the repository. Now B has accidentally overwritten the changes made by A leaving the system in an inconsistent state. This problem can be solved in two different ways: 
* Lock-Modify-Unlock
* Copy-Modify-Merge 
While CMVC follows the lock-modify-unlock solution, svn follows copy-modify-merge allowing users to modify the same piece of code concurrently. 
The problem with the lock-modify-unlock model is that it's a bit restrictive and often becomes a roadblock for users:

* Locking may cause unnecessary delay and is not desired when it comes to teams/projects which have a small cycle time between releases. For example: Suppose say, user A checks out a file (locks it) and some interrupt in his work causes him to switch to another task of higher priority. There is a possibility that he forgets completely about the file that he checked out. Now, if another user B wants to edit the same file, he cannot do so, without having the administrator unlock the file for him, his hands are tied!

* Locking may cause unnecessary serialization: What if two different users A and B want to edit different non-intersecting portions of the same file? With proper merging solution in place, they could have done it easily without bothering about what the other user does with the file.

* Locking may create a false sense of security: As with any model, lock-modify-unlock approach too allows two different users to work on separate files simultaneously. However the model does not define how dependencies between files are dealt with. For example: Suppose A locks and edits file f1, while B simultaneously locks and edits file f2. If there is a function call in f1 whose definition exists in f2 but the definition is removed or the function name is changed after editing f2, they don't work together anymore. Thus, locking files by itself does not provide security against such deliberate changes. Lot of manual synchronization is needed to avoid such situations which is only going to cause delay in the development of the project.

==Use of version control in other areas ==

Now a days, many document editing softwares have adopted version control. Wikis, GoogleDoc, Microsoft Office and OpenOffice.org suite are some example softwares that can save previous document editing history.

==Other considerations==

Most open source softwares have [http://linuxmafia.com/faq/Apps/vcs.html distributions for Linux] OS. In most open source cases, Linux and windows versions are released concurrently.
Many VCS' have plugins for common IDEs like Eclipse, Visual Studio, Oracle JDeveloper etc. NetBeans IDE and Xcode has integrated version control support.

==References==
<references/>

==Additional References==

1. [http://subversion.apache.org/news.html#news-20100217. Apache Software Foundation Announcements, "Subversion becomes Apache Subversion".(2010-02-17) Accessed:September 2010 ]

2. [http://svnbook.red-bean.com/ Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. "Version Control with Subversion", an O'Reilly book available online. Accessed:September 2010]

3. [http://shop.oreilly.com/product/9781565921177.do Don Bolinger, Tan Bronson: Applying RCS and SCCS. O'Reilly Media. ISBN:978-1-56592-117-7]

4. [http://www.ericsink.com/scm/source_control.html Eric Sink: A collection of articles on source control and best practices, Accessed:September 2010]

5. [http://basepath.com/aup/talks/SCCS-Slideshow.pdf M. J. Rochkind: The Source Code Control System.] In IEEE Transactions on Software Engineering SE-1:4 (Dec. 1975), pages 364–370.

6. [http://onlinelibrary.wiley.com/doi/10.1002/bltj.2039/pdf Martin, Robert L. (2002). "Software configuration management for the 21st century". Bell Labs technical journal, Volume 2, Issue 1, page- 154.]

7. Mike Mason; Pragmatic Version Control Using Subversion; Pragmatic Bookshelf; ISBN 0-9745140-6-3 (1st edition, paperback, 2005)

8. [http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ Noah Gift,Adam Shand: Introduction to distributed version control systems (compare how to use Bazaar, Mercurial, and Git) (Apr 2009), IBM Technical Library, Accessed:September 2010 ]

9.[http://onlinelibrary.wiley.com/doi/10.1002/spe.4380150703/abstract Walter F. Tichy; Rcs - a system for version control; In Software: Practice and Experience. Volume 15, Issue 7,(July 1985) pages 637–654 ]

==See also==
[http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision control]

[http://en.wikipedia.org/wiki/List_of_revision_control_software Wikipedia: List of revision control software]

[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Wikipedia: Detail comparison of revision control softwares]

[http://www.nongnu.org/cvs/ CVS webpage]

[http://www.cs.vu.nl/~dick/ Dick Grune's website on CVS history]

[http://groups.google.com/group/mod.sources/msg/2ebab72ac0744fb8?dmode=source The original usenet post on CVS] archived at google groups.

[http://linuxmafia.com/faq/Apps/vcs.html Linux availability of various version control softwares]

CSC/ECE 517 Fall 2012/ch1 1w1 rk

2012-09-08T01:24:34Z

Rchakar: /* Git (Version control)http://en.wikipedia.org/wiki/Git_(software) */

==Introduction==
A [http://en.wikipedia.org/wiki/Revision_control version control] system '''(VCS)''' is a process for managing software codes,files and directory structures and corresponding updates made to them during software development, web development etc. project or during subsequent project maintenances. Version control is also known as revision control, source control or [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM)[6].

Any software development project is a dynamic and fast paced environment. In a typical setting, development for a project is performed simultaneously by many developers. Thus, incorporating all the changes made, either simultaneously or at different times, poses a new type of challenge.

This wikibook chapter focuses mainly on the development history of different version control systems.

==Why version control systems are needed?==
The major issues in a dynamic development environment can be described as:
* Obviously, '''merging''' of a lot of files. If we consider somebody to do merging manually, The sheer volume of communication required is overwhelming. This communication can be among the developers themselves in a small team or between the team leader in charge of merging and the rest of the group.

* '''Accountability:''' if one of the developers breaks the code flow during development, It is tough to detect and naturally nobody steps forward to take the blame. A version control system can precisely indicate who caused the break in the code.

* If a certain code implementation doesn't work as expected, '''Reverting''' to last satisfactory state may be required.

* Development on stale code may result in '''Code loss'''. for example, two developers downloaded a certain file at 10AM. One of the developers modified foo_1() method and uploaded modified file at 10:30AM.The other developer modified foo_2() method and uploaded the same file at 10:45AM. Since the functions are in the same file, the second upload will overwrite the file uploaded by first developer at 10:30AM causing loss of his part of work.

* Even a lone coder might need to '''review''' why he or she made a certain change in code. Comments during code check-in can be a useful resource in such situation.

* Version control provides a form of '''documentation''' which makes tracking easy. i.e.-'''tagging''' is a kind of snapshot of all files and documents at a particular stage of development, usually during a stable release. This allows the developers to work with the exact files that were included in that release for bug-fixing purpose.

* '''Sandboxing / Branching:''' Version control makes it possible to perform temporary code changes in an isolated area, usually in branch folder, for testing purpose. If the outcome is satisfactory then the code can be merged with the existing code, otherwise it can be discarded without having any impact on the main code.

* Now a days, software development teams are spread across different countries and work at different time zones. Use of a version control system for project aggregation becomes unavoidable.

==Evolution of version control systems==

VCS' can be broadly categorized into three groups based on the repository model. The sequence below follows the evolution of version control systems as well:

==='''Local repository model''' <ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>===
Local version control systems had one storage location of the files. It was called local because it didn't support networked commands or access like the other later softwares. So, all the developers had to use same computer system to access or modify files.

===='''Source Code Control System (SCCS)'''<ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>====
It is one of the pioneer source code revision softwares.[5] SCCS was developed at Bell Labs in 1972 by Marc J. Rochkind. Although it was originally developed for OS/MVT, SCCS was included in [http://en.wikipedia.org/wiki/Source_Code_Control_System some UNIX distributions.] SCCS ruled as the dominant VCS until ''Revision Control System'' was released.
:SCCS was the dominant version control system for Unix until the release of the [http://en.wikipedia.org/wiki/Revision_Control_System Revision Control System (RCS)]. Today, SCCS is generally considered obsolete. However, its file format is still used internally by a few other revision control programs, including [http://en.wikipedia.org/wiki/BitKeeper BitKeeper] and [http://en.wikipedia.org/wiki/TeamWare TeamWare]. The latter is a frontend to SCCS. [http://en.wikipedia.org/wiki/Sablime Sablime] has been developed from a modified version of SCCS but uses a history file format that is incompatible with SCCS. The SCCS file format uses a storage technique called [http://en.wikipedia.org/wiki/Interleaved_deltas interleaved deltas] (or the weave). This storage technique is now considered by many [http://en.wikipedia.org/wiki/Revision_control revision control] system developers as foundational to advanced merging and versioning techniques, such as the "Precise [http://en.wikipedia.org/wiki/Codeville Codeville]" ("pcdv") merge.
:'''What does a source code control system do?'''
:If you are creating or maintaining a text file---perhaps a document, or a script, or a program---a source code control system can do several things for you:
:*It can keep track of the changes made to the file: what was changed, when it was changed, and by whom.
:*It provides a version numbering scheme so you can tell which versions of a file are more recent.
:*It can retrieve previous versions of your file, so that you can retreat to an older version if you decide that the current version is a bad idea, or if you want to see some text that has since been changed or deleted.
:*If you accidentally delete the current file, you can get back the last version.
:*If several people are working with the same file, a source code control system can help you coordinate your work and keep track of who did what, and when.

SCCS is also known for the <code>sccsid</code> string, for example:

static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/11/93";

This string contains the file name, date, and can also contain a comment. After compilation, this string can be found in binary and object files by looking for the pattern "@(#)" and can be used determine which source code files were used during compilation.

===='''Control System(RCS)'''<ref>http://en.wikipedia.org/wiki/Revision_Control_System Revision</ref>====
It automated storing, retrieval, logging, identification, and merging frequent revisions of texts. RCS was first released in 1982 by Walter F. Tichy as an alternative to SCCS. It quickly gained popularity and almost replaced SCCS.[9]
:RCS performed better by storing the most recent copy of file and then storing only reverse differences called "deltas".One of the shortcomings of RCS was that only one person at a time could edit the file. RCS could manage only single files, not a whole project or directory.
:Ref.[3] is a comprehensive book on CSSC and RCS.

==='''Client-server model'''===
The [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server model] utilizes a single centralized repository for the version control which is accessible to the developers through network or internet. The below diagram [http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html] provides a high level overview of the model.
[[Image:Client_Server_Model.png |center|]]
===='''Concurrent Versions System (CVS)'''<ref>http://en.wikipedia.org/wiki/Concurrent_Versions_System</ref>====
It was one of the early client-server model based scheme. Dick Grune started developing CVS from 1984-1985 to allow his students to collaborate in a project according to their schedule. CVS was publicly released at 1986.The main improvement for CVS over RCS was that CVS could manage the whole project while RCS could only work on a file at a time.At the beginning, CVS was script based and called RCS at background. Later it was developed into a full fledged program. A lot of the IDE's (Emacs, Eclipse/aptana,Netbeans, Komodo, PHPEdit etc.) support CVS. CVSNT is a cross platform port of CVS with some modification. CVS, which was the defacto standard for version controlling for a long time is almost replaced today by SVN. There were many disadvantages of CVS which hindered its stay in the industry further. Prominent ones were
#CVS check-in is not an [http://en.wikipedia.org/wiki/Atomic_commit atomic] operation. For example, given the files 1.c, 2.c, 3.c, 4.c and if someone runs '''cvs ci 1.c 3.c''' and someone else runs cvs update at the same time, the person running update might get only the change to `3.c' and not the change to `1.c'. So, if check-in process was disturbed, it could result in damage of existing project at repository.
#CVS only tracks modification on a file-by-file basis.
#CVS was designed with only text files in mind. No native support for other formats. Extensive modification are necessary at the client and the server to support other file types.
#Conflict resolution in CVS, if not absent, is definitely not good. Conflict markers used in CVS may go unnoticed and those file might find their way into the repository.
#Slow

===='''Subversion (SVN)'''<ref>http://en.wikipedia.org/wiki/Subversion_%28software%29</ref>====
As the complexity of projects increased, the shortcomings of CVS became more and more prominent. This led to the development of Subversion. CollabNet started developing svn as a successor of CVS with added [http://en.wikipedia.org/wiki/Subversion_(software)#Features functionality][2][7]. Different open source projects (i.e.-[http://en.wikipedia.org/wiki/Apache_Software_Foundation Apache Software Foundation],[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby],[http://en.wikipedia.org/wiki/SourceForge SourceForge],[http://en.wikipedia.org/wiki/Tigris.org Tigris.org], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/Python_(programming_language) Python] and [http://en.wikipedia.org/wiki/MediaWiki MediaWiki]) use Subversion. Subversion is an open source software due to it's Apache license[1].
[[Image:Subversion_project_visualization.svg.png|650px|thumb|center|Visualization of a very simple Subversion project. Source:wikimedia commons, Explanation of terms can be found at http://en.wikipedia.org/wiki/Apache_Subversion, "Branching and tagging" and at http://en.wikipedia.org/wiki/Revision_control, #"Common vocabulary"]]

'''Features:''' <ref>http://en.wikipedia.org/wiki/Apache_Subversion#Features</ref>
* [http://en.wikipedia.org/wiki/Commit_(data_management) Commits] as true [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomic operations] (interrupted commit operations in CVS would cause repository inconsistency or corruption).
* Renamed/copied/moved/removed files retain full revision history.
* The system maintains [http://en.wikipedia.org/wiki/Software_versioning versioning] for directories, renames, and file [http://en.wikipedia.org/wiki/Metadata metadata] (but not for timestamps). Users can move and/or copy entire directory-trees very quickly, while retaining full revision history.
* Versioning of [http://en.wikipedia.org/wiki/Symbolic_link symbolic link]s.
* Native support for binary files, with space-efficient binary-diff storage.
* [http://en.wikipedia.org/wiki/Apache_HTTP_Server Apache HTTP Server] as network server, [http://en.wikipedia.org/wiki/WebDAV WebDAV]/[http://en.wikipedia.org/wiki/WebDAV#Extensions_and_derivatives Delta-V] for protocol. There is also an independent server [http://en.wikipedia.org/wiki/Process_(computing) process] called svnserve that uses a custom protocol over [http://en.wikipedia.org/wiki/Internet_Protocol_Suite TCP/IP].
* Branching as a cheap operation, independent of file size (though Subversion itself does not distinguish between a branch and a directory)
* Natively [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client–server], [http://en.wikipedia.org/wiki/Abstraction_layer layered] [http://en.wikipedia.org/wiki/Library_(computing) library] design.
* Client/server protocol sends diffs in both directions.
* Costs proportional to change size, not to data size.
* Parsable output, including XML log output.
* Open source licensed — Apache License in the projected 1.7 release; prior versions use a derivative of the Apache Software License, v1.1
* Internationalized program messages.
* File locking for unmergeable files ("reserved checkouts").
* Path-based authorization.
* Language bindings for C#, PHP, Python, Perl, Ruby, and Java.
* Full MIME support — users can view or change the MIME type of each file, with the software knowing which MIME types can have their differences from previous versions shown.
* Merge tracking - Merges between branches will be tracked, this allows automatically merging between branches without telling Subversion what (doesn't) need to be merged.

=====Eclipse Subversive - Subversion (SVN) Team Provider<ref>http://www.eclipse.org/subversive/</ref>=====
The Subversive project is aimed to integrate the Subversion (SVN) version control system with the Eclipse platform. Using the Subversive plug-in, you can work with projects stored in Subversion repositories directly from the Eclipse workbench in a way similar to work with other Eclipse version control providers, such as CVS and Git.

'''Subversive Features''': Subversive plug-in provides access to Subversion repositories from the Eclipse workbench.

*'''Full-Scale SVN Client'''
:Subversive is designed to be used as a full-featured SVN client, so you can update, commit, merge changes, work with SVN properties, view change history and perform other operations with SVN directly from the Eclipse environment.

*'''Advanced SVN Features'''
:Subversive includes several features that extend functionality of the standard SVN client. In particular, Subversive can show the SVN repository content grouped by the logical structures of trunk, branch and tag and display changes on a visual revisions graph.

*'''Seamless Integration with Eclipse'''
:Subversive is an official Eclipse project and an integral part of Eclipse Simultaneous releases. The project follows all Eclipse guidelines and requirements to deliver a quality SVN team provider plug-in similar to CVS and Git implementations.

*'''Support of the Latest SVN Versions'''
:Subversive evolves together with the Subversion project to provide Eclipse users with the features that appeared in new versions of the SVN implementation. You can use the new SVN functionality in Eclipse by installing the Early Access version of Subversive.

===='''Configuration Management Version Control (CMVC)'''<ref>http://en.wikipedia.org/wiki/IBM_Configuration_Management_Version_Control_(CMVC)</ref>====
It was developed by IBM Corporation in the mid-late 1990s and was derived in part from software purchased from HP and from IBM's internal-use-only system, IDSS. CMVC was superseded by IBM Rational ClearCase and ClearQuest. The system was used to manage the IBM OS/2 and IBM AIX source code repositories in the 1990s. It is still widely used within IBM by various teams.

One of the drawbacks of CMVC is that, once a file is checked-out by a user, it remains locked to all the other users until the either the new version is checked-in or the lock is released explicitly by the owner (user) of the lock. Some proprietary client-server based version control softwares are:
::*[http://en.wikipedia.org/wiki/Autodesk_Vault Autodesk Vault] was specifically developed for Autodesk applications.
::*[http://en.wikipedia.org/wiki/IBM_Rational_ClearCase ClearCase] was developed by IBM Rational Software. It's a Source Code Control (SCC) compliant software.
::*[http://en.wikipedia.org/wiki/Visual_SourceSafe Visual SourceSafe] is developed by Microsoft targeting small development team.
::*[http://en.wikipedia.org/wiki/Visual_Studio_Team_System Visual Studio Team System] is also developed by Microsoft targeting larger groups.

===Distributed model===
'''Distributed Version Control (DVCS)''', or '''Decentralized Version Control''' systems can have many central repositories.This is a peer to peer approach. The concept started developing at late 90's. In DVCS. Each developer works with his or her local repository and the changes are synchronized between repositories upon commit. DVCS are better suited for large teams with partially independent developers. i.e.- opensource software development.[8]
#[http://en.wikipedia.org/wiki/Monotone_%28software%29 Monotone] and [http://en.wikipedia.org/wiki/GNU_arch GNU arch] were the first generation DVCS (release:2001-2003) followed by [http://en.wikipedia.org/wiki/Darcs Darcs] (stable release:2010).[http://en.wikipedia.org/wiki/Mercurial Mercurial] , [http://en.wikipedia.org/wiki/Git_%28software%29 Git] and [http://en.wikipedia.org/wiki/Bazaar_%28software%29 Bazaar] (2005-2007) are well adopted among developers.
#[http://en.wikipedia.org/wiki/BitKeeper BitKeeper],[http://en.wikipedia.org/wiki/Code_Co-op Code Co-op], [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] are some proprietary DVCS softwares.

It should be noted that many distributed version control softwares support client-server model too.One of the benefits of DVCS is that a developer can save the source code as long as he wants even if the central repository (in client-server model) is discarded at the end of a project.

[[Image:timeline.jpg|650px|thumb|center|A generalized timeline. Source:http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av]]

====Git (Version control)<ref>http://en.wikipedia.org/wiki/Git_(software)</ref>====
[[Image:220px-Git_data_flow_simplified.png|600px|thumb|right|Some data flows and storage levels in the Git revision control system.]]
Git development began after many Linux kernel developers chose to give up access to BitKeeper, a proprietary SCM system that had previously been used to maintain the project. The copyright holder of BitKeeper, Larry McVoy, had withdrawn free use of the product after he claimed that Andrew Tridgell had reverse-engineered the BitKeeper protocols.

Git was created by [http://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] (the founder of Linux) because he really didn’t like Concurrent Versions System (CVS), which, at the time, was the most popular version control system. Torvalds wanted something to help keep versions of the kernel he was working on and he figured that he would have to build a system of his own.

Git is an open source project, and since Torvalds’ initial development, there have been many other primary authors and contributors to the project.

'''Advantages of Using Git'''
*Git is super easy to install:
*Git is easier to learn compared to other systems:
*Git is fast:
*Git is decentralized:

'''Disadvantages of Using Git'''
*'''Git has a learning curve:''' It’s one of the easier version control systems to use, any new thing you introduce to your workflow will need some learning time. Learning Git will be similar to learning a new software application such as Word or Excel.

== File Sharing Models ==
Every system that implement version controlling have to address one fundamental problem: How will the files in the repository be safely shared across users but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

Consider the scenario with two users A and B. Both of them check out the same file (same version). User A after making his modification, suppose, commits the file first. A few moments later B completes his modification. B does not have any clue about A's check-in and he happily commits his code to the repository. Now B has accidentally overwritten the changes made by A leaving the system in an inconsistent state. This problem can be solved in two different ways: 
* Lock-Modify-Unlock
* Copy-Modify-Merge 
While CMVC follows the lock-modify-unlock solution, svn follows copy-modify-merge allowing users to modify the same piece of code concurrently. 
The problem with the lock-modify-unlock model is that it's a bit restrictive and often becomes a roadblock for users:

* Locking may cause unnecessary delay and is not desired when it comes to teams/projects which have a small cycle time between releases. For example: Suppose say, user A checks out a file (locks it) and some interrupt in his work causes him to switch to another task of higher priority. There is a possibility that he forgets completely about the file that he checked out. Now, if another user B wants to edit the same file, he cannot do so, without having the administrator unlock the file for him, his hands are tied!

* Locking may cause unnecessary serialization: What if two different users A and B want to edit different non-intersecting portions of the same file? With proper merging solution in place, they could have done it easily without bothering about what the other user does with the file.

* Locking may create a false sense of security: As with any model, lock-modify-unlock approach too allows two different users to work on separate files simultaneously. However the model does not define how dependencies between files are dealt with. For example: Suppose A locks and edits file f1, while B simultaneously locks and edits file f2. If there is a function call in f1 whose definition exists in f2 but the definition is removed or the function name is changed after editing f2, they don't work together anymore. Thus, locking files by itself does not provide security against such deliberate changes. Lot of manual synchronization is needed to avoid such situations which is only going to cause delay in the development of the project.

==Use of version control in other areas ==

Now a days, many document editing softwares have adopted version control. Wikis, GoogleDoc, Microsoft Office and OpenOffice.org suite are some example softwares that can save previous document editing history.

==Other considerations==

Most open source softwares have [http://linuxmafia.com/faq/Apps/vcs.html distributions for Linux] OS. In most open source cases, Linux and windows versions are released concurrently.
Many VCS' have plugins for common IDEs like Eclipse, Visual Studio, Oracle JDeveloper etc. NetBeans IDE and Xcode has integrated version control support.

==References==
<references/>

==Additional References==

1. [http://subversion.apache.org/news.html#news-20100217. Apache Software Foundation Announcements, "Subversion becomes Apache Subversion".(2010-02-17) Accessed:September 2010 ]

2. [http://svnbook.red-bean.com/ Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. "Version Control with Subversion", an O'Reilly book available online. Accessed:September 2010]

3. [http://shop.oreilly.com/product/9781565921177.do Don Bolinger, Tan Bronson: Applying RCS and SCCS. O'Reilly Media. ISBN:978-1-56592-117-7]

4. [http://www.ericsink.com/scm/source_control.html Eric Sink: A collection of articles on source control and best practices, Accessed:September 2010]

5. [http://basepath.com/aup/talks/SCCS-Slideshow.pdf M. J. Rochkind: The Source Code Control System.] In IEEE Transactions on Software Engineering SE-1:4 (Dec. 1975), pages 364–370.

6. [http://onlinelibrary.wiley.com/doi/10.1002/bltj.2039/pdf Martin, Robert L. (2002). "Software configuration management for the 21st century". Bell Labs technical journal, Volume 2, Issue 1, page- 154.]

7. Mike Mason; Pragmatic Version Control Using Subversion; Pragmatic Bookshelf; ISBN 0-9745140-6-3 (1st edition, paperback, 2005)

8. [http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ Noah Gift,Adam Shand: Introduction to distributed version control systems (compare how to use Bazaar, Mercurial, and Git) (Apr 2009), IBM Technical Library, Accessed:September 2010 ]

9.[http://onlinelibrary.wiley.com/doi/10.1002/spe.4380150703/abstract Walter F. Tichy; Rcs - a system for version control; In Software: Practice and Experience. Volume 15, Issue 7,(July 1985) pages 637–654 ]

==See also==
[http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision control]

[http://en.wikipedia.org/wiki/List_of_revision_control_software Wikipedia: List of revision control software]

[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Wikipedia: Detail comparison of revision control softwares]

[http://www.nongnu.org/cvs/ CVS webpage]

[http://www.cs.vu.nl/~dick/ Dick Grune's website on CVS history]

[http://groups.google.com/group/mod.sources/msg/2ebab72ac0744fb8?dmode=source The original usenet post on CVS] archived at google groups.

[http://linuxmafia.com/faq/Apps/vcs.html Linux availability of various version control softwares]

CSC/ECE 517 Fall 2012/ch1 1w1 rk

2012-09-08T01:24:01Z

Rchakar: /* Git (Version control)http://en.wikipedia.org/wiki/Git_(software) */

==Introduction==
A [http://en.wikipedia.org/wiki/Revision_control version control] system '''(VCS)''' is a process for managing software codes,files and directory structures and corresponding updates made to them during software development, web development etc. project or during subsequent project maintenances. Version control is also known as revision control, source control or [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM)[6].

Any software development project is a dynamic and fast paced environment. In a typical setting, development for a project is performed simultaneously by many developers. Thus, incorporating all the changes made, either simultaneously or at different times, poses a new type of challenge.

This wikibook chapter focuses mainly on the development history of different version control systems.

==Why version control systems are needed?==
The major issues in a dynamic development environment can be described as:
* Obviously, '''merging''' of a lot of files. If we consider somebody to do merging manually, The sheer volume of communication required is overwhelming. This communication can be among the developers themselves in a small team or between the team leader in charge of merging and the rest of the group.

* '''Accountability:''' if one of the developers breaks the code flow during development, It is tough to detect and naturally nobody steps forward to take the blame. A version control system can precisely indicate who caused the break in the code.

* If a certain code implementation doesn't work as expected, '''Reverting''' to last satisfactory state may be required.

* Development on stale code may result in '''Code loss'''. for example, two developers downloaded a certain file at 10AM. One of the developers modified foo_1() method and uploaded modified file at 10:30AM.The other developer modified foo_2() method and uploaded the same file at 10:45AM. Since the functions are in the same file, the second upload will overwrite the file uploaded by first developer at 10:30AM causing loss of his part of work.

* Even a lone coder might need to '''review''' why he or she made a certain change in code. Comments during code check-in can be a useful resource in such situation.

* Version control provides a form of '''documentation''' which makes tracking easy. i.e.-'''tagging''' is a kind of snapshot of all files and documents at a particular stage of development, usually during a stable release. This allows the developers to work with the exact files that were included in that release for bug-fixing purpose.

* '''Sandboxing / Branching:''' Version control makes it possible to perform temporary code changes in an isolated area, usually in branch folder, for testing purpose. If the outcome is satisfactory then the code can be merged with the existing code, otherwise it can be discarded without having any impact on the main code.

* Now a days, software development teams are spread across different countries and work at different time zones. Use of a version control system for project aggregation becomes unavoidable.

==Evolution of version control systems==

VCS' can be broadly categorized into three groups based on the repository model. The sequence below follows the evolution of version control systems as well:

==='''Local repository model''' <ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>===
Local version control systems had one storage location of the files. It was called local because it didn't support networked commands or access like the other later softwares. So, all the developers had to use same computer system to access or modify files.

===='''Source Code Control System (SCCS)'''<ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>====
It is one of the pioneer source code revision softwares.[5] SCCS was developed at Bell Labs in 1972 by Marc J. Rochkind. Although it was originally developed for OS/MVT, SCCS was included in [http://en.wikipedia.org/wiki/Source_Code_Control_System some UNIX distributions.] SCCS ruled as the dominant VCS until ''Revision Control System'' was released.
:SCCS was the dominant version control system for Unix until the release of the [http://en.wikipedia.org/wiki/Revision_Control_System Revision Control System (RCS)]. Today, SCCS is generally considered obsolete. However, its file format is still used internally by a few other revision control programs, including [http://en.wikipedia.org/wiki/BitKeeper BitKeeper] and [http://en.wikipedia.org/wiki/TeamWare TeamWare]. The latter is a frontend to SCCS. [http://en.wikipedia.org/wiki/Sablime Sablime] has been developed from a modified version of SCCS but uses a history file format that is incompatible with SCCS. The SCCS file format uses a storage technique called [http://en.wikipedia.org/wiki/Interleaved_deltas interleaved deltas] (or the weave). This storage technique is now considered by many [http://en.wikipedia.org/wiki/Revision_control revision control] system developers as foundational to advanced merging and versioning techniques, such as the "Precise [http://en.wikipedia.org/wiki/Codeville Codeville]" ("pcdv") merge.
:'''What does a source code control system do?'''
:If you are creating or maintaining a text file---perhaps a document, or a script, or a program---a source code control system can do several things for you:
:*It can keep track of the changes made to the file: what was changed, when it was changed, and by whom.
:*It provides a version numbering scheme so you can tell which versions of a file are more recent.
:*It can retrieve previous versions of your file, so that you can retreat to an older version if you decide that the current version is a bad idea, or if you want to see some text that has since been changed or deleted.
:*If you accidentally delete the current file, you can get back the last version.
:*If several people are working with the same file, a source code control system can help you coordinate your work and keep track of who did what, and when.

SCCS is also known for the <code>sccsid</code> string, for example:

static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/11/93";

This string contains the file name, date, and can also contain a comment. After compilation, this string can be found in binary and object files by looking for the pattern "@(#)" and can be used determine which source code files were used during compilation.

===='''Control System(RCS)'''<ref>http://en.wikipedia.org/wiki/Revision_Control_System Revision</ref>====
It automated storing, retrieval, logging, identification, and merging frequent revisions of texts. RCS was first released in 1982 by Walter F. Tichy as an alternative to SCCS. It quickly gained popularity and almost replaced SCCS.[9]
:RCS performed better by storing the most recent copy of file and then storing only reverse differences called "deltas".One of the shortcomings of RCS was that only one person at a time could edit the file. RCS could manage only single files, not a whole project or directory.
:Ref.[3] is a comprehensive book on CSSC and RCS.

==='''Client-server model'''===
The [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server model] utilizes a single centralized repository for the version control which is accessible to the developers through network or internet. The below diagram [http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html] provides a high level overview of the model.
[[Image:Client_Server_Model.png |center|]]
===='''Concurrent Versions System (CVS)'''<ref>http://en.wikipedia.org/wiki/Concurrent_Versions_System</ref>====
It was one of the early client-server model based scheme. Dick Grune started developing CVS from 1984-1985 to allow his students to collaborate in a project according to their schedule. CVS was publicly released at 1986.The main improvement for CVS over RCS was that CVS could manage the whole project while RCS could only work on a file at a time.At the beginning, CVS was script based and called RCS at background. Later it was developed into a full fledged program. A lot of the IDE's (Emacs, Eclipse/aptana,Netbeans, Komodo, PHPEdit etc.) support CVS. CVSNT is a cross platform port of CVS with some modification. CVS, which was the defacto standard for version controlling for a long time is almost replaced today by SVN. There were many disadvantages of CVS which hindered its stay in the industry further. Prominent ones were
#CVS check-in is not an [http://en.wikipedia.org/wiki/Atomic_commit atomic] operation. For example, given the files 1.c, 2.c, 3.c, 4.c and if someone runs '''cvs ci 1.c 3.c''' and someone else runs cvs update at the same time, the person running update might get only the change to `3.c' and not the change to `1.c'. So, if check-in process was disturbed, it could result in damage of existing project at repository.
#CVS only tracks modification on a file-by-file basis.
#CVS was designed with only text files in mind. No native support for other formats. Extensive modification are necessary at the client and the server to support other file types.
#Conflict resolution in CVS, if not absent, is definitely not good. Conflict markers used in CVS may go unnoticed and those file might find their way into the repository.
#Slow

===='''Subversion (SVN)'''<ref>http://en.wikipedia.org/wiki/Subversion_%28software%29</ref>====
As the complexity of projects increased, the shortcomings of CVS became more and more prominent. This led to the development of Subversion. CollabNet started developing svn as a successor of CVS with added [http://en.wikipedia.org/wiki/Subversion_(software)#Features functionality][2][7]. Different open source projects (i.e.-[http://en.wikipedia.org/wiki/Apache_Software_Foundation Apache Software Foundation],[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby],[http://en.wikipedia.org/wiki/SourceForge SourceForge],[http://en.wikipedia.org/wiki/Tigris.org Tigris.org], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/Python_(programming_language) Python] and [http://en.wikipedia.org/wiki/MediaWiki MediaWiki]) use Subversion. Subversion is an open source software due to it's Apache license[1].
[[Image:Subversion_project_visualization.svg.png|650px|thumb|center|Visualization of a very simple Subversion project. Source:wikimedia commons, Explanation of terms can be found at http://en.wikipedia.org/wiki/Apache_Subversion, "Branching and tagging" and at http://en.wikipedia.org/wiki/Revision_control, #"Common vocabulary"]]

'''Features:''' <ref>http://en.wikipedia.org/wiki/Apache_Subversion#Features</ref>
* [http://en.wikipedia.org/wiki/Commit_(data_management) Commits] as true [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomic operations] (interrupted commit operations in CVS would cause repository inconsistency or corruption).
* Renamed/copied/moved/removed files retain full revision history.
* The system maintains [http://en.wikipedia.org/wiki/Software_versioning versioning] for directories, renames, and file [http://en.wikipedia.org/wiki/Metadata metadata] (but not for timestamps). Users can move and/or copy entire directory-trees very quickly, while retaining full revision history.
* Versioning of [http://en.wikipedia.org/wiki/Symbolic_link symbolic link]s.
* Native support for binary files, with space-efficient binary-diff storage.
* [http://en.wikipedia.org/wiki/Apache_HTTP_Server Apache HTTP Server] as network server, [http://en.wikipedia.org/wiki/WebDAV WebDAV]/[http://en.wikipedia.org/wiki/WebDAV#Extensions_and_derivatives Delta-V] for protocol. There is also an independent server [http://en.wikipedia.org/wiki/Process_(computing) process] called svnserve that uses a custom protocol over [http://en.wikipedia.org/wiki/Internet_Protocol_Suite TCP/IP].
* Branching as a cheap operation, independent of file size (though Subversion itself does not distinguish between a branch and a directory)
* Natively [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client–server], [http://en.wikipedia.org/wiki/Abstraction_layer layered] [http://en.wikipedia.org/wiki/Library_(computing) library] design.
* Client/server protocol sends diffs in both directions.
* Costs proportional to change size, not to data size.
* Parsable output, including XML log output.
* Open source licensed — Apache License in the projected 1.7 release; prior versions use a derivative of the Apache Software License, v1.1
* Internationalized program messages.
* File locking for unmergeable files ("reserved checkouts").
* Path-based authorization.
* Language bindings for C#, PHP, Python, Perl, Ruby, and Java.
* Full MIME support — users can view or change the MIME type of each file, with the software knowing which MIME types can have their differences from previous versions shown.
* Merge tracking - Merges between branches will be tracked, this allows automatically merging between branches without telling Subversion what (doesn't) need to be merged.

=====Eclipse Subversive - Subversion (SVN) Team Provider<ref>http://www.eclipse.org/subversive/</ref>=====
The Subversive project is aimed to integrate the Subversion (SVN) version control system with the Eclipse platform. Using the Subversive plug-in, you can work with projects stored in Subversion repositories directly from the Eclipse workbench in a way similar to work with other Eclipse version control providers, such as CVS and Git.

'''Subversive Features''': Subversive plug-in provides access to Subversion repositories from the Eclipse workbench.

*'''Full-Scale SVN Client'''
:Subversive is designed to be used as a full-featured SVN client, so you can update, commit, merge changes, work with SVN properties, view change history and perform other operations with SVN directly from the Eclipse environment.

*'''Advanced SVN Features'''
:Subversive includes several features that extend functionality of the standard SVN client. In particular, Subversive can show the SVN repository content grouped by the logical structures of trunk, branch and tag and display changes on a visual revisions graph.

*'''Seamless Integration with Eclipse'''
:Subversive is an official Eclipse project and an integral part of Eclipse Simultaneous releases. The project follows all Eclipse guidelines and requirements to deliver a quality SVN team provider plug-in similar to CVS and Git implementations.

*'''Support of the Latest SVN Versions'''
:Subversive evolves together with the Subversion project to provide Eclipse users with the features that appeared in new versions of the SVN implementation. You can use the new SVN functionality in Eclipse by installing the Early Access version of Subversive.

===='''Configuration Management Version Control (CMVC)'''<ref>http://en.wikipedia.org/wiki/IBM_Configuration_Management_Version_Control_(CMVC)</ref>====
It was developed by IBM Corporation in the mid-late 1990s and was derived in part from software purchased from HP and from IBM's internal-use-only system, IDSS. CMVC was superseded by IBM Rational ClearCase and ClearQuest. The system was used to manage the IBM OS/2 and IBM AIX source code repositories in the 1990s. It is still widely used within IBM by various teams.

One of the drawbacks of CMVC is that, once a file is checked-out by a user, it remains locked to all the other users until the either the new version is checked-in or the lock is released explicitly by the owner (user) of the lock. Some proprietary client-server based version control softwares are:
::*[http://en.wikipedia.org/wiki/Autodesk_Vault Autodesk Vault] was specifically developed for Autodesk applications.
::*[http://en.wikipedia.org/wiki/IBM_Rational_ClearCase ClearCase] was developed by IBM Rational Software. It's a Source Code Control (SCC) compliant software.
::*[http://en.wikipedia.org/wiki/Visual_SourceSafe Visual SourceSafe] is developed by Microsoft targeting small development team.
::*[http://en.wikipedia.org/wiki/Visual_Studio_Team_System Visual Studio Team System] is also developed by Microsoft targeting larger groups.

===Distributed model===
'''Distributed Version Control (DVCS)''', or '''Decentralized Version Control''' systems can have many central repositories.This is a peer to peer approach. The concept started developing at late 90's. In DVCS. Each developer works with his or her local repository and the changes are synchronized between repositories upon commit. DVCS are better suited for large teams with partially independent developers. i.e.- opensource software development.[8]
#[http://en.wikipedia.org/wiki/Monotone_%28software%29 Monotone] and [http://en.wikipedia.org/wiki/GNU_arch GNU arch] were the first generation DVCS (release:2001-2003) followed by [http://en.wikipedia.org/wiki/Darcs Darcs] (stable release:2010).[http://en.wikipedia.org/wiki/Mercurial Mercurial] , [http://en.wikipedia.org/wiki/Git_%28software%29 Git] and [http://en.wikipedia.org/wiki/Bazaar_%28software%29 Bazaar] (2005-2007) are well adopted among developers.
#[http://en.wikipedia.org/wiki/BitKeeper BitKeeper],[http://en.wikipedia.org/wiki/Code_Co-op Code Co-op], [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] are some proprietary DVCS softwares.

It should be noted that many distributed version control softwares support client-server model too.One of the benefits of DVCS is that a developer can save the source code as long as he wants even if the central repository (in client-server model) is discarded at the end of a project.

[[Image:timeline.jpg|650px|thumb|center|A generalized timeline. Source:http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av]]

====Git (Version control)<ref>http://en.wikipedia.org/wiki/Git_(software)</ref>====
[[Image:220px-Git_data_flow_simplified.png|650px|thumb|right|Some data flows and storage levels in the Git revision control system.]]
Git development began after many Linux kernel developers chose to give up access to BitKeeper, a proprietary SCM system that had previously been used to maintain the project. The copyright holder of BitKeeper, Larry McVoy, had withdrawn free use of the product after he claimed that Andrew Tridgell had reverse-engineered the BitKeeper protocols.

Git was created by [http://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] (the founder of Linux) because he really didn’t like Concurrent Versions System (CVS), which, at the time, was the most popular version control system. Torvalds wanted something to help keep versions of the kernel he was working on and he figured that he would have to build a system of his own.

Git is an open source project, and since Torvalds’ initial development, there have been many other primary authors and contributors to the project.

'''Advantages of Using Git'''
*Git is super easy to install:
*Git is easier to learn compared to other systems:
*Git is fast:
*Git is decentralized:

'''Disadvantages of Using Git'''
*'''Git has a learning curve:''' It’s one of the easier version control systems to use, any new thing you introduce to your workflow will need some learning time. Learning Git will be similar to learning a new software application such as Word or Excel.

== File Sharing Models ==
Every system that implement version controlling have to address one fundamental problem: How will the files in the repository be safely shared across users but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

Consider the scenario with two users A and B. Both of them check out the same file (same version). User A after making his modification, suppose, commits the file first. A few moments later B completes his modification. B does not have any clue about A's check-in and he happily commits his code to the repository. Now B has accidentally overwritten the changes made by A leaving the system in an inconsistent state. This problem can be solved in two different ways: 
* Lock-Modify-Unlock
* Copy-Modify-Merge 
While CMVC follows the lock-modify-unlock solution, svn follows copy-modify-merge allowing users to modify the same piece of code concurrently. 
The problem with the lock-modify-unlock model is that it's a bit restrictive and often becomes a roadblock for users:

* Locking may cause unnecessary delay and is not desired when it comes to teams/projects which have a small cycle time between releases. For example: Suppose say, user A checks out a file (locks it) and some interrupt in his work causes him to switch to another task of higher priority. There is a possibility that he forgets completely about the file that he checked out. Now, if another user B wants to edit the same file, he cannot do so, without having the administrator unlock the file for him, his hands are tied!

* Locking may cause unnecessary serialization: What if two different users A and B want to edit different non-intersecting portions of the same file? With proper merging solution in place, they could have done it easily without bothering about what the other user does with the file.

* Locking may create a false sense of security: As with any model, lock-modify-unlock approach too allows two different users to work on separate files simultaneously. However the model does not define how dependencies between files are dealt with. For example: Suppose A locks and edits file f1, while B simultaneously locks and edits file f2. If there is a function call in f1 whose definition exists in f2 but the definition is removed or the function name is changed after editing f2, they don't work together anymore. Thus, locking files by itself does not provide security against such deliberate changes. Lot of manual synchronization is needed to avoid such situations which is only going to cause delay in the development of the project.

==Use of version control in other areas ==

Now a days, many document editing softwares have adopted version control. Wikis, GoogleDoc, Microsoft Office and OpenOffice.org suite are some example softwares that can save previous document editing history.

==Other considerations==

Most open source softwares have [http://linuxmafia.com/faq/Apps/vcs.html distributions for Linux] OS. In most open source cases, Linux and windows versions are released concurrently.
Many VCS' have plugins for common IDEs like Eclipse, Visual Studio, Oracle JDeveloper etc. NetBeans IDE and Xcode has integrated version control support.

==References==
<references/>

==Additional References==

1. [http://subversion.apache.org/news.html#news-20100217. Apache Software Foundation Announcements, "Subversion becomes Apache Subversion".(2010-02-17) Accessed:September 2010 ]

2. [http://svnbook.red-bean.com/ Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. "Version Control with Subversion", an O'Reilly book available online. Accessed:September 2010]

3. [http://shop.oreilly.com/product/9781565921177.do Don Bolinger, Tan Bronson: Applying RCS and SCCS. O'Reilly Media. ISBN:978-1-56592-117-7]

4. [http://www.ericsink.com/scm/source_control.html Eric Sink: A collection of articles on source control and best practices, Accessed:September 2010]

5. [http://basepath.com/aup/talks/SCCS-Slideshow.pdf M. J. Rochkind: The Source Code Control System.] In IEEE Transactions on Software Engineering SE-1:4 (Dec. 1975), pages 364–370.

6. [http://onlinelibrary.wiley.com/doi/10.1002/bltj.2039/pdf Martin, Robert L. (2002). "Software configuration management for the 21st century". Bell Labs technical journal, Volume 2, Issue 1, page- 154.]

7. Mike Mason; Pragmatic Version Control Using Subversion; Pragmatic Bookshelf; ISBN 0-9745140-6-3 (1st edition, paperback, 2005)

8. [http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ Noah Gift,Adam Shand: Introduction to distributed version control systems (compare how to use Bazaar, Mercurial, and Git) (Apr 2009), IBM Technical Library, Accessed:September 2010 ]

9.[http://onlinelibrary.wiley.com/doi/10.1002/spe.4380150703/abstract Walter F. Tichy; Rcs - a system for version control; In Software: Practice and Experience. Volume 15, Issue 7,(July 1985) pages 637–654 ]

==See also==
[http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision control]

[http://en.wikipedia.org/wiki/List_of_revision_control_software Wikipedia: List of revision control software]

[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Wikipedia: Detail comparison of revision control softwares]

[http://www.nongnu.org/cvs/ CVS webpage]

[http://www.cs.vu.nl/~dick/ Dick Grune's website on CVS history]

[http://groups.google.com/group/mod.sources/msg/2ebab72ac0744fb8?dmode=source The original usenet post on CVS] archived at google groups.

[http://linuxmafia.com/faq/Apps/vcs.html Linux availability of various version control softwares]