Implementation

The use cases have been completed, the problem has been analyzed, a candidate architecture has been drafted, and a suitable design has been defined. It is time to roll up the virtual sleeves and start implementing (Figure 13-1).

Figure 13-1. Activities during implementation

The activities of implementation include

• Mapping the design into code and components
• Building the code into binaries
• Unit testing
• Updating the model

At the same time, the UX team will be implementing the look-and-feel of the application in HTML.

The principal responsibility and activity of the implementer is to map the artifacts of design into executable code. The implementer, of course, uses more than the artifacts modified by design. A thorough knowledge of the use cases is required to ensure that their meanings and goals are not lost.

Every implementer is responsible for unit testing his or her own work. Some organizations may use pairs of implementers, and unit testing might be done by a partner. Either way, the goal is to have every delivered artifact, or component, unit tested before it is used by any other member of the team.

The final step in this cycle is to update the model when changes are made to the structure of the design as a result of the implementation. This is an iterative process, after all, and change is to be expected and planned for. An accurate model is important because the model is a view of not only the system to be built but also the system being built and the system that was built. Once the system and the model get out of sync, the model's ability to answer questions about the system is limited. Model updating can be as simple as a code review by the developer or designer and a manual updating of the model. More sophisticated CASE tools have reverse-engineering capabilities built in and make this task much easier.

Most nontrivial Web applications have a development staff of more than one, so an important part of the development environment is to publish package interfaces as early as possible. This allows implementers to work asynchronously even when their own code is dependent on others. Each developer will stub out a public interface. In the case of Web page development, a suitable interface prototype can be created by implementing the pages, in their correct directory, with hyperlinks to the other Web pages that comprise the system's scenarios. These scenarios are, of course, owned by the UX team and are often a valuable reference and resource to the rest of the team.

For the most part, the implementation of all the server-side componentsbusiness objects, persistence layer, transaction componentsis done in the same way as in any client/server system. Here, we'll concentrate on the construction of Web-specific components, most notably the Web pages of the system. Reiterating one of the main themes of this book: Web pages are architecturally significant components that exist in the model and in the executable system. Web page model elements map directly to Web page code. This chapter describes that mapping.

Web pages in a Web application can be implemented with scripted Web page filesASPX, JSP, PHPor with compiled componentsCGI, Java servlets. In either case, the logical separation of client-side and server-side activity is the same. Implementing the client pages in the model is essentially the same, regardless of which server-enabling technology is used.

This chapter does not cover all the specifics of mapping the models to code. These details can be found in Appendix A, a detailed description of the WAE profile and its mapping to HTML and JSP code. Another excellent way to understand the mapping between models and code is to examine the two reference applications: Number Store and Glossary. This chapter covers a few examples from the reference applications and provides some explanatory text.

Microsoft's .NET framework with the next-generation Active Server Page server has been released. The details and their mappings to UML are not yet fully understood and therefore are not covered in much detail here.