Organizing Connections
Connection definition and their content come from the interface views allocated to each component it connects. After the allocation decisions are made, we can derive the interfaces for the architecture components directly from the data components that were allocated to each component. Each message whose receiver becomes part of the interface between the components holding the sender and the receiver. The component collaborations that result can be viewed as lines indicating that there is some communication between components. We can populate those lines with actual messages.The collection of messages may give us a view that we have not seen before. For instance, we have gone to some trouble to separate the Skin and Service components from the rest of the application. The motive was that they may represent possibilities of change, and be reusable within this application and even across multiple applications. A recommendation to keep message consistency is to choose a single set of messages, which should be mapped back to the defined component behaviour. The diagrams should be redone using the new message sets for the components.
After determining that the messages are sufficient and consistent, they should be organized into connections. Connections are as an important part of the architecture as the components. The connections are the basis for component reuse within a single application and across multiple applications, and it is important to define them carefully, to arrive at a consistent connection definition, combining the messages from other interfaces into one consistent superset of the current messages. From this information, it may be possible to find relations between components that have been modelled before, and are now documented as design patterns [POSA96, PLoP94, GoF94, PLoP95]. These can be used at this level for the design and implementation of all connectors in the description.
Jorge Luis Ortega Arjona.