Design Model

The design model can be fairly close to the implementation model, depending on how strictly you map the design model’s classes, packages, and subsystems to implementation classes, files, packages, and subsystems in the implementation model. The implementation model is covered in chapter 6, but briefly it is the model that shows how the system actually looks in code. During implementation, you will often address small tactical issues related to the implementation environment that shouldn’t have impact on the design model. For example, classes and subsystems can be added during implementation to handle parallel and team development.

There are no hard and fast rules on what should and should not be in the design model. The design model must define enough of the system so it can be implemented unambiguously. The level of detail will vary from project to project, system to system, and company to company. For example, for relatively simple systems like our registration system, the design may be close to a sketch, detailed only enough so that the implementer can proceed (a so-called “sketch and code” approach). Often these sketch models are considered somewhat disposable once implementation begins and starts to differ from the sketch. On the other hand, if you are modeling a complex system, the design model will be very detailed and should be maintained as the code for the system is created.