UML component diagrams show the dependencies among software components, including the classifiers that specify them, such as implementation classes, and the artifacts that implement them, such as source-code files, binary-code files, executable files, scripts, and tables. Create them to

1. ■ model the low-level design configuration of your system,

2. ■ model the technical infrastructure (Ambler 1998),

3. ■ model the business/domain architecture for your organization (Ambler 1998).

Component Guidelines

In Figure 47, components are modeled as rectangles with either the text stereotype of «component» or the visual stereotype of a bandage box, as you can see in Figure 47. Components realize one or more interfaces, modeled using the lollipop notation in Figure 47, and may have dependencies on other components or interfaces. As you can see, the Persistence component has a dependency on the Corporate DB component.

Apply Descriptive Names to Architectural Components

Architectural diagrams are often viewed by a wide range of people who may not be familiar with your project. Therefore, component names need to be understandable. For example, most of the components in Figure 47, with the exception of Corporate DB, are named using full words such as Customer and Persistence. The name Corporate DB was used over Corporate Database because that is what it is known as within the company—abbreviations are preferable only when they are in common use.

Apply Environment-Specific Naming Conventions to Detailed Design Components

When you are creating a detailed component model, perhaps to understand the physical configuration of your system, then name your components using environment-specific names.