CSC/ECE 517 Fall 2009/wiki2 19 as

Development Methodologies

Responsibility Driven Design

Overview

Responsibility-driven design (RDD) is a way of designing complex software systems using objects and component technology. RDD was conceived as a shift from thinking about objects as data + algorithms, to thinking about objects as roles + responsibilities. In a responsibility-based model, objects play specific roles and occupy well-known positions in the application architecture. It is a smoothly-running community of objects. Each object is accountable for a specific portion of the work. Objects collaborate in clearly-defined ways, contracting with each other to fulfill the larger goals of the application. By creating such a “community of objects,” assigning specific responsibilities to each, you build a collaborative model of your application[1].

Strengths

• In RDD, Objects are service-providers, information-holders, structurers, coordinators, controllers, and interfacers to the outside world. Each must know and do its part! Thinking in terms of these object role stereotypes enables you to build powerful, flexible applications. Developing consistent control styles for similar parts of your application reduces maintenance costs. Incorporating flexibility into your design at specific “flex points” allows for planned extensions[1].

• Information encapsulation is maintained, since objects use their own information to fulfill tasks. This usually supports low coupling, which leads to more robust and maintainable systems. Behavior is distributed across the classes that have the required information, encouraging more cohesive “lightweight” class definitions that are easier to understand and maintain. High cohesion is usually supported[2].

Test Driven Development

Overview

Test-driven development (TDD) is a software development technique that relies on the repetition of a very short development cycle: First the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards[3].

The following flowchart shows the typical development cycle of TDD[3]:

Strengths

• Test-driven development offers more than just simple validation of correctness, but can also drive the design of a program. By focusing on the test cases first, one must imagine how the functionality will be used by clients (in the first case, the test cases). So, the programmer is only concerned with the interface and not the implementation. This benefit is complementary to Design by Contract as it approaches code through test cases rather than through mathematical assertions or preconceptions[3].

• The power test-driven development offers is the ability to take small steps when required. It allows a programmer to focus on the task at hand as the first goal is to make the test pass. Exceptional cases and error handling are not considered initially. Tests to create these extraneous circumstances are implemented separately. Another advantage is that test-driven development, when used properly, ensures that all written code is covered by a test. This can give the programming team, and subsequent users, a greater level of trust in the code[3].

• While it is true that more code is required with TDD than without TDD because of the unit test code, total code implementation time is typically shorter.[9] Large numbers of tests help to limit the number of defects in the code. The early and frequent nature of the tests helps to catch defects early in the development cycle, preventing them from becoming endemic and expensive problems. Eliminating defects early in the process usually avoids lengthy and tedious debugging later in the project[3].

• TDD can lead to more modularized, flexible, and extensible code. This effect often comes about because the methodology requires that the developers think of the software in terms of small units that can be written and tested independently and integrated together later. This leads to smaller, more focused classes, looser coupling, and cleaner interfaces. The use of the Mock Object design pattern also contributes to the overall modularization of the code because this pattern requires that the code be written so that modules can be switched easily between mock versions for unit testing or "real" version for deployment[3].

• Because no more code is written than necessary to pass a failing test case, automated tests tend to cover every code path. For example, in order for a TDD developer to add an else branch off an existing if statement, the developer would first have to write a failing test case that motivates the branch. As a result, the automated tests resulting from TDD tend to be very thorough: they will detect any unexpected changes in the code's behaviour. This detects problems that can arise where fixing something later in the development cycle unexpectedly alters other functionality[3].

Weaknesses

• Test-driven development is difficult to use in situations where full functional tests are required to determine success or failure. Examples of these are user interfaces, programs that work with databases, and some that depend on specific network configurations[3].

• Because writing test spends time, management may feel that it is waste of time unless the entire organization believing that test-driven development is going to improve the product[3].

• The tests themselves become part of the maintenance overhead of a project. Badly written tests, for example ones that include hard-coded error strings or which are themselves prone to failure, are expensive to maintain. There is a risk that tests that regularly generate false failures will be ignored, so that when a real failure occurs it may not be detected[3].

• The level of coverage and testing detail achieved during repeated TDD cycles cannot easily be re-created at a later date. Therefore these original tests become increasingly precious as time goes by. If a poor architecture, a poor design or a poor testing strategy leads to a late change that makes dozens of existing tests fail, it is important that they are individually fixed. Merely deleting, disabling or rashly altering them can lead to un-detectable holes in the test coverage[3].

• Unexpected gaps in test coverage may exist or occur for a number of reasons. Perhaps one or more developers in a team was not so committed to the TDD strategy and did not write tests properly, perhaps some sets of tests have been invalidated, deleted or disabled accidentally or on purpose during later work. If this happens, the confidence that a large set of TDD tests lend to further fixes and refactorings will actually be misplaced. Alterations may be made that result in no test failures when in fact bugs are being introduced and remaining undetected[3].

• Unit tests created in a test-driven development environment are typically created by the developer who will also write the code that is being tested. The tests may therefore share the same blind spots with the code: If, for example, a developer does not realize that certain input parameters must be checked, most likely neither the test nor the code will verify these input parameters. If the developer misinterprets the requirements specification for the module being developed, both the tests and the code will be wrong[3].

Domain Driven Design

Overview

Domain-driven design (DDD) is an approach to the design of software, flows from the premise that the heard of software development is knowledge of the subject matter and finding useful ways of understanding that subject matter. The complexity that should be tackled is the complexity of the domain itself -- not the technical architecture, not the user interface, not even specific features. This means designing everything around our understanding and conception of the most essential concepts of the business and justifying any other development by how it supports that core[4].

Strengths

• At DDD core it concentrates on building a simulation of the problem domain, minimizing technical influences, and attempting also to minimize misunderstandings between users of the software and the developers by establishing and using Ubiquitous Language (a common vocabulary)[5].

• A common model that is used between the business stakeholders, IT managers, Enterprise Architect, and software engineers, which is used to communicate the functional requirements, data model, and business processes[6].

• The model is extensible, easy to maintain, and adaptable as the iterative process of development progresses[6].

• It helps plan for reusability[6].

• The model makes testing of the business logic easy and continuous[6].

Behavior Driven Development

Overview

Behavior-driven development (BDD) is an Agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project[7].

Behavior Driven Development (BDD) is a process that evolved from Test Driven Development (TDD). The differences are subtle and primarily focus on removing communication related confusion[8]. The BDD cycle parallels the TDD cycle, except that the word test is replaced with the word spec. Although this change appears to be purely at the surface level, it actually represents a powerful shift in the thought process. BDD shifts the focus from implementation details to the behaviors that your system exhibits[9].

Strengths

• The focus of BDD is the language and interactions used in the process of software development. Behavior-driven developers use their native language in combination with the ubiquitous language of Domain Driven Design to describe the purpose and benefit of their code. 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[7].

• In TDD conventions, test classes and methods are named after the production classes and methods that they test. For example, if you are test-driving a frequent flyer application that has a class named RewardsCalculator with a method named calculate(), you would typically write a RewardsCalculatorTest class with a testCalculate() method. But this creates a situation in which your test code is tightly coupled to the structure of your production code. What happens if you move some of the functionality from the calculate() method to another method or class? You would likely need to modify the structure of your test code to reflect the change. BDD attempts to re-orient the focus of TDD away from the specific structure of implementation code and towards system behaviors. One advantage of this approach is that behaviors change less often than implementation details, and typically such changes are precipitated by intentional enhancements to the functionality of the system, not as a result of simple refactoring activities[9].

• BDD remove the central focus on "tests" to help accomplish the goal of a ubiquitous language. Generally, when the word "Test" is mentioned to a business minded person, they will immediately think about a quality assurance process that is situated near the end of a project plan. By changing the termonology from "Test" to "Specification", the focus changes to something done near the beginning of the project plan that defines and drives the development of the solution. This small focal shift can make a big difference in how the project is driven[8].

• System behaviors can be also described with varying levels of granularity. For example, you can talk about behaviors that the system as a whole should exhibit, or behaviors that characterize individual components of the system. Systemwide behaviors are often captured as user stories or use cases. Finer-grained behaviors are usually less formally described and often are only captured in test cases. BDD can be a useful way to communicate and verify behaviors of both forms. In fact, BDD blurs the distinction between unit, integration, and system tests[9].

• BDD also has advantages for developers. When specifications are documented in code, that code is more likely to accomplish the business goals, be easier to understand, and be much more maintainable over the life of the solution. In addition, the specifications written to drive the development can then be used to prove that the final product meets all of the business requirements[8].

Model Driven

Overview

Model-driven development (MDD) is a software-engineering approach consisting of the application of models and model technologies to raise the level of abstraction at which developers create and evolve software with the goal of both simplifying (making easier) and formalizing (standardizing, so that automation is possible) the various activities and tasks that comprise the software life cycle. MDD imposes structure and common vocabularies so that artifacts are useful for their main purpose in their particular stage in the life cycle (such as describing an architecture), for the underlying need to link with related artifacts (earlier or later in the life cycle), and to serve as a communication medium between participants in the project (over space or time)[10].

Strengths

• Raise the level of abstraction at which developers operate and, in doing so, reduce both the amount of developer effort and the complexity of the software artifacts that the developers use[10].

• Improve software quality[10].

• Improve reuse by enabling developers to work at reasonably higher levels of abstraction and to ignore "unnecessary" details[10].

Weaknesses

• It brings redundancy. A central tenet of MDD is that there are multiple representations of artifacts inherent in a software development process, representing different views or levels of abstraction on the same concepts. To the extent that these are manually created, duplicate work and consistency management are required[10].

• Rampant round-trip problems: The more models and levels of abstraction that are associated with any given software system, the more relationships will exist among those models. Many of these interrelationships are complex. The round-trip problem occurs whenever an interrelated artifact changes in ways that affect some or all of its related artifacts. For example, if a developer adds a method, m, to a class, in a UML(unified modeling language) diagram, the Java code that realizes C must be modified to include an implementation of m (or at least it must be flagged that an implementation of m is needed). In some cases, the change may be propagated automatically - for example, if C were an interface instead of a class, it might be possible to automatically generate a method m in C. The far worse (and more common) case, however,is when the round-trip problem cannot be addressed automatically. For example, if the change occurs in a method body, human intervention is required to determine the impact of the change on the related use case or business process model. In this case, the structure of the code or model is unchanged, but the semantics underlying the code or model have been adjusted. Is it a change in the desired function? Is it a bug fix? Is it part of a more extensive refactoring of the entire package? Each will have different implications on related artifacts[10].

Reference

[1]http://www.wirfs-brock.com/Design.html
[2]http://www.slideshare.net/harshjegadeesan/lecture-responsibility-driven-design-presentation
[3]http://en.wikipedia.org/wiki/Test_driven_development
[4]http://www.cs.colorado.edu/~kena/classes/6448/s05/lectures/lecture23.pdf
[5]http://behaviour-driven.org/DomainDrivenDesign
[6]http://www.software-solution-architect.com/software_solution_architect_software_architecture.php
[7]http://en.wikipedia.org/wiki/Behavior_Driven_Development
[8]http://bloggemdano.blogspot.com/2008/12/behavior-driven-development-bdd-in-f.html
[9]http://www.javaworld.com/javaworld/jw-09-2008/jw-09-easyb.html
[10]"Model-driven development: The good, the bad, and the ugly" by B.Hailpern and P.Tarr