Component Diagram

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

·         model the low-level design configuration of your system,

·         model the technical infrastructure

·         model the business/domain architecture for your organization

Good candidates for components are items that perform a key functionality and will be used frequently throughout our system. Software, such as loggers, XML parsers, or online shopping carts, are components we may already be using. These happen to be examples of common third-party components, but the same principles apply to components we create our self.

In system, we might create a component that provides services or access to data. For example, in a CMS we could have a conversion management component that converts blogs to different formats, such as RSS feeds.

Since components are major players in software design, it is important that they are loosely coupled so that changes to a component do not affect the rest of the system. To promote loose coupling and encapsulation, components are access through interfaces.

Elements of Component diagram

A component is drawn as a rectangle with the <<component>> stereotype and an optional tabbed rectangle icon in the upper righthand corner.

 

We can show that a component is actually a subsystem of a very large system by replacing <<component>> with <<subsystem>>. A subsystem is a secondary or subordinate system that's part of a larger system.

Provided and Required Interfaces in Component

Components need to be loosely coupled so that they can be changed without forcing changes on other parts of the system this is where interfaces come in. Components interact with each other through provided and required interfaces to control dependencies between components and to make components swappable.

A provided interface of a component is an interface that the component realizes. Other components and classes interact with a component through its provided interfaces . A component's provided interface describes the services provided by the component.

A required interface of a component is an interface that the component needs to function. More precisely, the component needs another class or component that realizes that interface to function. But to stick with the goal of loose coupling, it accesses the class or component through the required interface. A required interface declares the services a component will need.

There are three standard ways to show provided and required interfaces in UML: ball and socket symbols, stereotype notation, and text listings.

We can show a provided interface of a component using the ball symbol. A required interface is shown using the counterpart of the ball, the socket symbol drawn as a semicircle extending from a line. Write the name of the interface near the symbols.

Stereotype notation can be used to show required and provider interfaces. This notation is helpful if you want to show the operations of interfaces. If not, it is best to use the ball and socket notation, since it shows the same information more compactly.

When to use Component Diagram

Use component diagrams when you are dividing your System into components and want to show their interrelationships through Interfaces or the breakdown of components into a lower-level structure.