UML Weekend Crash Course™ - To Parent Directory

Session 25—Modeling the Static View: The Component Diagram 257
Component interfaces
A component interface may be modeled in either of two ways. One way is to use a class with
the stereotype attached to the component with a realization arrow, as
shown in Figure 25-2. The realization arrow looks like the generalization symbol with a
dashed line. To realize the interface means to apply it to something real like the executable.
OrderEntry.exe
Order
Figure 25-2 Interface notation using a class and stereotype
A second, more common, technique is to use a “lollipop” attached to the component
with a solid line, as shown in Figure 25-3. If you look into the UML specification examples,
the circle on the end of the lollipop is very small. This is a bit distorted from the typical
notation employed by modeling tools.
OrderEntry.exe
OrderInt
Figure 25-3 Interface notation using the lollipop
The interface implemented by a component is actually implemented by the classes within
the component, so the interface should already have been defined in your Class diagrams.
Also, a component may implement as many interfaces as it requires. The number and exact
type of interfaces are dictated by the classes implemented by the component.
Component dependencies
Dependencies between components are drawn with the dashed arrow from the dependent
component to the component it needs help from. In Session 24, you learned that package
dependencies could be stereotyped to clarify the nature of the dependency. The same is true
for component dependencies. In Figure 25-4, the OrderEntry depends on the OrderEntry.exe
component. The UML stereotype means that the OrderEntry file literally
becomes the OrderEntry executable at runtime. OrderEntry would be the code sitting on a
storage device. At runtime it is loaded into memory and possibly even compiled. Then during
execution the OrderEntry.exe component would depend on the three other components:
orders.dll, inventory.dll, and orders.tbl.