architecture_design_guidelines 建筑设计指导英文版

1 Documenting the Architecture - Guidelines

1.1 General

Note: This document provides a set of guidelines to follow for documenting your system architecture in your Architecture Design Specification (ADS). This guideline document is not a template that you should replicate and complete, but it can be used as the basis for construction of your document. That is, the section numbering and naming used herein is a reference for the content of the Architecture Design Specification Document, NOT the structure of the ADS.

Your architecture defines how the system/product will be constructed, describing what the critical components are and how they fit together, from a high-level, logical perspective. It does not provide the details of your design – that comes later. Your architecture must be documented in a way that clearly states the identification of the logical layers of your system, the specific subsystems that compose the layers, and their responsibilitiesand interfaces. While an architectural block diagram is a static model of the architecture, we will use an additional model: a data flow-like model based on the architectural block diagram. The next several sections describes the logical organization, representation and content of the architecture specification itself.

1.2 Introduction

Your introduction should describe your product concept in sufficient detail that the architectural design will be easy to follow. The introduction may include information used in the first sections of your SRD for this purpose. At a minimum, ensure that the product concept, scope and key requirements are described.

1.3 Meta Architecture

Specify in this section your architectural vision, key principles, special styles/conventions to be followed, concepts and key assumptions that will affect how you will go about designing the product. Focus on the high-level decisions that will strongly influence the structure of the system. This section should rule out certain structural choices, and guide your decisions and tradeoffs among others.

1.4 Layer Definition Section

This section should describe the overall structure of your software system. Think of it as the strategy for how you will build the system. An architectural “layer” is the top-level logical view, or an abstraction, of your design. also contain the high-level block diagram of the layers, as shown in the example below, as well as detailed descriptions of the functions of each layer.

Figure 1.1. An Example of an Architectural Layer Diagram

Note in Figure 1.1 that vertical layers can be used to show availability of services to multiple other layers, as they may provide centralized common services at various levels.

1.4.1 Layer-Name and Description

Each layer should be described separately in detail. Descriptions should include the features, functions, critical Also include any conventions that your team will use in describing the structure: naming conventions for layers, subsystems, modules, and data flows; interface specifications; how layers and subsystems are defined; etc.

1.5 Inter-Subsystem Data Flow Section

This section breaks down your layer abstraction to another level of detail. Here you grapically represent the logical subsytems that compose each layer and show the interactions/interfaces between those subsystems. A subsystem can be thought of as a programming unit that implements one of the major functions of the layer. It, therefore, has data elements that serve as source/sinks for other subsystems. The logical data elements that flow between

subsystems need to be explicitly defined at this point, beginning with a data flow-like diagram based on the block diagram. Following is an example of a data flow diagram, taken from a prior senior design project:

Figure 1.2. An Example of an Architectural Data flow Diagram.

Once the inter-layer data flows have been exposed, each of the elements flowing between layers must be described. This is often best done in a simple tabular form as shown in sample of Table 1.1 below. The specific data elements depicted in the data flow diagram are described in detail in this sub-section. Each named data element is described in terms of its generic type, its use and any other relevant information.

Table 1.1. Sample Inter-Subsystem Data Element Descriptions.

Descriptions

table here. This is any additional information about the

Data Element:

the name by which the data element is referred to in the rest of the document. Note that the term data element as used above also specifies complex elements such as

objects or structures. For example, a data element could be an integer value, a string of characters, or a JPEG graphics object.

a verbal description of the data element. Specify here what the element is in terms of its composition/type, and what it is used for.

Description:

Once the elements themselves are described, their actual flow paths should be documented. Because the flow of any element is from producer (source) to consumer (sink), the flows are most easily summarized by the use of a flow path transition matrix, such as:

Table 1.2. Producer-Consumer Relationships.

Producer Subsystem: name of the layer or subsystem that creates the data elements specified. Note that this

is the layer that invokes the constructor for the data element, not necessarily the layer that owns the constructor.