Mumbai University > Information Technology > Semester 7 > Software Architecture.

There is no industry-standard template for documenting a view, but the seven-part standard organization mentioned below has worked well in practice. Allocating specific information to specific sections will help the documentation writer deal with the task and recognize completion, and it will help the documentation reader quickly find information of interest at the moment and skip everything else.

1. Primary presentation shows the elements and the relationships among them that populate the view. The primary presentation should contain the information about the system. It should certainly include the primary elements and relations of the view. For example, we may wish to show the elements and relations that come into play during normal operation, but relegate error handling or exceptional processing to the supporting documentation. The primary presentation is usually graphical. Sometimes it can be tabular.
2. Element catalog details those elements and relations which are depicted in the primary presentation, and few other details. In addition, if there are elements relevant to the view that were omitted from the primary presentation, the catalog is where those are explained.
3. Context diagram shows how the system depicted in the view relates to its environment in the vocabulary of the view. For example, in a component-and-connector view we show which component and connectors interact with external components and connectors, via interfaces and protocols.
4. Variability guide shows how to exercise any variation points that are a part of the architecture shown in this view. In some architecture, decisions are left unbound until a later stage of the development process, and yet the architecture must still be documented A variability guide should include documentation about each point of variation in the architecture, including -
5. The options among which a choice is to be made.
6. The binding time of the option. Some choices are made at design time, some at build time, and others at runtime.
7. Architecture background explains why the design reflected in the view came to be. The goal of this section is to explain to someone why the design is as it is and to provide a convincing argument that it is sound. An architecture background includes - • Rationale, explaining why the decisions reflected in the view were made and why alternatives were rejected. • Analysis results, which justify the design or explain what would have to change in the face of a modification. • Assumptions reflected in the design.
8. Glossary of terms used in the views, with a brief description of each.
9. Other information, which might include management information such as authorship, configuration control data, and change histories. Or the architect might record references to specific sections of a requirements document to establish traceability.