# Common Component Diagram Mistake

**In short:** Two common component diagram mistakes are leaving artifacts unlinked to the components they embody, and letting components depend on each other in a cycle. Both are avoidable with manifestation links and acyclic dependencies.

## Explanation

A component diagram shows the parts of a system and how they depend on each other. See UML Component Diagram. Two mistakes are easy to spot in review.

**Artifacts with no link to a component**

An artifact is a physical piece of a system, such as a file that gets deployed. An artifact can embody, or *manifest*, model elements. A component is one such element. The artifact owns the manifestation relationships. Each one records that the artifact uses a model element.

So an artifact on a diagram with no manifestation line leaves readers guessing. They cannot tell which component it stands for. One artifact may manifest several elements. A single artifact can therefore be tied to more than one component.

**Circular dependencies between components**

A dependency means one component needs another to work. A cycle occurs when component A depends on B, and B depends, directly or through others, back on A.

The acyclic dependencies principle says the dependency graph of components must have no cycles. In other words, it forms a directed acyclic graph: arrows run one way and never loop back.

Cycles can always be broken. One way is to create a new package and move the shared dependencies into it. Both original components then depend on the new package, not on each other.

## Example

A shop diagram shows an "Orders" component and a "Customers" component. Orders needs customer data. Customers needs order history. The two arrows form a loop.

The fix: move the shared parts, such as the customer and order record definitions, into a new "Shared Records" package. Both components now point to that package. No arrow points back.

On the same diagram, a file named `shop.jar` appears with no line to anything. Adding a manifestation relationship from the file to the component it embodies removes the guesswork.

## Trade-offs

Breaking a cycle by moving shared parts into a new package adds one more element to the diagram and to maintain. The facts here do not go further than that, so check each case on its own.

Cycle removed through a shared package, and an artifact linked to its component by a manifestation.

```plantuml
@startuml
component Orders
component Customers
package "Shared Records" as Shared
Orders ..> Shared
Customers ..> Shared
artifact "shop.jar" as Jar
Jar ..> Orders : <<manifest>>
@enduml
```

## Checks

- Every artifact on a component diagram is linked by a manifestation relationship to the model element, such as a component, that it embodies.
- The dependency graph between components has no cycles.
- Where a cycle existed, it was broken, for example by moving shared dependencies into a new package.

## Related

- [UML Component Diagram](https://arc.fuet.ch/concepts/modeling-uml/uml-component-diagram.md)
- [Component Connector (Assembly and Delegation)](https://arc.fuet.ch/concepts/modeling-uml/component-connector-assembly-and-delegation.md)
- [Delegation Connector](https://arc.fuet.ch/concepts/modeling-uml/delegation-connector.md)
- [Provided and Required Interface](https://arc.fuet.ch/concepts/modeling-uml/provided-and-required-interface.md)
- [Coupling and Cohesion](https://arc.fuet.ch/concepts/principles/coupling-and-cohesion.md)
- [Modularity](https://arc.fuet.ch/concepts/principles/modularity.md)
- [UML Modeling Anti-Pattern](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-anti-patterns.md)
- [UML Deployment Diagram](https://arc.fuet.ch/concepts/modeling-uml/deployment-diagram.md)

## Sources

- [Unified Modeling Language 2.5 (UML) FTF — Open Issues - OMG Issue Tracker](https://issues.omg.org/issues/UML25-197) — issues.omg.org, accessed 2026-11-09
- [Acyclic dependencies principle - Wikipedia](https://en.wikipedia.org/wiki/Acyclic_dependencies_principle) — en.wikipedia.org, accessed 2026-11-09