Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 16 aa

2009-11-17T14:06:53Z

Bryson: More presentation issues

== Reuse/Release Principle ==

The Reuse/Release Principle was coined by Robert C. Martin in C++ Report 1996 and states that “The granule of reuse is the granule of release. Only components that are released through a tracking system can effectively be reused. This granule is the package.” [http://www.objectmentor.com/resources/articles/granularity.pdf [1]] This principle is one of several principles used in software design and development and is central to how packages should be built. Before attempting to understand the principle, a look at understanding the proper definition of code reuse is necessary.

== Definition of Reuse ==

Code reuse takes on different meanings to different people. To some, reuse may be the simple idea of cutting code from one module and copying in another. To others, reuse is copying a compiled class into another project or application. Both of those examples are in fact undeveloped versions of code reuse. They are better explained as copying code rather than examples of proper reuse. Why? Reusable code is better defined as packaged modules capable of being used in multiple applications but having a single residence, owner, and maintainer. Both the owner and maintainer are entities that may consist of one or multiple people.

== Requirements for Reuse ==

In order to effectively reuse code, several requirements should be met.
<ul><li>Packages – Dependent classes or modules are placed into a package. Packages are the foundation for reuse. They provide a place for all dependencies to be grouped and released collectively. For example, for a Health Insurance Claims Workfile system the following classes can be separated into different packages as shown below: </li>
 
<table border="1">
<tr><td WIDTH="25%">Patient Information (org.name.patient)</td><td WIDTH="25%">Claim Information (org.name.claim)</td></tr>
<tr><td WIDTH="25%">Patient</td><td WIDTH="25%">Claim</td></tr>
<tr><td WIDTH="25%">Account</td><td WIDTH="25%">Status</td></tr>
<tr><td WIDTH="25%">Policy</td><td WIDTH="25%">Medium</td></tr>
<tr><td WIDTH="25%">Insurance</td><td WIDTH="25%">Representative</td></tr></table>
 
Since all of the above classes work collectively, it is better to pull them together into one package, like org.name.claimworkfile, so that all of the classes are released as a whole. There could still be two subpackages of org.name.patient and org.name.claim. So a possible package structure of the above classes could be:
 
<ul><li>Claim Workfile (org.name.claimworkfile)</li>
<ul><li>Patient Information (org.name.patient)</li>
<ul><li>Patient</li>
<li>Account</li>
<li>Policy</li>
<li>Insurance</li></ul>
<li>Claim Information (org.name.claim)</li>
<ul><li>Claim</li>
<li>Status</li>
<li>Medium</li>
<li>Representative</li></ul></ul></ul>
 
<li>Release / Source Control – Packages should be placed under the governance of a source control or tracking system. The control system would manage the release of original packages as well as the enhanced versions. Each release would have a release or version number associated with it. Ideally clients or reusers would get notified before a release occurs so that they can plan and prioritize their schedule in order to incorporate the new package release.</li>
 
<li>Documentation – Proper documentation must accompany each release. Without good release notes it is difficult for the client who uses the package to easily incorporate it into their own application.</li></ul>

== Benefits of Reuse/Release Principle ==

The Reuse/Release Principle has several benefits for the client or reuser.
<ul><li>Decreased Maintenance [http://downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt [2]] – The client has less code that he must maintain himself.</li>

<li>Improved Quality [http://downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt [2]] - Since the client has less code to maintain, focus can be given to that which he does need to keep up. Also, the client does not have to be the only one to provide enhancements or new features to his application. As the supplier of the reused code periodically upgrades it, the client can take advantage of those upgrades without having to be the one who changed the code.</li>

<li>Automated Builds [http://cmcrossroads.tangram-studio.com/index2.php?option=com_content&do_pdf=1&id=5905 [3]] - Clients of reused code should take advantage of the tools that are available to automatically build their application from a storehouse of packages. That practice frees the developers from the IDE because their applications can be rebuilt outside of the IDE using a tool like ANT.</li>

<li>Robust software [http://www.objectmentor.com/resources/articles/granularity.pdf [1]] – Because the client does not have to develop every feature in his software from scratch, his software can include more features with much less effort or time for including those features.</li></ul>

== Disadvantages of Reuse/Release Principle ==

Everything that has an advantage typically has a disadvantage. The same is true for the Reuse/Release Principle.
<ul><li>Dependence on supplier – It is nice to be able to depend on the supplier for enhancements to a particular package of code. However, for the client it may be inconvenient at times and may possibly become a risk against meeting an implementation deadline. The client may need a bug fixed or an enhancement made to the reused package before their deliverable can be released. Yet, they are at the mercy of the supplier’s schedule as to when the update will be complete and ready for release.</li>

<li>Pressure from clients – While the clients may have it easier in some regard, the suppliers may not. They may be placed under pressure and time constraints that are proposed by their clients. Clients expect for the reused code to be bug free. Timely upgrades are also expected so that the code is current with trends and technologies. Suppliers may therefore feel the pressure of those client wishes as they lobby for position in their busy schedules.</li></ul>

== Links ==
<ol><li>[http://www.objectmentor.com/resources/articles/granularity.pdf Granularity]</li>
<li>[http://downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt Object Reuse]</li>
<li>[http://cmcrossroads.tangram-studio.com/index2.php?option=com_content&do_pdf=1&id=5905 Object Reuse Within the Enterprise: A Report From the Field]</li></ol>

CSC/ECE 517 Fall 2009/wiki3 16 aa

2009-11-17T13:42:39Z

Bryson: More presentation issues

== Reuse/Release Principle ==

The Reuse/Release Principle was coined by Robert C. Martin in C++ Report 1996 and states that “The granule of reuse is the granule of release. Only components that are released through a tracking system can effectively be reused. This granule is the package.” [http://www.objectmentor.com/resources/articles/granularity.pdf [1]] This principle is one of several principles used in software design and development and is central to how packages should be built. Before attempting to understand the principle, a look at understanding the proper definition of code reuse is necessary.

== Definition of Reuse ==

Code reuse takes on different meanings to different people. To some, reuse may be the simple idea of cutting code from one module and copying in another. To others, reuse is copying a compiled class into another project or application. Both of those examples are in fact undeveloped versions of code reuse. They are better explained as copying code rather than examples of proper reuse. Why? Reusable code is better defined as packaged modules capable of being used in multiple applications but having a single residence, owner, and maintainer. Both the owner and maintainer are entities that may consist of one or multiple people.

== Requirements for Reuse ==

In order to effectively reuse code, several requirements should be met.
<ul><li>Packages – Dependent classes or modules are placed into a package. Packages are the foundation for reuse. They provide a place for all dependencies to be grouped and released collectively. For example, for a Health Insurance Claims Workfile system the following classes can be separated into different packages as shown below: </li>
 
Patient Information Claim Information 
Patient&nbsp Claim 
PatientAccount&nbsp ClaimStatus 
PatientPolicy&nbsp ClaimMedium 
PatientInsurance&nbsp ClaimRepresentative 
 
However, since all of the above classes work collectively, it is better to pull them together into one package so that all of the classes are released as a whole.
 
<li>Release / Source Control – Packages should be placed under the governance of a source control or tracking system. The control system would manage the release of original packages as well as the enhanced versions. Each release would have a release or version number associated with it. Ideally clients or reusers would get notified before a release occurs so that they can plan and prioritize their schedule in order to incorporate the new package release.</li>
 
<li>Documentation – Proper documentation must accompany each release. Without good release notes it is difficult for the client who uses the package to easily incorporate it into their own application.</li></ul>

== Benefits of Reuse/Release Principle ==

The Reuse/Release Principle has several benefits for the client or reuser.
<ul><li>Decreased Maintenance [http://downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt [2]] – The client has less code that he must maintain himself.</li>

<li>Improved Quality [http://downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt [2]] - Since the client has less code to maintain, focus can be given to that which he does need to keep up. Also, the client does not have to be the only one to provide enhancements or new features to his application. As the supplier of the reused code periodically upgrades it, the client can take advantage of those upgrades without having to be the one who changed the code.</li>

<li>Automated Builds [http://cmcrossroads.tangram-studio.com/index2.php?option=com_content&do_pdf=1&id=5905 [3]] - Clients of reused code should take advantage of the tools that are available to automatically build their application from a storehouse of packages. That practice frees the developers from the IDE because their applications can be rebuilt outside of the IDE using a tool like ANT.</li>

<li>Robust software [http://www.objectmentor.com/resources/articles/granularity.pdf [1]] – Because the client does not have to develop every feature in his software from scratch, his software can include more features with much less effort or time for including those features.</li></ul>

== Disadvantages of Reuse/Release Principle ==

Everything that has an advantage typically has a disadvantage. The same is true for the Reuse/Release Principle.
<ul><li>Dependence on supplier – It is nice to be able to depend on the supplier for enhancements to a particular package of code. However, for the client it may be inconvenient at times and may possibly become a risk against meeting an implementation deadline. The client may need a bug fixed or an enhancement made to the reused package before their deliverable can be released. Yet, they are at the mercy of the supplier’s schedule as to when the update will be complete and ready for release.</li>

<li>Pressure from clients – While the clients may have it easier in some regard, the suppliers may not. They may be placed under pressure and time constraints that are proposed by their clients. Clients expect for the reused code to be bug free. Timely upgrades are also expected so that the code is current with trends and technologies. Suppliers may therefore feel the pressure of those client wishes as they lobby for position in their busy schedules.</li></ul>

== Links ==
<ol><li>[http://www.objectmentor.com/resources/articles/granularity.pdf Granularity]</li>
<li>[http://downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt Object Reuse]</li>
<li>[http://cmcrossroads.tangram-studio.com/index2.php?option=com_content&do_pdf=1&id=5905 Object Reuse Within the Enterprise: A Report From the Field]</li></ol>

CSC/ECE 517 Fall 2009/wiki3 16 aa

2009-11-17T13:37:30Z

Bryson: Fixing presentation issues

== Reuse/Release Principle ==

The Reuse/Release Principle was coined by Robert C. Martin in C++ Report 1996 and states that “The granule of reuse is the granule of release. Only components that are released through a tracking system can effectively be reused. This granule is the package.” [http://www.objectmentor.com/resources/articles/granularity.pdf [1]] This principle is one of several principles used in software design and development and is central to how packages should be built. Before attempting to understand the principle, a look at understanding the proper definition of code reuse is necessary.

== Definition of Reuse ==

Code reuse takes on different meanings to different people. To some, reuse may be the simple idea of cutting code from one module and copying in another. To others, reuse is copying a compiled class into another project or application. Both of those examples are in fact undeveloped versions of code reuse. They are better explained as copying code rather than examples of proper reuse. Why? Reusable code is better defined as packaged modules capable of being used in multiple applications but having a single residence, owner, and maintainer. Both the owner and maintainer are entities that may consist of one or multiple people.

== Requirements for Reuse ==

In order to effectively reuse code, several requirements should be met.
<ul><li>Packages – Dependent classes or modules are placed into a package. Packages are the foundation for reuse. They provide a place for all dependencies to be grouped and released collectively. For example, for a Health Insurance Claims Workfile system the following classes can be separated into different packages as shown below: </li>
 
Patient Information Claim Information 
Patient Claim 
PatientAccount ClaimStatus 
PatientPolicy ClaimMedium 
PatientInsurance ClaimRepresentative 
 
However, since all of the above classes work collectively, it is better to pull them together into one package so that all of the classes are released as a whole.
 
<li>Release / Source Control – Packages should be placed under the governance of a source control or tracking system. The control system would manage the release of original packages as well as the enhanced versions. Each release would have a release or version number associated with it. Ideally clients or reusers would get notified before a release occurs so that they can plan and prioritize their schedule in order to incorporate the new package release.</li>
 
<li>Documentation – Proper documentation must accompany each release. Without good release notes it is difficult for the client who uses the package to easily incorporate it into their own application.</li></ul>

== Benefits of Reuse/Release Principle ==

The Reuse/Release Principle has several benefits for the client or reuser.
<ul><li>Decreased Maintenance [http://downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt [2]] – The client has less code that he must maintain himself.</li>

<li>Improved Quality [http://downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt [2]] - Since the client has less code to maintain, focus can be given to that which he does need to keep up. Also, the client does not have to be the only one to provide enhancements or new features to his application. As the supplier of the reused code periodically upgrades it, the client can take advantage of those upgrades without having to be the one who changed the code.</li>

<li>Automated Builds [http://cmcrossroads.tangram-studio.com/index2.php?option=com_content&do_pdf=1&id=5905 [3]] - Clients of reused code should take advantage of the tools that are available to automatically build their application from a storehouse of packages. That practice frees the developers from the IDE because their applications can be rebuilt outside of the IDE using a tool like ANT.</li>

<li>Robust software [http://www.objectmentor.com/resources/articles/granularity.pdf [1]] – Because the client does not have to develop every feature in his software from scratch, his software can include more features with much less effort or time for including those features.</li></ul>

== Disadvantages of Reuse/Release Principle ==

Everything that has an advantage typically has a disadvantage. The same is true for the Reuse/Release Principle.
<ul><li>Dependence on supplier – It is nice to be able to depend on the supplier for enhancements to a particular package of code. However, for the client it may be inconvenient at times and may possibly become a risk against meeting an implementation deadline. The client may need a bug fixed or an enhancement made to the reused package before their deliverable can be released. Yet, they are at the mercy of the supplier’s schedule as to when the update will be complete and ready for release.</li>

<li>Pressure from clients – While the clients may have it easier in some regard, the suppliers may not. They may be placed under pressure and time constraints that are proposed by their clients. Clients expect for the reused code to be bug free. Timely upgrades are also expected so that the code is current with trends and technologies. Suppliers may therefore feel the pressure of those client wishes as they lobby for position in their busy schedules.</li></ul>

== Links ==
<ol><li>[http://www.objectmentor.com/resources/articles/granularity.pdf Granularity]</li>
<li>[http://downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt Object Reuse]</li>
<li>[http://cmcrossroads.tangram-studio.com/index2.php?option=com_content&do_pdf=1&id=5905 Object Reuse Within the Enterprise: A Report From the Field]</li></ol>

CSC/ECE 517 Fall 2009/wiki3 16 aa

2009-11-17T13:34:59Z

Bryson: Fixing the links

== Reuse/Release Principle ==

The Reuse/Release Principle was coined by Robert C. Martin in C++ Report 1996 and states that “The granule of reuse is the granule of release. Only components that are released through a tracking system can effectively be reused. This granule is the package.” [http://www.objectmentor.com/resources/articles/granularity.pdf [1]] This principle is one of several principles used in software design and development and is central to how packages should be built. Before attempting to understand the principle, a look at understanding the proper definition of code reuse is necessary.

== Definition of Reuse ==

Code reuse takes on different meanings to different people. To some, reuse may be the simple idea of cutting code from one module and copying in another. To others, reuse is copying a compiled class into another project or application. Both of those examples are in fact undeveloped versions of code reuse. They are better explained as copying code rather than examples of proper reuse. Why? Reusable code is better defined as packaged modules capable of being used in multiple applications but having a single residence, owner, and maintainer. Both the owner and maintainer are entities that may consist of one or multiple people.

== Requirements for Reuse ==

In order to effectively reuse code, several requirements should be met.
<ul><li>Packages – Dependent classes or modules are placed into a package. Packages are the foundation for reuse. They provide a place for all dependencies to be grouped and released collectively. For example, for a Health Insurance Claims Workfile system the following classes can be separated into different packages as shown below: </li>

Patient Information Claim Information
Patient Claim
PatientAccount ClaimStatus
PatientPolicy ClaimMedium
PatientInsurance ClaimRepresentative

However, since all of the above classes work collectively, it is better to pull them together into one package so that all of the classes are released as a whole.

<li>Release / Source Control – Packages should be placed under the governance of a source control or tracking system. The control system would manage the release of original packages as well as the enhanced versions. Each release would have a release or version number associated with it. Ideally clients or reusers would get notified before a release occurs so that they can plan and prioritize their schedule in order to incorporate the new package release.</li>

<li>Documentation – Proper documentation must accompany each release. Without good release notes it is difficult for the client who uses the package to easily incorporate it into their own application.</li></ul>

== Benefits of Reuse/Release Principle ==

The Reuse/Release Principle has several benefits for the client or reuser.
<ul><li>Decreased Maintenance [downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt [2]] – The client has less code that he must maintain himself.</li>

<li>Improved Quality [downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt [2]] - Since the client has less code to maintain, focus can be given to that which he does need to keep up. Also, the client does not have to be the only one to provide enhancements or new features to his application. As the supplier of the reused code periodically upgrades it, the client can take advantage of those upgrades without having to be the one who changed the code.</li>

<li>Automated Builds [http://cmcrossroads.tangram-studio.com/index2.php?option=com_content&do_pdf=1&id=5905 [3]] - Clients of reused code should take advantage of the tools that are available to automatically build their application from a storehouse of packages. That practice frees the developers from the IDE because their applications can be rebuilt outside of the IDE using a tool like ANT.</li>

<li>Robust software [http://www.objectmentor.com/resources/articles/granularity.pdf [1]] – Because the client does not have to develop every feature in his software from scratch, his software can include more features with much less effort or time for including those features.</li></ul>

== Disadvantages of Reuse/Release Principle ==

Everything that has an advantage typically has a disadvantage. The same is true for the Reuse/Release Principle.
<ul><li>Dependence on supplier – It is nice to be able to depend on the supplier for enhancements to a particular package of code. However, for the client it may be inconvenient at times and may possibly become a risk against meeting an implementation deadline. The client may need a bug fixed or an enhancement made to the reused package before their deliverable can be released. Yet, they are at the mercy of the supplier’s schedule as to when the update will be complete and ready for release.</li>

<li>Pressure from clients – While the clients may have it easier in some regard, the suppliers may not. They may be placed under pressure and time constraints that are proposed by their clients. Clients expect for the reused code to be bug free. Timely upgrades are also expected so that the code is current with trends and technologies. Suppliers may therefore feel the pressure of those client wishes as they lobby for position in their busy schedules.</li></ul>

== Links ==
<ol><li>[http://www.objectmentor.com/resources/articles/granularity.pdf Granularity]</li>
<li>[downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt Object Reuse]</li>
<li>[http://cmcrossroads.tangram-studio.com/index2.php?option=com_content&do_pdf=1&id=5905 Object Reuse Within the Enterprise: A Report From the Field]</li></ol>

CSC/ECE 517 Fall 2009/wiki3 16 aa

2009-11-17T13:27:48Z

Bryson: Initial entry

== Reuse/Release Principle ==

The Reuse/Release Principle was coined by Robert C. Martin in C++ Report 1996 and states that “The granule of reuse is the granule of release. Only components that are released through a tracking system can effectively be reused. This granule is the package.” [[1] http://www.objectmentor.com/resources/articles/granularity.pdf] This principle is one of several principles used in software design and development and is central to how packages should be built. Before attempting to understand the principle, a look at understanding the proper definition of code reuse is necessary.

== Definition of Reuse ==

Code reuse takes on different meanings to different people. To some, reuse may be the simple idea of cutting code from one module and copying in another. To others, reuse is copying a compiled class into another project or application. Both of those examples are in fact undeveloped versions of code reuse. They are better explained as copying code rather than examples of proper reuse. Why? Reusable code is better defined as packaged modules capable of being used in multiple applications but having a single residence, owner, and maintainer. Both the owner and maintainer are entities that may consist of one or multiple people.

== Requirements for Reuse ==

In order to effectively reuse code, several requirements should be met.
<ul><li>Packages – Dependent classes or modules are placed into a package. Packages are the foundation for reuse. They provide a place for all dependencies to be grouped and released collectively. For example, for a Health Insurance Claims Workfile system the following classes can be separated into different packages as shown below: </li>

Patient Information Claim Information
Patient Claim
PatientAccount ClaimStatus
PatientPolicy ClaimMedium
PatientInsurance ClaimRepresentative

However, since all of the above classes work collectively, it is better to pull them together into one package so that all of the classes are released as a whole.

<li>Release / Source Control – Packages should be placed under the governance of a source control or tracking system. The control system would manage the release of original packages as well as the enhanced versions. Each release would have a release or version number associated with it. Ideally clients or reusers would get notified before a release occurs so that they can plan and prioritize their schedule in order to incorporate the new package release.</li>

<li>Documentation – Proper documentation must accompany each release. Without good release notes it is difficult for the client who uses the package to easily incorporate it into their own application.</li></ul>

== Benefits of Reuse/Release Principle ==

The Reuse/Release Principle has several benefits for the client or reuser.
<ul><li>Decreased Maintenance [[2] downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt] – The client has less code that he must maintain himself.</li>

<li>Improved Quality [[2] downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt] - Since the client has less code to maintain, focus can be given to that which he does need to keep up. Also, the client does not have to be the only one to provide enhancements or new features to his application. As the supplier of the reused code periodically upgrades it, the client can take advantage of those upgrades without having to be the one who changed the code.</li>

<li>Automated Builds [[3] http://cmcrossroads.tangram-studio.com/index2.php?option=com_content&do_pdf=1&id=5905] - Clients of reused code should take advantage of the tools that are available to automatically build their application from a storehouse of packages. That practice frees the developers from the IDE because their applications can be rebuilt outside of the IDE using a tool like ANT.</li>

<li>Robust software [[1] http://www.objectmentor.com/resources/articles/granularity.pdf] – Because the client does not have to develop every feature in his software from scratch, his software can include more features with much less effort or time for including those features.</li></ul>

== Disadvantages of Reuse/Release Principle ==

Everything that has an advantage typically has a disadvantage. The same is true for the Reuse/Release Principle.
<ul><li>Dependence on supplier – It is nice to be able to depend on the supplier for enhancements to a particular package of code. However, for the client it may be inconvenient at times and may possibly become a risk against meeting an implementation deadline. The client may need a bug fixed or an enhancement made to the reused package before their deliverable can be released. Yet, they are at the mercy of the supplier’s schedule as to when the update will be complete and ready for release.</li>

<li>Pressure from clients – While the clients may have it easier in some regard, the suppliers may not. They may be placed under pressure and time constraints that are proposed by their clients. Clients expect for the reused code to be bug free. Timely upgrades are also expected so that the code is current with trends and technologies. Suppliers may therefore feel the pressure of those client wishes as they lobby for position in their busy schedules.</li></ul>

== Links ==
<ol><li>[[Granularity] http://www.objectmentor.com/resources/articles/granularity.pdf]</li>
<li>[[Object Reuse] downloads.urbancode.com/presentations/reuse/ObjectReuse.ppt]</li>
<li>[[Object Reuse Within the Enterprise: A Report From the Field] http://cmcrossroads.tangram-studio.com/index2.php?option=com_content&do_pdf=1&id=5905]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:48:01Z

Bryson: /* Survey of “Driven Development” Methodologies */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li></ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]

Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

<ul><li>The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.</li>
<li>Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.</li>
<li>Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.</li></ul>

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li></ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]

In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]

Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li></ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]

Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
. . .
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
. . .
public void start(Transaction transaction) {
account.process(transaction);
}
. . .
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:47:38Z

Bryson: /* Test Driven Development */

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:46:53Z

Bryson: /* Behavior Driven Development */

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:46:26Z

Bryson: /* Model Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li></ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

<ul><li>The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.</li>
<li>Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.</li>
<li>Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.</li></ul>

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li></ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]

In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]

Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li></ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]

Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
. . .
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
. . .
public void start(Transaction transaction) {
account.process(transaction);
}
. . .
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:46:00Z

Bryson: /* Domain Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li></ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

<ul><li>The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.</li>
<li>Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.</li>
<li>Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.</li></ul>

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li></ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]

Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li></ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]

Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
. . .
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
. . .
public void start(Transaction transaction) {
account.process(transaction);
}
. . .
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:45:37Z

Bryson: /* Responsibility Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li></ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

<ul><li>The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.</li>
<li>Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.</li>
<li>Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.</li></ul>

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li></ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li></ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]

Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
. . .
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
. . .
public void start(Transaction transaction) {
account.process(transaction);
}
. . .
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:45:14Z

Bryson: /* Responsibility Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li></ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

<ul><li>The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.</li>
<li>Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.</li>
<li>Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.</li></ul>

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li></ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li></ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]

Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
. . .
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
. . .
public void start(Transaction transaction) {
account.process(transaction);
}
. . .
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:45:04Z

Bryson: /* Responsibility Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li></ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

<ul><li>The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.</li>
<li>Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.</li>
<li>Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.</li></ul>

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li></ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li></ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
. . .
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
. . .
public void start(Transaction transaction) {
account.process(transaction);
}
. . .
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:43:10Z

Bryson: /* Domain Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li></ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

<ul><li>The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.</li>
<li>Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.</li>
<li>Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.</li></ul>

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li></ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li></ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:42:30Z

Bryson: /* Behavior Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li></ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

<ul><li>The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.</li>
<li>Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.</li>
<li>Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.</li></ul>

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li></ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:41:33Z

Bryson: /* Test Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li></ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

<ul><li>The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.</li>
<li>Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.</li>
<li>Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.</li>

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li></ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:40:56Z

Bryson: /* Model Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li><ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

<ul><li>The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.</li>
<li>Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.</li>
<li>Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.</li>

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li></ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:38:44Z

Bryson: /* Behavior Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li><ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

<ul><li>The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.</li>
<li>Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.</li>
<li>Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.</li>

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li><ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:35:30Z

Bryson: /* Behavior Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li><ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.
Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.
Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li><ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:34:21Z

Bryson: /* Test Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li><ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.

Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.

Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li><ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:33:40Z

Bryson: /* Test Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li><ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]] The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.

Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.

Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li><ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:32:24Z

Bryson: /* Test Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li><ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]] The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.

Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.

Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li><ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:30:50Z

Bryson: /* Behavior Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li><ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]] The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.

Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.

Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li><ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:30:06Z

Bryson: /* Test Driven Development */

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li><ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]] The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]

All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.

Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.

Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li><ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T15:29:12Z

Bryson: Adding links

==Survey of “Driven Development” Methodologies==

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [http://video.google.com/videoplay?docid=8135690990081075324# [4]] That process is focused on writing [http://en.wikipedia.org/wiki/Unit_test unit tests] first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li><ol>

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling]</li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Code implementation time is typically shorter. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]] The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the [http://en.wikipedia.org/wiki/Unit_test unit tests] [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Difficult to use for [http://en.wikipedia.org/wiki/User_interface UI] code or code that works with databases or certain network configurations [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests can become a maintenance overhead [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [http://en.wikipedia.org/wiki/Test_Driven_Development [6]]</li></ul>

[[Example]]
All examples in this article will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], system behavior is described using “should” statements. Then, those statements are further defined using the words ''Given'', ''When'', and ''Then''. [http://en.wikipedia.org/wiki/Behavior_Driven_Development [3]] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [http://video.google.com/videoplay?docid=8135690990081075324# [4]] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the [http://en.wikipedia.org/wiki/State_%28computer_science%29 state] of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the [http://en.wikipedia.org/wiki/User_interface UI] is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the [http://en.wikipedia.org/wiki/User_interface UI] and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the [http://en.wikipedia.org/wiki/User_story user story] practices from [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and Test Driven Development practices from XP.” [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Increases “. . . fluidity between analysis and design”. [http://www.code-magazine.com/article.aspx?quickid=0805061 [5]]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the ''Given'', ''When'', ''Then'' example given above:

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the [http://en.wikipedia.org/wiki/User_interface UI] to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.

Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.

Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [http://en.wikipedia.org/wiki/Model-driven_engineering [9]] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li><ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language (UML)]:

[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard [http://en.wikipedia.org/wiki/Object_oriented_design Object Oriented Design]. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Can be applied to different development languages or platforms [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design [7]]</li>
<li>Should not be used on complex legacy systems [http://www.infoq.com/interviews/eric-evans-ddd-interview [8]]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [http://www.methodsandtools.com/archive/archive.php?id=90 [1]]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]] </li>
<li>Intelligent objects that do more than hold data [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf [2]]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the [http://en.wikipedia.org/wiki/Software_development_lifecycle software lifecycle], the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. [http://en.wikipedia.org/wiki/Crc_cards CRC] (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

==Links==
<ol><li>[http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]</li>
<li>[http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]</li>
<li>[http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]</li>
<li>[http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]</li>
<li>[http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]</li>
<li>[http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]</li>
<li>[http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]</li>
<li>[http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD]</li>
<li>[http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]</li></ol>

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T14:54:27Z

Bryson: Added images

==Survey of “Driven Development” Methodologies==
--------------------------------------------------------------------------------------------------------------------------------------------------------

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==
--------------------------------------------------------------------------------------------------------------------------------------------------------

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [4] That process is focused on writing unit tests first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li><ol>

[[Strengths]]
<ul><li>Loose or low coupling</li>
<li>High cohesion</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [6]</li>
<li>Code implementation time is typically shorter. [6] The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [6]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the unit tests [6]</li>
<li>Difficult to use for UI code or code that works with databases or certain network configurations [6]</li>
<li>Tests can become a maintenance overhead [6]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [6]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [6]</li></ul>

[[Example]]
All examples in this wiki will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==
--------------------------------------------------------------------------------------------------------------------------------------------------------

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [3] During the design phase of the software lifecycle, system behavior is described using “should” statements. Then, those statements are further defined using the words Given, When, and Then. [3] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [4] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the state of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the UI is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the UI and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the user story practices from Scrum and Test Driven Development practices from XP.” [5]</li>
<li>Increases “. . . fluidity between analysis and design”. [5]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the Given, When, Then example given above:
'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the UI to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.

Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.

Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==
--------------------------------------------------------------------------------------------------------------------------------------------------------

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [9] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li><ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using Unified Modeling Language (UML):

**Image**
[[Image:UML.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==
--------------------------------------------------------------------------------------------------------------------------------------------------------

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [7] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard Object Oriented Design. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [7]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [7]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD [7]</li>
<li>Can be applied to different development languages or platforms [7]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [7]</li>
<li>Should not be used on complex legacy systems [8]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==
--------------------------------------------------------------------------------------------------------------------------------------------------------

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [1]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [2] </li>
<li>Intelligent objects that do more than hold data [2]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the software lifecycle, the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. CRC (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

**Image**
[[Image:CRC.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==
--------------------------------------------------------------------------------------------------------------------------------------------------------

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

Links
1) [http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]
2) [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]
3) [http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]
4) [http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]
5) [http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]
6) [http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]
7) [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]
8) [http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD
9) [http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]

File:UML.jpg

2009-10-09T14:53:35Z

Bryson:

File:CRC.jpg

2009-10-09T14:53:19Z

Bryson:

CSC/ECE 517 Fall 2009/wiki2 19 aa

2009-10-09T14:52:33Z

Bryson: Initial entry

==Survey of “Driven Development” Methodologies==
--------------------------------------------------------------------------------------------------------------------------------------------------------

It seems that the discipline of software engineering has been inundated with methodologies with names ending in “driven development” or “driven design”. Each of the methodologies asserts that it is important for a developer to be driven by a specific concept as he/she designs a software system. Some of the methodologies are totally new and others simply supply new names to ideas that have been around for years. None of the methodologies present a perfect way to design code. Each of them has its own niche in the software community.

In this wiki, we will explore the following subset of the “driven development” methodologies:

<ul><li>Test Driven Development (TDD)</li>
<li>Behavior Driven Development (BDD)</li>
<li>Model Driven Development (MDD)</li>
<li>Domain Driven Development (DDD)</li>
<li>Responsibility Driven Development (RDD)</li></ul>

A brief overview of each methodology is given along with its strengths and weaknesses. As a conclusion, we will discuss when each methodology should be put into practice.

==Test Driven Development==
--------------------------------------------------------------------------------------------------------------------------------------------------------

Despite the name, Test Driven Development (TDD) is not about testing. It is a design process. [4] That process is focused on writing unit tests first and then writing the application code that will cause the test to pass. TDD is described using four simple steps:

<ol><li>Write a test and watch it fail.</li>
<li>Write code that will cause the test to pass.</li>
<li>Rerun the test and watch it succeed.</li>
<li>Repeat.</li><ol>

[[Strengths]]
<ul><li>Loose or low coupling</li>
<li>High cohesion</li>
<li>Virtually bug-free code</li>
<li>Can be used in conjunction with all other “driven development” methodologies</li>
<li>Ensures that all code has a test that validates its correctness which produces an overall trust of the code [6]</li>
<li>Code implementation time is typically shorter. [6] The tests help to eliminate defects early which will decrease the amount of debugging necessary before implementation. [6]</li></ul>

[[Weaknesses]]
<ul><li>More code is required due to the unit tests [6]</li>
<li>Difficult to use for UI code or code that works with databases or certain network configurations [6]</li>
<li>Tests can become a maintenance overhead [6]</li>
<li>Less quality assurance activities may be put into place based on a false sense of security in the code [6]</li>
<li>Tests may still include gaps or blind spots since the developer that writes the tests is also writing the code that the tests are working on [6]</li></ul>

[[Example]]
All examples in this wiki will be based on a banking transaction. A bank is requesting a new application that would allow tellers to create new checking or savings accounts, process a transaction like a withdrawal, or close an account.

For TDD, the developer may start by writing a test that assumes that an object called CheckingAccount receives a non-zero deposit when it is created.

public class BankAppTest extends TestCase {
public void testCheckingAccountInitialDepositNotZero() {
try {
CheckingAccount checkingAccount = new CheckingAccount(0.00);
fail(“Zero dollar initial deposit should throw an exception.”)
} catch(ZeroDepositException zde) {
//This is the correct action so the test should pass
}
}
}

The developer would then run the test and see that it would fail due to the fact that no code has been written for the object CheckingAccount. Next, it is time to write just enough code to cause the test to pass.

public class BankingOnline {
public static void main(String args[]){
}
}

public class CheckingAccount {
public CheckingAccount(float initialAmount) {
if (initialAmount <= 0) throw new ZeroDepositException(“Initial Deposit”);
}
}

public class ZeroDepositException implements Throwable {
public ZeroDepositException(String inMessage) {
super(inMessage + “ cannot be zero!”);
}
}

Another run of the test should find that it succeeds. Repeat the process until all features have been developed.

==Behavior Driven Development==
--------------------------------------------------------------------------------------------------------------------------------------------------------

Behavior Driven Development (BDD) is the process of designing software by creating objects that accomplish certain behaviors expected of the system. “Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.” [3] During the design phase of the software lifecycle, system behavior is described using “should” statements. Then, those statements are further defined using the words Given, When, and Then. [3] For example,

'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

BDD is basically an extension of Test Driven Development. Dave Astels says that BDD is “what you are doing already if you are doing Test Driven Development very well.” [4] BDD redefines some of the terms as well as the focus of TDD in its early adoption. For example, TDD was focused on writing tests that would verify the state of an object. BDD should still use TDD because development is still driven by writing “tests” first. However, the tests should verify that an expected behavior occurred rather than verifying the state of an object after a segment of code has been executed.

BDD takes an outside-in approach to designing a system. Typically, the UI is the first part of the system that is written. If the prototypes are accepted as behaving appropriately, then developers move forward to create objects that collaborate with the UI and so on. Therefore, one system feature is fully developed before continuing to another feature.

[[Strengths]]
<ul><li>“. . . creates more harmony between the user story practices from Scrum and Test Driven Development practices from XP.” [5]</li>
<li>Increases “. . . fluidity between analysis and design”. [5]</li>
<li>Focuses on behaviors that add value to the business</li></ul>

[[Weaknesses]]
<ul><li>Could lead to tight coupling of various objects since one feature is developed at a time.</li></ul>

[[Example]]
Back to the banking application . . . we will use the Given, When, Then example given above:
'''''Given''''' a checking account,
'''''When''''' a customer opens the account,
'''''Then''''' the initial deposit should be greater than zero.

The developer would begin by creating the UI to allow the banker to open a new checking account for a customer. Before any code is written, the UI would be described using “should” statements.

The banking application should have a main screen with buttons for opening a new account, processing a transaction, and closing an account.

Clicking the “Create New Account” button should bring up a new screen that will ask the banker what type of account is to be created – checking or savings – as well as the initial deposit for the account.

Entering zero for the initial deposit should display an error message once the banker exits the initial deposit field.

Software code would be created to accomplish the behavior described by each “should” statement. A prototype would be presented to the end-user with the purpose of gaining acceptance of the behavior(s) exhibited.

==Model Driven Development==
--------------------------------------------------------------------------------------------------------------------------------------------------------

Model Driven Development (MDD) is the process of designing a software system where the focus is put on producing models for a given domain. System specifications are described in the form of models which are developed through extensive communication between the development team and the business experts. The models are considered effective if both the end-user and the development team can understand them. [9] Objects are then developed based on the models.

[[Strengths]]
<ul><li>Buy-in from the end-user for the system design is easier to gain because of the work put into having them be able to thoroughly understand the models prior to developing the system</li>
<li>Design is more thorough because the end-user or business experts as well as system architects are intricately involved in the system design from the ground up.</li>
<li>Helps to reduce risk because areas of risk are discovered early in the development process</li><ul>

[[Weaknesses]]
<ul><li>Model development is highly dependent on a specified toolset and typically requires being locked-in to a specific vendor.</li>
<li>One object often has a relationship with many other objects which create numerous dependencies. </li></ul>

[[Example]]
In order to design the banking application we have used thus far, MDD developers would create a set of models that would provide a picture of the system to be created. That picture could be described graphically or with text. Here’s an example of one type of model that could be created using Unified Modeling Language (UML):

**Image**
[[Image:Example.jpg]]

Similar to BDD, once the models have been accepted by both developers and business experts, software code would be created to accomplish the behavior described by each model.

==Domain Driven Development==
--------------------------------------------------------------------------------------------------------------------------------------------------------

Domain Driven Development (DDD) is the process of designing software by concentrating on thoroughly understanding the domain in which the product will live. Some example domains are shipping, banking, academia, and health care. DDD is all about avoiding the problem of having many objects that talk to many other objects which produces a lot of dependencies. [7] Such a problem is one of the weaknesses of Model Driven Development. As a matter of fact, DDD is based on MDD in that models are used to design a system. However, those models are based on an intricate knowledge of the domain or business logic. So, DDD forces the developer to thoroughly learn the domain and then incorporate it into the code. That process helps bridge the gap between business experts and developers. The basics of DDD are not much different than what has been used for years in standard Object Oriented Design. However, one of the major differences is the practice of forming that distinct or ubiquitous language that is shared between business experts and software developers. [7]

[[Strengths]]
<ul><li>The core model is clean and aides in maintainability of the software [7]</li>
<li>Code is test-friendly and goes hand-in-hand with TDD [7]</li>
<li>Can be applied to different development languages or platforms [7]</li></ul>

[[Weaknesses]]
<ul><li>Translations between domain model and infrastructure should not be done by hand and all languages do not have good tools to automate that process [7]</li>
<li>Should not be used on complex legacy systems [8]</li></ul>

[[Example]]
Once again we go back to the banking example . . .

First, the development team would have conversations with the business experts seeking to fully understand the details of business processes and rules of the bank requesting the software. Some such rules that may be discovered are as follows:

<ul><li>A checking account cannot be created without first establishing a savings account.</li>
<li>A savings account balance cannot ever go below $10.</li>
<li>A savings account withdrawal request would be denied if the balance after the withdrawal was less than $10.</li><ul>

Those domain details would be incorporated into the remaining design of the software system. They would also drive how the system behaves and the responsibilities managed by each object produced.

==Responsibility Driven Development==
--------------------------------------------------------------------------------------------------------------------------------------------------------

Responsibility Driven Development (RDD) is the process of designing software by developing objects based on their roles and responsibilities in the system. During the design phase of a system, candidate objects are identified by the concepts mentioned repeatedly. Most often, those candidate objects will be passive. Responsibilities are defined by making the candidate objects active. [1]

[[Strengths]]
<ul><li>[http://en.wikipedia.org/wiki/Loose_coupling Loose or low coupling] </li>
<li>[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 High cohesion]</li>
<li>Flexible applications that are easily changed when requirements change [2] </li>
<li>Intelligent objects that do more than hold data [2]</li></ul>

[[Weaknesses]]
<ul><li>Code reuse is not as prevalent since roles and responsibilities are not typically shared among applications. In contrast, some of the collaboration objects may be readily reused.</li></ul>

[[Example]]
Once again, we will use the example of the banking system. This time, let’s look at the process of a withdrawal request.
During the design phase of the software lifecycle, the development team would find candidate objects used to implement a role within the banking application. One such role would be a withdrawal procedure which could be implemented by the candidate object WithdrawalProcedure. CRC (Class, Responsibility, Collaboration) cards are used to describe each of the candidates. There are a few different ways those cards could be structured. One way is to place the name of the candidate object at the top of the card with a list of responsibilities on the left and a list of collaboration objects on the right.

**Image**
[[Image:Example.jpg]]

Once all candidates have been established, the code can be written to implement each candidate.

public class WithdrawalProcedure {
private BankAccount account;
...
public WithdrawalProcedure(BankAccount inAccount) {
account = inAccount;
}
...
public void start(Transaction transaction) {
account.process(transaction);
}
...
}

== So now what? ==
--------------------------------------------------------------------------------------------------------------------------------------------------------

Now that we have supplied an overview of each of the methodologies, we need to look at when it is appropriate to use them. Test Driven Development can and should be used in combination with all of other the methodologies mentioned above. It is a solid way of creating a software system that can be trusted once it is released into a production environment. Domain Driven Development can also be used in combination with all of the other methodologies. It is always beneficial to thoroughly understand the domain for a given system and then allow those details to drive the way that objects are defined whether that is focused on behavior, models, or responsibilities. However, Domain Driven Development is not necessarily a good fit when a given system does not contain complex business logic.
The remaining methodologies do not necessarily have a given situation in which one should be used in place of another. The only methodology that has a situation that would make it less attractive to use is Model Driven Development. Since MDD is focused on creating models that the end-user or business expert fully understands, it may not be useful to use Model Driven Development for projects where the business expert is not interested in being an intricate part of the development cycle. Those situations are rare, but they do exist.

Links
1) [http://www.methodsandtools.com/archive/archive.php?id=90 Responsibility Driven Design with Mock Objects]
2) [http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf A Brief Tour of RDD]
3) [http://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipedia – Behavior Driven Development]
4) [http://video.google.com/videoplay?docid=8135690990081075324# Beyond Test Driven Development – Behaviour Driven Development]
5) [http://www.code-magazine.com/article.aspx?quickid=0805061 Behavior Driven Development]
6) [http://en.wikipedia.org/wiki/Test_Driven_Development Wikipedia - Test Driven Development]
7) [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nillson on Domain Driven Design]
8) [http://www.infoq.com/interviews/eric-evans-ddd-interview Eric Evans on the State of DDD
9) [http://en.wikipedia.org/wiki/Model-driven_engineering Wikipedia – Model Driven Development]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-08T12:48:05Z

Bryson: /* Distributed Version Control */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is one way to manage or control revisions of a software package. Unlike the closely related [http://en.wikipedia.org/wiki/Version_control_system Version Control Systems] (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[[http://en.wikipedia.org/wiki/Revision_control 2]] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list below gives a few of those advantages, but is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and branches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[[http://en.wikipedia.org/wiki/Distributed_revision_control 1]]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

6. Developers using such methods as [http://en.wikipedia.org/wiki/Extreme_programming eXtreme] or [http://en.wikipedia.org/wiki/Pair_programming pair programming] can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

== Disadvantages ==

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive but does provide a few disadvantages.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller, disjointed working versions, but not a central one. [[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ 4]]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products. [[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

== External Links ==

1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]

2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]

3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]

4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]

5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]

6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-08T12:47:52Z

Bryson: /* Distributed Version Control */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is one way to manage or control revisions of a software package. Unlike the closely related[http://en.wikipedia.org/wiki/Version_control_system Version Control Systems] (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[[http://en.wikipedia.org/wiki/Revision_control 2]] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list below gives a few of those advantages, but is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and branches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[[http://en.wikipedia.org/wiki/Distributed_revision_control 1]]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

6. Developers using such methods as [http://en.wikipedia.org/wiki/Extreme_programming eXtreme] or [http://en.wikipedia.org/wiki/Pair_programming pair programming] can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

== Disadvantages ==

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive but does provide a few disadvantages.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller, disjointed working versions, but not a central one. [[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ 4]]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products. [[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

== External Links ==

1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]

2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]

3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]

4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]

5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]

6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-08T12:46:44Z

Bryson: /* Advantages */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[[http://en.wikipedia.org/wiki/Revision_control 2]] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list below gives a few of those advantages, but is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and branches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[[http://en.wikipedia.org/wiki/Distributed_revision_control 1]]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

6. Developers using such methods as [http://en.wikipedia.org/wiki/Extreme_programming eXtreme] or [http://en.wikipedia.org/wiki/Pair_programming pair programming] can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

== Disadvantages ==

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive but does provide a few disadvantages.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller, disjointed working versions, but not a central one. [[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ 4]]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products. [[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

== External Links ==

1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]

2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]

3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]

4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]

5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]

6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-08T12:45:04Z

Bryson: /* Disadvantages */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[[http://en.wikipedia.org/wiki/Revision_control 2]] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list below gives a few of those advantages, but is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and branches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[[http://en.wikipedia.org/wiki/Distributed_revision_control 1]]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

== Disadvantages ==

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive but does provide a few disadvantages.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller, disjointed working versions, but not a central one. [[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ 4]]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products. [[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

== External Links ==

1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]

2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]

3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]

4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]

5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]

6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-08T12:41:19Z

Bryson: /* Advantages */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[[http://en.wikipedia.org/wiki/Revision_control 2]] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list below gives a few of those advantages, but is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and branches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[[http://en.wikipedia.org/wiki/Distributed_revision_control 1]]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

== Disadvantages ==

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller working versions, but not a central one.[[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ 4]]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products.[[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

== External Links ==

1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]

2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]

3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]

4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]

5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]

6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-08T12:34:04Z

Bryson: /* Distributed Version Control */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[[http://en.wikipedia.org/wiki/Revision_control 2]] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and braches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[[http://en.wikipedia.org/wiki/Distributed_revision_control 1]]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

== Disadvantages ==

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller working versions, but not a central one.[[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ 4]]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products.[[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

== External Links ==

1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]

2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]

3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]

4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]

5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]

6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-05T19:31:46Z

Bryson: /* Disadvantages */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is a one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[[http://en.wikipedia.org/wiki/Revision_control 2]] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and braches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[[http://en.wikipedia.org/wiki/Distributed_revision_control 1]]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

== Disadvantages ==

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller working versions, but not a central one.[[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ 4]]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products.[[http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html 3]]

== External Links ==

1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]

2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]

3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]

4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]

5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]

6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-05T19:30:44Z

Bryson: /* Advantages */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is a one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[[http://en.wikipedia.org/wiki/Revision_control 2]] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and braches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[[http://en.wikipedia.org/wiki/Distributed_revision_control 1]]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 5]]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[[http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf 6]]

== Disadvantages ==

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller working versions, but not a central one.[4]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [3]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products.[3]

== External Links ==

1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]

2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]

3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]

4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]

5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]

6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-05T19:27:39Z

Bryson: /* Distributed Version Control */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is a one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[[http://en.wikipedia.org/wiki/Revision_control 2]] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and braches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[5]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[1]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[5]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[6]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[6]

== Disadvantages ==

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller working versions, but not a central one.[4]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [3]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products.[3]

== External Links ==

1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]

2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]

3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]

4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]

5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]

6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-05T19:25:43Z

Bryson: /* External Links */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is a one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[2] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and braches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[5]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[1]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[5]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[6]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[6]

== Disadvantages ==

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller working versions, but not a central one.[4]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [3]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products.[3]

== External Links ==

1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]

2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]

3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]

4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]

5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]

6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-05T19:25:20Z

Bryson: /* External Links */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is a one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[2] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and braches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[5]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[1]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[5]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[6]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[6]

== Disadvantages ==

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller working versions, but not a central one.[4]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [3]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products.[3]

== External Links ==
-----------------------------------------------------------------------------------------------------------------------------------------------------
1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control

2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]

3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]

4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]

5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]

6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-05T19:25:03Z

Bryson: /* Disadvantages */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is a one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[2] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and braches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[5]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[1]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[5]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[6]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[6]

== Disadvantages ==

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller working versions, but not a central one.[4]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [3]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products.[3]

== External Links ==
-----------------------------------------------------------------------------------------------------------------------------------------------------
1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]
2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]
3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]
4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]
5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]
6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-05T19:24:54Z

Bryson: /* Advantages */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is a one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[2] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==

DVC has several advantages over VCS. This list is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and braches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[5]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[1]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[5]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[6]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[6]

== Disadvantages ==
-----------------------------------------------------------------------------------------------------------------------------------------------------

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller working versions, but not a central one.[4]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [3]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products.[3]

== External Links ==
-----------------------------------------------------------------------------------------------------------------------------------------------------
1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]
2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]
3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]
4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]
5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]
6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-05T19:24:42Z

Bryson: /* History */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is a one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[2] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==
-----------------------------------------------------------------------------------------------------------------------------------------------------

DVC has several advantages over VCS. This list is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and braches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[5]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[1]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[5]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[6]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[6]

== Disadvantages ==
-----------------------------------------------------------------------------------------------------------------------------------------------------

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller working versions, but not a central one.[4]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [3]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products.[3]

== External Links ==
-----------------------------------------------------------------------------------------------------------------------------------------------------
1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]
2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]
3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]
4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]
5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]
6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-05T19:24:32Z

Bryson: /* Distributed Version Control */

== Distributed Version Control ==

Distributed Version Control (DVC or DVCS) is a one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[2] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==
-----------------------------------------------------------------------------------------------------------------------------------------------------

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==
-----------------------------------------------------------------------------------------------------------------------------------------------------

DVC has several advantages over VCS. This list is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and braches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[5]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[1]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[5]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[6]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[6]

== Disadvantages ==
-----------------------------------------------------------------------------------------------------------------------------------------------------

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller working versions, but not a central one.[4]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [3]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products.[3]

== External Links ==
-----------------------------------------------------------------------------------------------------------------------------------------------------
1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]
2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]
3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]
4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]
5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]
6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]

CSC/ECE 517 Fall 2009/wiki1a 1 aa

2009-09-05T19:24:00Z

Bryson: Distributed Version Control

== Distributed Version Control ==

-----------------------------------------------------------------------------------------------------------------------------------------------------

Distributed Version Control (DVC or DVCS) is a one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[2] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

== History ==
-----------------------------------------------------------------------------------------------------------------------------------------------------

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

== Advantages ==
-----------------------------------------------------------------------------------------------------------------------------------------------------

DVC has several advantages over VCS. This list is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and braches. Commits, rollbacks, and revision diffs are possible without being connected to a network.[5]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[1]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[5]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[6]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[6]

== Disadvantages ==
-----------------------------------------------------------------------------------------------------------------------------------------------------

Just as there are several advantages to using Distributed Version Control, there are also disadvantages. Again, this list is in no way comprehensive.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller working versions, but not a central one.[4]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [3]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products.[3]

== External Links ==
-----------------------------------------------------------------------------------------------------------------------------------------------------
1. [http://en.wikipedia.org/wiki/Distributed_revision_control Wikipedia: Distributed Revision Control]
2. [http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision Control]
3. [http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html John Arbash Meinel's Bazaar Blog: Bazaar vs Subversion]
4. [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated)]
5. [http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Wincent Colaiuta's weblog: Why distributed version control]
6. [http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf Distributed Version Control Systems - Why and How]