The Java Development Process

This section outlines the development process from start (setting up your environment) to finish (delivering your software).

Introduction to Incremental Development

Incremental development is the practice of developing software in small, discrete stages comprised of program analysis and design, coding and code refactoring, testing, and incremental integrated deliveries.

For the purposes of this chapter, design refers to program design and not the larger arena of system design, which involves evaluating use-cases , UML diagrams, and so on, although the two are obviously dependent upon one another.

Note

Chapter 3, "A Developer's Guide to the Unified Modeling Language (UML)," and Chapter 6, "Transitioning from Software Design to J2EE Technology Components and Services," explain in detail the design phase of a Java or J2EE project.

The process, referred to as the design-coding-testing-delivery cycle, is repeated many times during the development stage, as illustrated in Figure 4.6.

Figure 4.6. Design-coding-testing-delivery cycle.

Note

Incremental development is closely related to eXtreme Programming (XP), which is explained in more detail in Chapter 2.

Preparing for Java Development

Before a single line of application code is written, an operational and easy-to-use environment should be set up. The last thing you want developers to do is to troubleshoot environmental issues when they have timelines to meet.

This section presents a list of tasks that should be completed before application development begins:

1. Write a procedure to set up the standardized development environment. The procedure creates directories and sets environment variables .

2. For J2EE development, provide instructions on how to configure the application server, how to deploy the application to the application server, how to administer the application server, and so on. Industrial strength J2EE application servers such as WebLogic Server have a comprehensive set of examples shipped with the product and excellent online up-to-date product documentations (http://edocs.bea.com).

3. For products, such as IDEs , design tools, and so on, provide instructions on how they should be configured for the project.

4. Provide concise instructions and supporting documentation for building software.

5. Provide concise instructions and supporting documentation for using source code control.

6. Provide access to a Web page containing links to online product documentation, internal documentation, and other useful information.

7. Collect and build the initial set of common Java components, which is explained in the next section, "Creating the Common Components."

8. Write a sample program that demonstrates how developers should write code. Include all source, configuration, and build files as well as instructions for running the different types of applications (JSP, EJB, Servlets, and so on) used in your project.

9. Create a source code control area where developers can test the commands of the code control system.

Creating the Common Components

Every Java programming project uses shared classes. Some of these Java classes are business-specific and others are more general. General-purpose classes include error message generation, logging, authentication, exception handling, string handling, and so on. Business-specific classes vary depending on the business.

Ideally, all common components should be in place before application development begins. However, some components are discovered along the way when a developer realizes the same code is needed in various places. Other components are planned, but writing the code requires a lot of work and you don't want to delay the project.

Before starting application development, at a minimum, skeletal classes should provide features, such as error message handling and exception handling, that are used early in the development cycle.

What the Developer Should Do First

Don't worry about designing or coding yet. The developer needs to set up his environment, verify it works, and learn to use it.

After the system administrator has set up your account, log in and run the environment setup procedure. Familiarize yourself with the project directory structure. Examine the environment variables. In particular, look at the CLASSPATH and PATH variables to see which programs you are using and which Java classes are being used. Check the version of your JDK and make sure it is what you expect. Perform any other environmental checks you deem useful at this time.

Next, make sure your tools are installed and they are working at a minimal level. If you find problems, contact the tech support group . Because you are using a common environment, others will eventually encounter the same problems.

After the tools are working, set up any Web links to useful online documentation, such as J2EE, J2SE, and BEA WebLogic documentation or the projectwide documentation page. The Java Developer Connection provides the latest information about Java technology at its Web site, http://java.sun.com/jdc, as well as distribution of highlighted topics through e-mail. Specifically for the WebLogic developer, BEA offers an online developer program at http://developer.bea.com. For all documentation that addresses your project, if you need hardcopy documentation, gather it or have it ordered.

Tip

Join Sun Developer Connection at http://developer.java.sun.com/developer/?frontpage-main.

Join BEA Developer Program at http://developer.bea.com

Read the short version of the build and source code control system documentation. Use the source code control system by setting up a local copy of the project sample application. Try checking software out and in, getting listings, and so on.

If you are learning a product, read the documentation, and, if possible, talk to colleagues and identify the aspects of the product that are relevant to your project. Read for feature functionality and not necessarily deep understanding. Go through the product tutorial. Read and test the product examples. It is strongly recommended to attend BEA product training courses either onsite or offsite.

When you understand the environment and the products well enough, it is time to examine the project's sample application. Look over the source code, look at build files, look at the configuration files, and so on. Build and run the sample application and verify that it works.

Finally, create a HelloWorld application using the technologies relevant to your assignment. Keep this demo application in your prototypes directory for future reference.

Overall, you need to spend a few days (or more depending on the scope of the project) to look over the documentation and other resources so you understand the products and can effectively develop software.

Application Development

After you understand how to use the products and the development environment, it is time to get started with application development. At this point, you should have a complete understanding of your project's objectives and have worked out a preliminary software design.

Getting Started

From the preliminary design, you should be able to code your top-level classes. This will require stubbing out most of the functionality. Include the hooks for common services (security, logging, and so on), if you have this information. After creating the skeletal application, you should be ready to run the first version of your program. Remember, the emphasis in incremental development is design, code, test, and do it over again!

The Design-Coding-Testing-Delivery Cycle

The design-coding-testing-delivery cycle refers to the process of developing programs in many short stages where a design is made, the code is written and tested , and the result is integrated with other parts of the system.

Program Design

The goal of program design is to translate the user 's requirements into a form that can be implemented in a programming language.

Philosophy

Because requirements are consistently evolving it is best to design for generality and flexibility, but code to the current specific needs. Don't over-design. Look for simplicity and coherence. Remember, a simple design results in a smaller amount of code and it is easier to understand, maintain, and debug. Recognition of common components ( coherence ) decreases the amount of source code and amplifies testing of that code.

When working on a design keep at it until you are satisfied it is as clean as possible. Don't fall into the habit of using the first design that comes to mind as your final solution.

Use programs as working documents, a place to keep notes, and reminders about implementation ideas. Use pseudocode, in the form of comments, as placeholders for future code. Replace the pseudocode with real code as you develop the software.

Design Versus Coding

One dilemma every programmer faces is when to design and when to code. A lot of ugly code has been created when programs are coded and designed at the same time. Programming too soon after a very critical design decision can also result in regrettable code.

Coding and design require fundamentally different thought processes. Designing usually requires considering issues that affect your program as a whole. Designing involves process flows, identification of common functionality, and other generalizations . Coding, on the other hand, concentrates on low-level logic issues, programming constructs, APIs, and so on. In short, design is global and coding is local.

It is important to remember the following points:

• Keep design and coding separate.

• Let design ideas settle before implementing the code.

• Design a simple, expressive model that clearly communicates how the product will be realized.

Coding

The real work is done by the code, so write it well. Code in stages, starting with basic functionality, followed by refactoring, followed by adding more functionality.

Write the Code Correctly the First Time

Write the code correctly in the first release. Don't think about retrofits. You don't get a chance to fix your mistakes. Poorly written working code is more valuable to a business than untested well-written code.

We don't expect your code to be sparkling at all times during development, but when it is turned in for the final release you should have everything cleaned up.

Use Examples

The message is simple: "Don't re-invent the wheel." Don't be ashamed of borrowing someone else's code; just make sure you understand it. You can find working code everywhere, in the product demos, on the Internet, and in books. Many books contain complete solutions to the problems you are trying to solve. If you can find a helpful book, buy it. The $30 “50 cost of the book will quickly pay for itself even if the book saves you just a few hours of work. Most companies will reimburse you for the book.

Refactoring

Code refactoring is the process of systematically re-evaluating existing software and then making changes to improve it without causing observational changes.

Note

For further information on refactoring, please refer to http://www.objectcentral.com/oobook/oobook.htm.

Refactoring usually refers to going back to completed code, identifying improvements or generalizations, and making code changes to reflect them. However, refactoring applies equally well to new program development.

We have identified five types of refactoring that are to be done during new program development:

• Documentation refactoring: Review your Javadoc and program comments. Make corrections to your programs so they conform to project standards. This stage is essentially mechanical, but it is a good time to look for logic problems and any non-conforming constructs. Document, but do not fix these problems during this stage.

• Coding guidelines refactoring: Review and update your code to reflect programming and optimization guidelines. This stage is also mechanical.

• Generalization refactoring: While reviewing or working on your code you will discover programming patterns or classes that are used in more than one place. These elements are likely candidates for collapsing into a common class or method.

• Decomposition refactoring: Decomposition problems are usually discovered during coding. They are usually in the form of long, complex methods or classes that can be broken into a collection of small methods or classes. Decomposing large classes is a great way to isolate and simplify a program. Decomposing methods is nothing more than breaking a method into smaller methods so it can be more easily understood .

• Normal form refactoring: During this stage, the code layout is rearranged to the normal form described by the Java programming style standards. No programming logic changes are made during this stage, but the locations of code do change. Remember to save a backup a copy of the original sources and recompile after each source file is changed because it is very difficult to identify mistakes.

Some refactoring is essentially a boilerplate process, whereas others require creative thinking. All Java source files in your application should pass through the five stages of refactoring. The following are our guidelines on applying the refactoring process:

• Generally, refactor piece by piece. Some refactoring, especially the more mechanical phases, are big jobs; you can get bored and end up doing a sloppy job if you try to complete it all at once.

• Do mechanical refactoring tasks when you need a break or have to mull over a design.

• Refactor only after you have gotten it to work; otherwise , you will not know if you made errors.

Coding Practice

When writing code, don't always worry about complying with the rules of normal form and documentation. You should try to follow the programming guidelines, but any mistakes should be caught later. Always be on the lookout for generalizations and decompositions.

The time spent coding should be as free of distractions as possible. Limit the number of meetings and breaks. You should concentrate on one thing: writing the code.

Try to be complete when coding at each stage. If you must put off some complex or tedious code, mark it so it can be corrected later. Use code refactoring as a means to break away from difficult coding or to delay implementing a design decision until you have had more time to think about it.

Before the software is complete, it must pass through each refactoring stage. Finally, make sure the code is complete before commencing with final testing.

Testing

Although testing is still pretty much an art, some systematic practices can be followed:

• Test standalone components outside the application. By doing this, you can create a test harness to validate all the important test cases.

• Keep programming increments small and test frequently. The design-coding-testing cycle encourages this, but you can also perform a lot of unit testing by testing the small changes that are made during the coding stage.

• Complete the testing of key components before moving on to use-case level testing. Perform unit testing from the inside out.

• Build your code with good debugging support, logging, exception handling, and error messages. This is very important if you are developing servlets or EJBs.

• In preparation for the final integration testing, identify a set of test cases for your application. A test case is a set of input values your application is given along with the expected outcomes . Evaluating use-cases and studying the program logic can help identify valid test cases.

Delivery

The major objective of the design-code-test-deliver cycle is to produce an application system working according to specifications.

Because you are using an incremental approach for development, there are a number of intermediate delivery objections. Although the intermediate objectives are highly dependent on the application, one objective is true across all projects, be sure the progress achieved by the intermediate deliverables can be demonstrated to your end-users and/or managers.

Reference

http://alumni.caltech.edu/~croft/research/java/guide/

http://www.geosoft.no/javastyle.html