- 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:
Start your solution-side package design by developing a model that has a consistent set of operations and descriptive interface.
Then:
- Create a project in your Visual Studio (or Eclipse, ...) solution, seperate from the application project. Temporarily set it as the startup project. Set the properties of this project to define the test stub string so your tests will be compiled.
- Decide on a representation for any data the package has to manage in terms of structures of existing types. You will find the Standard Template Library very useful here.
- Create public methods that implement the model and use them to make transformations or provide access to the data.
- For each method make a test in the package's test stub main function, and exercise it. Don't go on until the current function works as expected.
- Use class and member names that are consistent with the package model, e.g., M_AryTree, SymbolTable, etc.
- As soon as this solution can support it's application-side parent, embed into the Project solution, make that the startup project, and test.