Components, connectors, and associations
This was a question from the CMU software architecture class that I think highlights a common misunderstanding.
Question
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.
Answer
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 ways).
