Summary Checklist

  • Component-and-connector (C&C) views define models consisting of elements that have some runtime presence, such as processes, objects, clients, servers, and data stores. Additionally, component-and-connector models include as elements the pathways of interaction, such as communication links and protocols, information flows, and access to shared storage.
  • Components have interfaces, which are called ports.
  • Connectors have interfaces, which are called roles.
  • Connectors need not be binary, meaning that they may have more than two roles. Even if the connector is ultimately implemented using binary connectors, such as a procedure call, it can be useful to adopt n-ary connector representations at an architectural level.
  • If a component's primary purpose is to mediate interaction between a set of components, consider representing it as a connector instead.
  • Connectors can and often should represent complex forms of interaction. Even a semantically simple procedure call can be complex when carried out in a distributed setting, involving runtime protocols for timeouts, error handling, and locating the service provider.
  • Connectors embody a protocol of interaction. When two or more components interact, they must obey conventions about order of interactions, locus of control, and handling of error conditions and timeouts. When providing a detailed description of a connector, the documentation should attempt to capture this detail.
  • Be clear about which style you are using, by referring to an appropriate style guide.
  • Make clear which port is used when attaching a component to a connector.
  • If it is not clear that it is valid to attach a given port with a given role, provide a justification in the rationale section for the view.
  • Make clear which ports are used to connect the system to its external environment.
  • Data flow and control flow diagrams are projections of C&C models. When creating such diagrams, be explicit about the semantic criteria being used to determine where the arrows go. Data flow and control flow projections are at best ap-proximations to the connectors, which define the components' interactions.

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

Advanced Concepts

Documenting Software Interfaces

Documenting Behavior

Choosing the Views

Building the Documentation Package

Other Views and Beyond

Rationale, Background, and Design Constraints

References



Documenting Software Architectures(c) Views and Beyond
Documenting Software Architectures: Views and Beyond
ISBN: 0201703726
EAN: 2147483647
Year: 2005
Pages: 152

Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net