1.5 The Framework Process Patterns
As discussed in the Preface, we've chosen to use a patterns-based approach in this book. We've further organized these patterns into seven distinct categories, each addressing a separate aspect of frameworks. Chapter 3 (the first chapter that presents the patterns) addresses patterns that are common across the entire development process. This includes architectural patterns as well. Chapters 4 through 7 describe patterns specific to individual artifacts from the development process: requirements, analysis, design, and documentation. Chapter 8 looks at the social aspects of creating a strong and focused development team. Finally, Chapter 9 explores how customers use the framework. Together these patterns cover all the factors (product, process, development team, and customer) that go into the development and use of a successful framework.
An alternative way of looking at these patterns is by the area (or discipline) that they address. In Table 1.1 (which is also printed on the inside back cover) we've categorized the patterns in each part by these areas:
CommunicationInformation must be properly communicated.
ConsistencyThe same things should be done the same way.
IterationSoftware development involves iteration, and frameworks are no exception. In fact, for frameworks there is unique iteration related to refining them to their target applications in their target domain.
IncompletenessSometimes you should leave a framework incomplete so that framework users have the ability to complete (extend) it to their particular needs.
FlexibilityYou need to determine how much extensibility a framework should support and where it should support it.
DuhSome things are obvious but still can cause problems if you aren't careful.
These patterns will be demonstrated through the use of a case study, presented in Chapter 2.