Software architecture serves as the basis for the design, QA and PM of a project.
The SAD (Software Architecture Document) contains architecture-specific design information

Representations

Architectural Views

There are many ways to represent software architecture, such as:

• Decomposition Views
• Execution Views
• Dependency Views
• Deployment Views
• Work-Assignment Views

Architectural Representations

Informal block diagrams show entities and relationships within an architecture
Semiformal representations use a standardised notion without complete semantics, like UMLs
Formal representations use precise semantics which can be used with formal analysis (ADLs)

Views

Decomposition View

• Decomposition views visualise systems as an often hierarchical set of programmable units
• The view may be represented by multiple models
• Decomposition views can be informal, simply being an indented tree of units
• They can be semiformal using UML package diagrams

Dependency Views

The dependency view shows dependencies between units, it’s often useful in project planning and change impact

• Informally, it can be a table (one column being the dependency, and another being the dependent)
• Semiformally, it can be a data-flow diagram or a UML package diagram with <<use>>

Execution View

The execution view shows the runtime structure of a system.
It is often drawn as a flowchart

• Each component is a distinct executing entity which may have its own progarm stack
• Connectors exist as intercomponent communication mechanisms
• Many different representations can be used, such as sequence diagrams

Implementation view

The implementation view describes which files in the source tree map to units in the program’s design
It can make it easier to find source owners for a particular unit, etc

Deployment View

Deployment views map runtime entities onto computer resources, such as PCs or servers

Work-Assignment View

The work-assignment view decomposes the design of a system into tasks that are assigned to project teams

IPO Chart

An IPO chart, as the name suggests, describes how information is processed in the program

UML Activity Diagrams

Activity diagrams describe logic, they are not unlike flowcharts but allow for parallelism
They are sometimes used to map use-cases to designs

Software Architecture Documents

A design is a collection of views, showing how views relate to one another.
The SAD will of course include multiple views, at least a decomposition and execution view.
The structure and attributes to be measured determines the number and type of additional views to include in the SAD.
It is recommended to follow ISO/IEC/IEEE 42010 for SADs

Recommended Practices

1. Architecture description
2. Stakeholder and concern identification
3. Architecture viewpoint selection
4. Architecture views
5. Consistency and correspondences among architectural views
6. Architectural rationale

Examples

http://www.iso-architecture.org/ieee-1471/docs/SBSCS-AD-v02.pdf

http://www.iso-architecture.org/ieee-1471/docs/health-watcher-AD.pdf

Collaborative Design

The design of a software system is often underpinned by a team of developers.
The team must address numerous issues such as which member to design each aspect, how they should be documented, and how all the units should be coordinated and integrated.