In the example presented in Figure 4, you'd probably want to develop a set of detailed models for the component Customer Management because it's a reasonably well-defined subset. At the same time, you would draw a more detailed component diagram for Network Management because it's a large and complex domain that must be broken down further. This approach to component diagrams is contrary to what the UML document currently suggests. The current use for component diagrams proposed by the UML document is that it is an implementation diagram that shows the granular components, perhaps ActiveX components or Java Beans, used during implementation. Although these kinds of components are important, this is a low-level approach to reuse.
Bigger payback is achieved from taking an architectural approach to development.
The manner in which I suggest using component diagrams supports this approach. Besides, you still have deployment diagrams to document your implementation decisions. Deployment Diagrams Figure 5. Notice the similarity of the notation for both deployment and component diagrams. Deployment diagrams are reasonably simple models that are used to show how the hardware and software units will be configured and deployed for an application.