In This Chapter
Defining good packages
Developing subsystems from packages
Considering dependencies
Specifying required subsystem services
Realizing a subsystem
Using architectural patterns to decompose your system
Even the development wizards can get it wrong. This chapter shows you the tricks of the trade so you can avoid or at least contain the mess that can result when designing large systems. When designing these large systems, poor system decomposition—partitioning a system into smaller systems or subsystems—can exacerbate the confusion, and you can end up with a maintenance headache resulting from built in dependencies throughout the system. If this is the case, you may have a queasy feeling that the system is brittle—which means that every time you make a change to one part of the system, you end up having to make changes in lots of other places too. To help you head off such a scenario, this chapter shows you some measures you can take to avoid brittle systems. We talk about moving from analysis-time packages to design-time subsystems. You’ll see examples of subsystem notation and architectural patterns that get you started building solid systems that stand the test of time.