Software Connector

Explanation

Software is built from parts called components. Components rarely work alone. They interact. An architecture description needs a way to show these interactions. That is the job of a connector.

A connector represents an interaction between components.

Ports. A component has ports. A port is a point where the component interacts with its environment. Connectors plug in at these points. The article Port covers ports in more detail.

Roles. A connector has an interface, just as a component does. The connector’s interface is a set of roles. Each role is one participant in the interaction. A connector for an interaction between two parties therefore has a role for each side.

Putting the pieces together:

Components own the ports.
Connectors own the roles.
Plugging a connector into a port ties a component into the interaction.

This keeps two questions apart. Components answer “what are the parts?” Connectors answer “how do the parts interact?”

Example

Imagine a small shop system with two components: an “Order Service” and a “Payment Service”. The Order Service has a port where it asks for payments. The Payment Service has a port where it receives payment requests. A connector joins the two ports. It has two roles: one for the party that asks and one for the party that answers. In a diagram, you would draw this as a line between two boxes.

A connector joins the ports of two components. Each end of the connector is a role.

Diagram source

flowchart LR
  A[Component A] -- port --- C((Connector: role 1 and role 2)) --- B[Component B]

Checks

Interactions between components are shown as explicit connectors in the architecture description.
Each connector names its roles, so each participant in the interaction is identifiable.
Each connector plugs into identified ports of the components it joins.

Sources

Using Dependence Analysis to Support Software Architecture Understanding — arxiv.org, accessed 2026-11-09