Components, connectors, and associations

Apr 2, 2008 | George Fairbanks

This was a question from the CMU software architecture class that I
think highlights a common misunderstanding.


Is there any real difference between a component and a connector? I tend to take connectors as:

  • Interface and protocol between 2 components
  • A component whose major purpose is conveying information

For example, in a typical drawing of the architecture of web services,
you wouldn’t see the web server. (You would see a web container, but
that is something different).

The web server is reduced to a connector between the client and the
web-tier components, because we do not care too much at this level
from this angle.

It does not mean a web server is not important, or it is very simple;
it’s just we “choose” to hide it in this particular diagram. It does
not have to be hidden always. When we want to discuss the link layer
security or load balance of the system, the “connector” shows up as a
group of components.

It is the same for the pipe-n-filter C&C view we had in the
class. Making a “pipe” a connector is only adequate if you “choose” to
focus on the filters on this diagram. If the pipes are intelligent and
can consume all your available memory, as I have seen in some
proposals, we may choose to express them as separate components in
some other diagrams.

If we accept this vague definition, can we say a connector is roughly
the same as the “association” in UML? We can always beef up an
association with class or stereotype to give it more meaning.


One way to think of this is that you don’t need any of these
abstractions: components, connectors, ports, roles, … But many
people find them useful, especially as you think about larger systems.

Components “do work” while connectors “move stuff around”. When you
look closer, “moving stuff around” is work in itself. So in that
sense connectors and components are equivalent. But you could also
say that neither one exists at all, and it’s all just machine
instructions. You aren’t wrong to think of everything as machine
instructions, but you will not get much leverage on harder problems.

Regarding your last point, associations in UML are different than
connectors. First, associations are between objects, not components.
I would use a UML association to represent the “head” pointer in a
linked list data structure. Second, associations imply only that
there is a relationship between the objects, not that they
communicate. I don’t think of the head pointer communicating with a
node in the linked list. Connectors are helpful when you want to tell
the reader that two components communicate over a channel (and the
usual “closed” semantics means that they do not communicate in other


George Fairbanks is a software developer, designer, and architect living in New York city

+1-303-834-7760 (Recruiters: Please do not call)
Twitter: @GHFairbanks