This is the next installment in a series of articles about the essential diagrams used within the Unified Modeling Language, or UML. In my previous article on the UML’s class diagram, I described how the class diagram’s notation set is the basis for all UML 2’s structure diagrams. Continuing down the track of UML 2 structure diagrams, this article introduces the component diagram.
The diagram’s purpose
The component diagram’s main purpose is to show the structural relationships between the components of a system. In UML 2, components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces. Although the UML 2 specification does not strictly state it, components are larger design units that represent things that will typically be implemented using replaceable” modules. Components are strictly logical, design-time constructs. The idea is that you can easily reuse and/or substitute a different component implementation in your designs because a component encapsulates behavior and implements specified interfaces.
In component-based development (CBD), component diagrams offer architects a natural format to begin modeling a solution. Component diagrams allow an architect to verify that a system’s required functionality is being implemented by components, thus ensuring that the eventual system will be acceptable.
In addition, component diagrams are useful communication tools for various groups. The diagrams can be presented to key project stakeholders and implementation staff. While component diagrams are generally geared towards a system’s implementation staff, component diagrams can generally put stakeholders at ease because the diagram presents an early understanding of the overall system that is being built.
Developers find the component diagram useful because it provides them with a high-level, architectural view of the system that they will be building, which helps developers begin formalizing a roadmap for the implementation, and make decisions about task assignments and/or needed skill enhancements. System administrators find component diagrams useful because they get an early view of the logical software components that will be running on their systems. Although system administrators will not be able to identify the physical machines or the physical executables from the diagram, a component diagram will nevertheless be welcomed because it provides early information about the components and their relationships (which allows sys-admins to loosely plan ahead).
The notation
The component diagram notation set makes it one of the easiest UML diagrams to draw. Figure 1 shows a simple component diagram using the former UML 1.4 notation; the example shows a relationship between two components: an Order System component that uses the Inventory System component. As you can see, a component in UML 1.4 was drawn as a rectangle with two smaller rectangles protruding from its left side.
Figure 1: This simple component diagram shows the Order System’s general dependency using UML 1.4 notation
The above UML 1.4 notation is still supported in UML 2. However, the UML 1.4 notation set did not scale well in larger systems. For that reason, UML 2 dramatically enhances the notation set of the component diagram, as we will see throughout the rest of this article. The UML 2 notation set scales better and is also more informative while maintaining its ease of understanding.
Let’s step through the component diagram basics according to UML 2.
The basics
Deploy with confidence
Consistently deliver high-quality software faster using DevOps Continuous Delivery. Edit your code anywhere with Git repos and issue tracking, deliver continuously with an automated pipeline, get Insights to improve quality, and more.
Drawing a component in UML 2 is very similar to drawing a class on a class diagram. In fact, in UML 2 a component is merely a specialized version of the class concept. Which means that the notation rules that apply to the class classifier also apply to the component classifier. (If you read and understood my previous article regarding structure diagrams in general, and class diagrams in particular, you are well under way to understanding component diagrams.)
In UML 2, a component is drawn as a rectangle with optional compartments stacked vertically. A high-level, abstracted view of a component in UML 2 can be modeled as just a rectangle with the component’s name and the component stereotype text and/or icon. The component stereotype’s text is «component»” and the component stereotype icon is a rectangle with two smaller rectangles protruding on its left side (the UML 1.4 notation element for a component). Figure 2 shows three different ways a component can be drawn using the UML 2 specification.
Figure 2: The different ways to draw a component’s name compartment
When drawing a component on a diagram, it is important that you always include the component stereotype text (the word “component” inside double angle brackets, as shown in Figure 2) and/or icon. The reason? In UML, a rectangle without any stereotype classifier is interpreted as a class element. The component stereotype and/or icon distinguishes this rectangle as a component element.
Modeling a component’s interfaces Provided/Required
The Order components drawn in Figure 2 all represent valid notation elements; however, a typical component diagram includes more information. A component element can have additional compartments stacked below the name compartment. As mentioned earlier, a component is an autonomous unit that provides one or more public interfaces. The interfaces provided represent the formal contract of services the component provides to its consumers/clients. Figure 3 shows the Order component having a second compartment that denotes what interfaces the Order component provides and requires. (Note: Even though components are autonomous units they still may depend on the services provided by other components. Because of this, documenting a component’s required interfaces is useful.)
Figure 3: The additional compartment here shows the interfaces that the Order component provides and requires
In the example Order component shown in Figure 3, the component provides the interfaces of OrderEntry and AccountPayable. Additionally, the component also requires another component that provides the Person interface. (Note: Figure 3 does not show the Order component in its complete context. In a real-world model the OrderEntry, AccountPayable, and Person interfaces would be present in the system’s model.)