CSC/ECE 517 FALL 2009/wiki2 1 HJ

From Expertiza_Wiki
Jump to navigation Jump to search

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 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.
  • RDD describes the responsibilities in terms that both users and developers can understand.
  • RDD simplifies interfaces and patterns of collaboration.

Weakness

  • RDD is less detailed and rigorous than some other technique used in software engineering like Booch method [2] for example.
  • RDD delegates some task that they could not do. RDD needs other software developing technique to code what it could not do.

Use of RDD

RDD build powerful and flexible applications.

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. It is easier to know when the code is correct.
  • 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 is difficult to use with programs that worked with databases or user interfaces.
  • TDD means writing more tests.
  • TDD is often specifically about the design of code units and modules such as classes.


Use of TDD

Programmers apply TDD to improve and debug legacy code developed with older techniques.

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 has his own vocabulary that you need to know to use it: the Ubiquitous language. BDD encourages collaboration between developers and non-technical or business participants in a software project. Developers can so 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.
  • Developers talking more about behaviors and less about implementation.
  • BDD minimizes the hurdles between specification, design, implementation and confirmation of the behaviour of a system.
  • BDD's focus addresses a much broader range of design concerns than TDD.

Weakness

  • BDD depends on the success of TDD.
  • BDD is influenced by DDD.

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, focuses on the domain and domain logic. DDD maps business domain concepts into software artifacts.

Strength

  • DDD uses the strengths of Object-Oriented software development techniques to simulate the core of the problem.
  • Different stakeholders (from IT and business units) with different backgrounds and areas of expertise are involved in DDD.

Weakness

  • It is difficult to reach an agreement between different actors of the design of the software.

Use of DDD

DDD is used for business units who are involved in the design of the software.

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. UML [5] is one example of the MDD. This picture from [6] is one example of an MDD project.


Strength

  • Decompose complex models into views.
  • MDD helps to visualize and analyze problems.
  • MDD helps to design information systems.
  • MDD helps to define business requirements.


Weakness

  • MDD costs a lot.
  • MDD takes a lot of time.

Use of MDD

MDD is the best option if fulfilling user requirements is the point to it all and quality is more important than cost and schedule.

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

[19] http://www.jscgroup.com/model-driven-development.html

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_FALL_2009/wiki2_1_HJ&oldid=26380"