20.1. Programming and the Development Process
The prior design work should not be taken to imply that there is no prototyping or design while programming; modern development tools provide an excellent environment to quickly explore alternate approaches, and some (or even lots) design-while-programming is usually worthwhile.
However, some developers find that a little forethought with visual modeling before programming is helpful, especially those who are comfortable with visual thinking or diagrammatic languages.
|
Suggestion For a two-week iteration, consider spending at least a half-day near the start of the iteration doing some visual modeling design work, before moving on to programming. Use simple “tools” that support quick creative diagramming, such as a whiteboard and digital camera. If you find a UML computer-aided software engineering (CASE) tool that is equally fast, easy, and convenient, excellent. |
The creation of code in an object-oriented programming language—such as Java or C#—is not part of OOA/D; it is an end goal. The artifacts created in the UP Design Model provide some of the information necessary to generate the code.
A strength of OOA/D and OO programming—when used with the UP—is that they provide an end-to-end roadmap from requirements through to code. The various artifacts feed into later artifacts in a traceable and useful manner, ultimately culminating in a running application. This is not to suggest that the road will be smooth, or can simply be mechanically followed—there are too many variables. But having a roadmap provides a starting point for experimentation and discussion.
Creativity and Change During Implementation
Some decision-making and creative work was accomplished during design work. It will be seen during the following discussion that the generation of the code—in this example—is a relatively mechanical translation process.
However, in general, the programming work is not a trivial code generation step—quite the opposite. Realistically, the results generated during design are an incomplete first step; during programming and testing, myriad changes will be made and detailed problems will be uncovered and resolved.
Done well, the design artifacts will provide a resilient core that scales up with elegance and robustness to meet the new problems encountered during programming. Consequently, expect and plan for change and deviation from the design during programming.
Code Changes and the Iterative Process
A strength of an iterative and incremental development process is that the results of a prior iteration can feed into the beginning of the next iteration (see Figure 20.1). Thus, subsequent analysis and design results are continually being refined and enhanced from prior implementation work. For example, when the code in iteration N deviates from the design of iteration N (which it inevitably will), the final design based on the implementation can be input to the analysis and design models of iteration N+1.
Figure 20.1. Implementation in an iteration influences later design.
An early activity within an iteration is to synchronize the design diagrams; the earlier diagrams of iteration N will not match the final code of iteration N, and they need to be synchronized before being extended with new design results.
Code Changes, CASE Tools, and Reverse-Engineering
It is desirable for the diagrams generated during design to be semi-automatically updated to reflect changes in the subsequent coding work. Ideally this should be done with a CASE tool that can read source code and automatically generate, for example, package, class, and sequence diagrams. This is an aspect of reverse-engineering—the activity of generating diagrams from source (or sometimes, executable) code.