CSC/ECE 517 FALL 2009/wiki2 1 HJ

Responsibility-Driven Development (RDD)

Overview

Responsibility-Driven Design (or RDD) relies on objects and component technology to design complex software systems. In RDD, objects has object has responsibilities and collaborates with others to fulfill its responsibilities. Objects do what they can do and delegate the rest to the others. CRC (Class Responsibility Collaborator) [1] is a modeling technique used in RDD.

Strength

• RDD is effective in allowing the designer to incrementally add to the existing model.
• RDD permits a more cohesive design.

Weakness

• RDD is less detailed and rigorous than some other technique used in software engineering like Booch method [2] for example.

Use of RDD

RDD is used for an evolutionary design.

Test Driven Development (TDD)

Overview

Test Driven Development [3] (or TDD) uses the repetition of a very short development cycle. The developer writes a failing automated test case that defines a new function, then writes the code to pass that test and finally refactors the new code.

This picture from [4] summarizes the TDD method.

Strength

• Constant feedback that each component is still working is provided by the fact that we do small changes and test.

The unit tests act as documentation that cannot go out-of-date, unlike separate documentation, which can and frequently does.

• The developer can move on to a new test when the test is refactored because the code is finished.
• The software tends to be better designed. All the code is refactored.
• No need to use a debugger. TDD reduced debugging time!
• The developer understand the project and why this project is design to code the correct test and program.
• TDD enables us to take small steps when we write a software.
• Quick results: The effect of design decisions can be seen very quickly.
• Flexibility: Changes are easy because of the short distance between commits.

Weakness

• The high number of passing unit tests may bring a false sense of security.
• TDD can not be use in situations where full functional tests are required to determine success or failure. That's why TDD can not be used for programs that worked with databases or user interfaces.
• TDD means writing more tests.

Use of TDD

TDD is

Behavior Driven Development (BDD)

Behavior Driven Development (or BDD) is an Agile software development technique that focused on the language and interactions used in the process of software development. BDD encourages collaboration between developers and non-technical or business participants in a software project. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management etc.

Strength

• BDD increases feedback and communication in a software development.
• Behavior-driven developers use both their native language and the language of Domain Driven Design to describe the purpose and benefit of their code.
• BDD minimizes the hurdles between specification, design, implementation and confirmation of the behaviour of a system.

Weakness

• BDD depends on the success of TDD.
• BDD has his own vocabulary that you need to know to use it.

Use of BDD

BDD bridges the gap between the differing views of computer systems held by Business users and developers.

Domain Driven Development (DDD)

Overview

Domain-driven design (or DDD) is a technique to design software, where the complex domain design which is based on a model, and that focus on the domain and domain logic.

Strength

DDD uses the strengths of Object-Oriented software development techniques to simulate the core of the problem.

Model Driven Development (MDD)

Overview

Model Driven Development(or MDD) focuses on creating models, closer to some particular domain concepts rather than algorithmic concepts to create new software.

References

RDD

[1] http://www.xpday.net/html/Xpday2008/rdd_with_mockito.pdf

[2] http://www.wirfs-brock.com/Design.html

[3] http://codebetter.com/blogs/jeremy.miller/articles/131726.aspx

[4] http://www.cs.colorado.edu/~kena/classes/6448/s05/lectures/lecture05.pdf

[5] http://dspace.mit.edu/bitstream/handle/1721.1/38809/35561120.pdf?sequence=1

TDD

[6] http://en.wikipedia.org/wiki/Test-driven_development

[7] http://www.agiledata.org/essays/tdd.html

[8] http://c2.com/cgi/wiki?TestDrivenDevelopment

[9] http://www.developer.com/design/article.php/10925_3622546_1/Test-Driven-Development-a-Portable-Methodology.htm

[10] http://msdn.microsoft.com/en-us/library/aa730844(VS.80).aspx

BDD

[11] http://behaviour-driven.org/Introduction

[12] http://en.wikipedia.org/wiki/Behavior_Driven_Development

[13] http://www.code-magazine.com/article.aspx?quickid=0805061

DDD

[14] http://www.infoq.com/articles/ddd-in-practice

[15] http://en.wikipedia.org/wiki/Domain-driven_design

MDD

[16] http://en.wikipedia.org/wiki/Model-driven_engineering

[17] http://msdn.microsoft.com/en-us/library/aa964145.aspx

[18] http://searchsoa.techtarget.com/news/interview/0,289202,sid26_gci999474,00.html