Purpose of Component Diagram
The purpose of a component diagram is to show the relationship between different components in a system. For the purpose of UML 2.0--and for any time that we discuss components on this site-- we are referring to a module of classes which represent independent systems or subsystems that have an ability to interface with the rest of the system. There exists a whole development approach that revolves around components, called component-based development (CBD). In this approach, component diagrams allow the planner to identify the different components so the whole system does what it's supposed to do.
More commonly, in an OO programming approach, the component diagram allows a senior developer to group classes together based on common purpose so that the devloper and others can look at a software development project at a high level.
UML 2.0 Component Diagram Notation
There are three popular ways to create a component's name compartment. You always need to include the component text inside the double angle brackets and/or the component logo. The distinction is important because a rectangle with just a name in it is reserved for classifiers (class elements).
As with the class notation, components also have an optional space to list interfaces, similar to the way you add attributes and methods to class notation. Interfaces represent the places where the groups of classes in the component communicate with other system components. An alternative way to represent interfaces is by extending symbols from the component box. Here is a quick run down of the most commonly used symbols.
- Provided interfaces 0--[component] - is a straight line from the component box with an attached circle. These represent the interfaces where a component produces information used by the required interface of another component.
- Required interfaces [component]-( is a straight line from the component box with an attached half circle. This is also represented as a dashed arrow with an open arrow. These represent the interfaces where a component requires information in order to perform its proper function.
An easy way to remember this is that the provided interface looks like a ball being thrown by the component, and the required interface look like a catcher's mitt ready to catch a ball.
Component Diagram Examples
Here is a simple component diagram putting together all the parts that we have covered. In the example, we have 3 simple components that work together to create a whole system. You might remember this system from elementary school.
The example above uses UML 1.x notation for the the required interface because Lucidchart currently doesn't support the half circle shape. Each component is a complicated subsystem that interfaces with another component by producing a requirement needed by another component.
Start your Lucidchart trial here. No download or plugins required.