Business Modeling may be undertaken for a number of reasons. For example, we may wish to undertake Business Modeling in order to gain an understanding of current problems in the organization and identify areas of potential improvement. This improvement may be provided through the implementation of applications that automate aspects of the business. Such automation may address problems such as poor performance or excessive human error.

Business Modeling may also be undertaken to ensure that customers, end users, and developers have a common understanding of the structure of the target organization. This understanding may be communicated as precise definitions of roles, responsibilities and interactions between elements of the organization.

Business Modeling can also be undertaken when deriving requirements for applications that are built to support the organization. For example, a particular application may be required to interoperate with other applications that automate other aspects of the business, and may be required to be accessed by certain roles within the organization, which might result in a requirement to access the application through certain devices, such as a WAP phone for mobile users.

Business Modeling can be very important because it puts the system to be developed in the business context. Business Modeling provides an input to the Requirements activities, as well as to the Analysis and Design Activities, since business entities can be used as an input to identifying entity classes.

The scope of testing discussed in Chapter 9, Implementation is confined to unit testing. However, RUP contains an extensive Test discipline that supports testing concerns beyond those of the individual developer.

In particular, RUP acknowledges the need to integrate the work of a number of developers and discusses integration testing, system testing and acceptance testing. Integration is a software development activity in which separate software components are combined into an executable whole. Integration testing is concerned with testing this whole. System testing is traditionally performed when the software is functioning as a whole, and the target of testing is the end-to-end functioning of the system. The goal of acceptance testing is to verify that the software can be used by the end-users to execute the functionality of the system.

From the perspective of the J2EE Developer Roadmap, the Requirements artifacts (such as the Use-Case Model and Supplementary Specification) and Implementation artifacts (such as Implementation Directories, Implementation Files and Test Scripts) are a significant input to the activities of the Test discipline.

The Deployment discipline of RUP is focused on ensuring that the software product is available for its end users, and it defines a number of artifacts as a result (such as Release Notes, Installation Artifacts and Training Materials). From a J2EE perspective, the Deployment discipline emphasizes that solely producing the software product is not sufficient to transition a product to its end users, and that other concerns, such as installation and training, must be considered.

A key artifact of the Deployment discipline is a Deployment Unit. A Deployment Unit consists of a Build (a collection of executable elements, such as a J2EE application or J2EE modules), documents (End-User Support Material and Release Notes) and Installation Artifacts.

Most of the artifacts that the developer produces are subject to configuration and change management. RUP describes a comprehensive Configuration and Change Management discipline that addresses:

Certain artifacts, such as documents and source code files, can be configured and change managed in their entirety. This is not the case with other artifacts such as the Design Model. Multiple developers must work concurrently on different parts of the model, and these parts must be individually configured and change managed. Concurrent access to the same model requires that the model be structured to support this way of working (see the Structure the Implementation Model activity in Chapter 9).

The Project Management discipline of RUP provides a framework for managing software-intensive projects. It provides practical guidelines for planning, staffing, executing, and monitoring projects, as well as providing a framework for managing risk.

It is interesting to note that a number of artifacts produced by the J2EE developer influence the planning aspects of Project Management. For example, the Use-Case Priority List, Use Cases, Design Subsystems, Design Packages, and Framework Components are all inputs to the planning of the development of a J2EE application.

As has been mentioned several times throughout this book, RUP is iterative in nature. This aspect is of particular significance to the Project Manager who must plan the iterations of the project. Planning is essentially performed at two levels. The first is at the level of phases. This planning is captured in a phase plan^[2], which provides a holistic perspective of the project's phases and iterations. For example, the phase plan provides an indication of the anticipated number and duration of iterations of the project. An extract from an example phase plan is shown in Table 10.1.

The second level of planning occurs at the level of iterations. This planning is captured in an Iteration Plan, which provides a detailed fine-grained view of the tasks, resources, resource dependencies, and durations for the iteration. As the project progresses, there are always two Iteration Plans being considered. The first Iteration Plan is associated with the current iteration. The second Iteration Plan is associated with the next iteration. One aspect of an Iteration Plan is often a Gantt chart, which shows the timeline of the iteration. An example of an Elaboration Iteration Plan is shown in Figure 10.1.

Figure 10.1. An Elaboration Phase Iteration Plan

The Environment discipline of RUP defines activities that are focused on providing a process and toolset for use on a project. This may involve configuring RUP in some way, as well as integrating a set of tools. For example, in defining the J2EE Developer Roadmap, we followed the activities described in the Environment discipline of RUP. In RUP terms, the J2EE Developer Roadmap constitutes one aspect of a Development Case artifact.

The Environment discipline also contains activities and artifacts explicitly aimed at defining the guidelines to be used on the project. For example, the activities of the Environment discipline produce the following guidelines, which we reference in the J2EE Developer Roadmap.

There are also a number of considerations that apply across disciplines that should be mentioned. One of the most significant of these is the development of a traceability strategy. Traceability is the ability to trace a project element to other related project elements. For example, we could explicitly model the traceability from an EJB to the key abstraction(s) that it was derived from. Traceabilities may be set up to:

Implementing a traceability strategy requires careful thought, since there is a cost involved in creating and maintaining any traceability. However, given appropriate conventions and tool automation, much of this cost can be reduced. For more information on developing a traceability strategy, see RUP.

While writing this book, we kept a number of objectives in mind. The most obvious of these was to present a useful subset of the RUP, the J2EE Developer Roadmap, which effectively addresses the complexities of developing J2EE applications, and can be immediately applied. In addition, we deliberately placed an emphasis on exemplifying this process through the development of an Online Auction application, from requirements through to implementation.

When we first considered bringing our experiences together on paper, we were concerned about the longevity of such a publication. We were concerned with the continuing evolution of the J2EE platform. We were asking ourselves and our colleagues: will our book still be relevant in 12 months' time? Will initiatives such as Web services dramatically affect the J2EE Developer Roadmap that we advocate?

Of course, we would not have written the book if we had concluded that the material would age rapidly. This book is about how to build a specific kind of application (an enterprise application), with specific technologies (J2EE), and is not about the technologies themselves. We strongly believe that even though the J2EE technologies will improve and include more services, our process roadmap for building J2EE applications will stay fundamentally the same. Of course, we may have to add, or possibly remove steps and change their details, but nothing will remove the need to do good requirements, analysis, design, and implementation, or reduce the benefits of developing iteratively.

The framework on which the roadmap has been built, the Rational Unified Process itself, demonstrates the longevity of a good process. RUP has been constructed with longevity in mind and has been successfully applied to many software development projects—projects that differ dramatically in terms of size^[3], complexity and domain. While the technologies that underpin the J2EE platform may evolve, we are confident that the roadmap we have presented in this book for “Building J2EE Applications with the Rational Unified Process” will prove useful to you for some time to come.

In closing, we strongly encourage you to make your own improvements to the roadmap. Although we like to think of the J2EE Developer Roadmap as a cookbook for J2EE developers, even the best recipe can be improved by a good cook.