Component-based development (CBD) and object-oriented development go hand-in-hand, and it is generally recognized that object technology is the preferred foundation from which to build components. The Unified Modeling Language (UML) includes a component diagram that shows the dependencies among software components, including the classifiers that specify them (for example implementation classes) and the artifacts that implement them; such as source code files, binary code files, executable files, scripts and tables.Component diagrams, along with UML Activity diagrams, are arguably one of the “forgotten” UML diagrams. Few books invest much time discussing them, I suspect the primary reason for this is because most methodologists appear to relegate them to low-level design diagrams for specifying the configuration of your software. UML Deployment diagrams are preferred by most modelers for this task, not only can you define what you intend to deploy you can also indicate where you intend to deploy it with deployment diagrams, and most programmers prefer to use their configuration management system to define configurations. UML Component diagrams become much more useful when used as architectural-level artifacts, perhaps used to model the logical architecture of your technical or business/domain infrastructures.There are guidelines for:
As you can see in Figure 1 UML 2.X components are modeled as rectangles with either a visual stereotype in the top left corner or the textual stereotype of <>. Components realize one or more interfaces, modeled using the lollipop notation in Figure 1, and may have dependencies on other components – as you can see the Persistence component has a dependency on the Corporate DB component.
Figure 1. A UML Component 2.x diagram representing the logical architecture of a simple e-commerce system.
Use Descriptive Names for Architectural Components
Use Environment-Specific Naming Conventions for Detailed Design Components
Apply Textual Stereotypes to Components Consistently
Avoid Modeling Data and User Interface Components
2. Interfaces
Prefer Lollipop Notation To Indicate Realization of Interfaces By Components
Prefer the Left-Hand Side of A Component for Interface Lollipops
Show Only Relevant Interfaces
3. Dependencies and Inheritance
Components will have dependencies either on other components or better yet on the interfaces of other components. As you can see in Figure 1 and Figure 2 dependencies are modeled using a dashed line with an open arrowhead.
