RAD Architecture and Design

As an example, consider the choice of which scripting language to adopt on a new project. Both Jython and Groovy are excellent choices as scripting languages. Both are each compatible with Java and offer highly expressive language constructs. Nevertheless, if the team has a large base of experience with Perl, then neither Jython nor Groovy may be the best option. Where possible, you may wish to stick to what the team knows well and work to your strengths. Without doubt, there is value in learning new technologiesjust be cautious of learning on time-critical projects.

Chapter 9 looks at Jython and Groovy .

Use Best-of-Breed Frameworks

J2EE is all about frameworks, yet extensive as the J2EE platform is, it does not cater to every scenario. Enter the application framework to plug the gaps.

A suitable software framework can significantly reduce the amount of code we need to write and improve the quality of the design. Thanks to the groundswell of support for all things Java, J2EE developers are spoiled for choice when it comes to the availability of software frameworks.

Frameworks are available for just about every conceivable application, including Web development, security, build environments, test environments, and GUI development. Table 4-1 lists a selection of the popular offerings from the Java community and highlights the diversity of the frameworks available.

Table 4-1. Open Source Frameworks

The choice of which framework to use on a project is an important decision that can be critical to the success of the project. The following guidelines should help you through the decision-making process:

Team knowledge .

Look to work with products that have proven successful on other projects, and consider frameworks with which the team already has experience.

Maturity .

How long has the framework been used in commercial software development? Is it an open source project maintained by Apache, or is it the result of someone's PhD? A mature software product has all the rough edges knocked off. Be prepared for problems if the software has yet to be used on a commercial development.

Fit for purpose .

Pick a framework that meets the specific needs of the system. Where an acceptable match cannot be found, longer term benefits maybe realized by investing in the development of your own framework for a specific business area.

Tool support .

Tool support is a significant criterion in the selection of a suitable framework, because the combination of framework and development tool can offer significant productivity gains.

Longevity .

Try to select frameworks that will remain supported for the predicted lifetime of the system. A framework that disappears from view once a system reaches production presents ongoing maintenance and support problems.

Picking the best framework for your project reduces the development timeframe and should contribute to the quality of the final application. Here are some metrics to use as a guide when assessing a framework in terms of its maturity and longevity:

• Availability of mailing lists and discussion forums

• Level of activity on these forums

• Response time for users getting questions answered and quality of the answers

• Frequency of new releases of the framework

• Community feedback in terms of perceived quality and usability

• Number of open defects

• Quality of documentation

Choosing a framework is an important decision, so be sure to do your homework before making it.

Think Ahead

By thinking ahead during the design process, you can make the lives of developers and testers alike a lot easier. The need to think ahead is especially relevant in the area of testing.

Sadly, testing is often unfairly seen as the poor relation to development. This perception is unwarranted, as testing is an integral part of the software development lifecycle. As a rough rule of thumb, testing hours on a project will likely equal that of developmentany less, and the system is probably undertested.

Any actions you can take as an architect to make testing easier will not only result in a higher quality system, but also reduce the total testing effort. Exactly how the architect can design with testing in mind is largely dependent on the application.

Testing is a key part of RAD and is covered in some detail in Chapters 14 and 15 .

Outlined below are some points for consideration when working on the system design.

Include Test Stubs and Unit Tests as Part of the Design

Considerable effort is often wasted on projects when developers produce their own ad hoc testing harnesses. These test harnesses sprout like weeds throughout the project's code base. They burst into existence as developers find themselves unable to test new components or modules due to a dependency on a piece of software that hasn't yet been written. The solution is often to quickly implement a test stub in place of the missing software. Unfortunately, this task consumes time, and on a large project, this practice can quickly get out of hand with engineers duplicating the same test stubs.

These test stubs seldom find their way into source control and are often of dubious quality because no time has been set aside to the developer for this task on the project plan. To avoid this problem, the architect must think strategically and incorporate all necessary test stubs into the design. The designer must work in conjunction with the project manager to ensure software components are built in a logical sequence to avoid the need for ad hoc test stubs. Where this is not possible, the test stub should be included as part of the object model and time set aside on the plan for the development of the stub.

With this approach, all test harnesses and stubs become part of the project's build cycle and are available to the entire team. They can also be made available to the test team for early testing of delivered components. The test team in turn can give feedback on the quality of the test stubs.

Therefore, the rule is, think about your testing needs early on, and design testing into the system. Your developers and your testers will thank you for it.

Be Wary of Weakly Typed Interfaces

Due to the surge in popularity of XML as a format for data transfer, the interfaces on distributed components the world over are taking on a very similar appearance. Thus, many methods now have the signature

void update(String document);

The parameter document in this case carries an XML document as the payload. Using XML in this way has largely taken over from the conventional approach of defining each argument as a typed parameter on the method as it provides an effective approach for ensuring loose coupling between components. The structure of the XML document can be modified without the need to change the interface, allowing for a design that is very resilient to change.

The downside to this approach is that the compiler cannot perform any type checking of the data on our behalf . Type checking, or validation of the document against a schema, must now take place at runtime. With XML, Java becomes a type-less language.

This presents the test team with something of a headache . Errors are harder to catch at runtime than at compile time, and the testing effort must now be exhaustive.

If you intend to use XML in this manner to achieve a highly decoupled system, then ensure the necessary safeguards are in place to replace the compiler's type safety. Where practical, validate against an XML schema and always log any errors caught at runtime in a manner that makes them immediately apparent.

Be Wary of Designing for Reuse

Software reuse is a key element of RAD, but reuse is a double-edged sword. Making the reuse of software components part of your strategy for rapid development is not an easy task, even with the benefits of Java as an OOP language and J2EE as a container for housing prefabricated components.

Designing code for reuse is a difficult and time-consuming task. The developer must consider all reasonable future scenarios for a component and accommodate them accordingly within the software architecture. This adds excessive complexity to the component's design and implementation. On a project with a tight timeframe, you should avoid overengineering the architecture for future reuse purposes. Rapid development project teams should design only to have the software meet the current known requirements, not possible future ones.

This fits in with the fundamental XP principle of keeping the design simplea principle aptly described by the XP expression, " You ain't gonna need it ," or YAGNI. Remember, less code means fewer defects.

Chapter 3 covers the practices of XP .

Warning

Rapid development requires designing with reuse as opposed to designing for reuse.