Components are part of a view on a system. A component may refer to a enclosed element or to a complete system of its own.
Components are modules of the system.
For larger systems a component document may describe the component briefly and link to a space with detailed information on the component. This is especially true in case the component has its own release cycle.
The document type component provides the following properties:
Please note that only information about specific properties is provided here. Common document property used by all document types are documented by Document Properties.
Define the depth of the containment hierarchy for this component.
This value is typically derived automatically by the depth of this document within its component documents tree.
Add references to information on external systems here.
Give a brief description of the design and the usage of the component.
In contrast to the short description this section may contain any formatting and text elements required. This section is intended to be transcluded by other documents that refer to this component.
May contain a context diagram centred on the component, but keep it very small. Also note that in case such a diagram is included, make sure to include it in every component description. Documents may transclude the abstract information from different components. Nonetheless these documents should appear monolithic to the reader. If in doubt, add the context diagram to the view section.
Provide an overview description of the component. This summary should cover every aspect of the component from a higher level.
The summary is intended to be transcluded in overview documents.
Provide a list of configuration options of the component.
List properties that are mandatory to run this component.
List properties that are optional to run this component.
Use cases allow to define how the component is used. This section may also show use cases where the component plays only a small role. Add a reference to a use case document for each identified use case.
Quality scenarios document the important quality aspects of the component. Add a reference to a quality scenario document for each important quality of the component.
With architecture aspects the team documents aspects that have impact on all components of the system. List the aspects that are most important for the component.
Components are important to the system. To explain their construction, runtime behaviour or deployment use view documents.
This section may also contain a context diagram.
List how other components may communicate with this component over its interfaces.
List the interfaces provided by this component.
List the interfaces required by this component.
List the artifacts that manifest this component.
List subcomponents within this component.
You may want to Reference components that are associated with this one. This makes it easier for readers to get information about those collaborators.
But this list of references is not restricted to collaboration. You may also reference components that are connected to this component in any other way. For instance, a component may be replaced by other components that implement the same interface. Listing those components may be very helpful for teams having the task to assemble a system.
This information may be part of the Interface section or have its own section.
A components design or implementation may be based on some architectural decisions. List those that are important to understand the component.