Chapter 7: Synchronizing the Model and CodeOne Small Release at a Time

Overview

If release 1 marked the end of the project, then that would be fine: our work here would be done. If the product works, it meets the requirements, and there’s no more development to be done, then there’s simply no need to spend time tidying up the design.^[1.] For the mapplet project, however, we’re really just getting started. So to prepare for the next release, we need to transform the prototype alpha design into a production-quality design that’s more maintainable, reusable, and extensible.

In this chapter, we analyze the robustness and sequence diagrams that the team produced (i.e., the design the team coded from) and show how that design could have been improved. This should prove useful, as the diagrams reveal some common issues that it pays to be aware of. These issues typically appear early in a project when the team is still working to create an understanding of the product that it’s going to build.

In the early stages of a project, you’d normally expect design errors to be made and for the source code to not be precisely aligned with the diagrams. As subsequent releases are embarked upon, however, you should expect to see the diagrams and the source code converge more and more. Having the design model and the code in sync allows the project to be much more agile, as it’s easier to design for the next release, building on the design work that was done for the previous release.

^[1.]In such cases, however, it does pay to spend a little time “mothballing” the project—that is, updating the documentation so that if the project does happen to be revisited sometime in the future, the documentation actually matches the code. Think about the maintenance team that will have to work with your legacy. Be nice to them!