Here in the early days of what some are calling the age of component-based software engineering, we are awash in stories where the architect thought he or she could plug two components together with a connector, only to find out that the component didn't implement the right protocol, or was otherwise badly matched with the expectations of that connector. This is why we prescribe writing a justification where the match-up is less than obvious. For a thoughtful treatment of element mismatch, see [Garlan+ 95].
It is tempting to treat architecture as an assembly of components, but there are great conceptual advantages to be gained from elevating connectors to a first-class architectural status as well. Mary Shaw makes an eloquent argument for doing so in [Shaw 96b]. Shaw and Garlan [ShawGarlan 96] treat software architecture in terms of components and connectors and address concerns such as constructing systems as assemblies of components. For a more thorough discussion of connector mechanisms see [Shaw+ 96]. Allen and Garlan lay out the semantic foundations for connectors as first-class entities [AllenGarlan 97].
Software Architectures and Documentation
Part I. Software Architecture Viewtypes and Styles
The Module Viewtype
Styles of the Module Viewtype
The Component-and-Connector Viewtype
Styles of the Component-and-Connector Viewtype
The Allocation Viewtype and Styles
Part II. Software Architecture Documentation in Practice
Documenting Software Interfaces
Choosing the Views
Building the Documentation Package
Other Views and Beyond
Rationale, Background, and Design Constraints