- Introduction
- 20.1 Programming and Iterative, Evolutionary Development
- 20.2 Mapping Designs to Code
- 20.3 Creating Class Definitions from DCDs
- 20.4 Creating Methods from Interaction Diagrams
- 20.5 Collection Classes in Code
- 20.6 Exceptions and Error Handling
- 20.7 Defining the Sale.makeLineItem Method
- 20.8 Order of Implementation
- 20.9 Test-Driven or Test-First Development
- 20.10 Summary of Mapping Designs to Code
- 20.11 Introduction to the NextGen POS Program Solution
- 20.12 Introduction to the Monopoly Program Solution
This chapter is from the book
This chapter is from the book
This chapter is from the book
20.1 Programming and Iterative, Evolutionary Development
The prior design modeling 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 and refactor alternate approaches, and some (often lots) design-while-programming is worthwhile.
The creation of code in an OO language—such as Java or C#—is not part of OOA/D—it’s an end goal. The artifacts created in the Design Model provide some of the information necessary to generate the code.
A strength of use cases plus OOA/D plus OO programming 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 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 these examples 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 modeling 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 ideas and understanding (not the diagrams or documents!) generated during OO design modeling will provide a great base that scales up with elegance and robustness to meet the new problems encountered during programming. But, expect and plan for lots of change and deviation from the design during programming. That’s a key—and pragmatic—attitude in iterative and evolutionary methods.