Note #6 - Bottom-up Design

• Bottom-up Design often starts when we're building an application side package. We identify some data that needs to be managed and start by defining a language for the application to manage the data, embedded in a new package. We then implement each of the words in that language as member classes and member functions that build the data structure, transform it, and access its current state.
• Most solution-side design is bottom-up. We strive to make each of the solution packages reusable or extendable, where that makes sense. That supports both this project and other projects we may implement later.
• It is very common in large projects that similar operations are applied in several places in the project structure. Building reuseable packages for those operations allows us to have only one place to fix bugs and add functionality.
• Building reusable packages can be difficult since we don't know the context of future uses. For this reason we often try to make solution side packages have a common core set of operations that can be extended in different ways for different contexts. Learning to do this well takes some experience. That's why you are here in this course.
• One sensible way to orchestrate all this is to:
  • Build a top-down framework with stubs for many of the solution side operations.
  • Once the framework is cycling, we replace each stub with solution side operations implemented bottom-up as a package.
  • If we are careful with the design, each solution side package provides part of a language used by the application side to implement all its obligations in a way that can be easily understood and maintained.

Conclusions for Bottom-up Design: