Component Boundary Analysis

5/10/2007

An important step in the componentization process is determining the boundaries of the components. It is rarely practical to create one component for an entire piece of software, or one component for each file that makes up the software. The following list provides guidelines for determining the contents of each component:

• Evaluate architecture.
  Architectural evaluation is the logical division of the software into obvious functional elements, such as dividing Microsoft Office into Word, Excel, and PowerPoint components. It is a good starting point because it follows the functional boundaries of the software. It also serves to clarify the limitations of componentization because no software can be componentized beyond what its existing architecture permits. For example, Notepad cannot be split into an editing component and a searching component. Both of these functions are implemented by Notepad.exe and they are not configurable by some external means such as a registry key.
• Evaluate usage scenarios.
  Evaluation of usage scenarios involves examining which portions of functionality are commonly used and would likely require separation into components. For example, while an architectural evaluation of Word might suggest components for editing, reviewing, drawing, and formatting, a usage scenario evaluation may reveal that reviewing should be further divided into components for change-tracking functionality and commenting functionality.
• Identify common dependencies.
  Look for a single file or set of files that must be present in all configurations due to interdependencies. For example, if all features use a dynamic-link library (.dll) file that provides utility services, then that .dll file should be in its own component and all other components should have a dependency on it.
• Identify inseparable groupings.
  Look for files that must always be used together or not at all, and include them in the same component. For example, if a feature is always shipped with its Help file, then the executable file and the Help file should both belong to the same component.
• Do not under-componentize.
  Do not create huge components that incorporate too much functionality that could be divided into separate components. If you need the ability to include all of the functionality in some configurations, use dependency groups or macro components.
• Do not over-componentize.
  Do not create a separate component for every file and every registry key. That leads to numerous interdependencies and components that are useless on their own. For example, if a .dll file always uses B.dll, and B.dll has no other purpose, then those files should belong to the same component.

See Also

Concepts

How to Componentize an Application
Macro Components

Other Resources

Application and Device Driver Components
Dependencies
Groups