软件架构设计说明书

架构设计说明书

版本1.0.0

目录

1.引言

[对于由多个进程构成的复杂系统，系统设计阶段可以分为：架构设计（构架设计）、组件高层设计、组件详细设计。对于由单个进程构成的简单系统，系统设计阶段可以分为：系统概要设计、系统详细设计。本文档适用于由多个进程构成的复杂系统的构架设计。]

[架构设计说明书是软件产品设计中最高层次的文档，它描述了系统最高层次上的逻辑结构、物理结构以及各种指南，相关组件（粒度最粗的子系统）的内部设计由组件高层设计提供。]

[系统：指待开发产品的软件与硬件整体，其软件部分由各个子系统嵌套组成，子系统之间具有明确的接口；

组件：指粒度最粗的子系统；

模块：指组成组件的各层子系统，模块由下一层模块或函数组成；]

[此文档的目的是：

1）描述产品的逻辑结构，定义系统各组件（子系统）之间的接口以及每个组件（子系统）应该实现的功能；

2）定义系统的各个进程以及进程之间的通信方式；

3）描述系统部署，说明用来部署并运行该系统的一种或多种物理网络（硬件）配置。对于每种配置，应该指出执行该系统的物理节点（计算机、网络设备）配置情况、节点之间

的连接方式、采用何种通信协议、网络带宽。另外还要包括各进程到物理节点的映射；

4）系统的整体性能、安全性、可用性、可扩展性、异常与错误处理等非功能特性设计；

5）定义该产品的各个设计人员应该遵循的设计原则以及设计指南，各个编程人员应该遵循的编码规范。

]

[建议架构设计工程师与组件设计工程师共同完成此文档。]

[架构设计说明书的引言应提供整个文档的概述。它应包括此文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。]

1.1目的

[简要描述体系结构文档的目的。]

1.2范围

[简要说明此文档的范围：它的相关项目以及受到此文档影响的任何其它事物]

1.3预期的读者和阅读建议

[说明此文档的阅读对象，简要说明此文档中其它章节包含的内容与文档组织方式，对于不同读者的阅读方式建议。

如：

目标读者是系统最终用户、系统分析员、项目经理、产品经理、市场人员等。

此文档的第2章描述…..]

本项目的组织架构和参与人员如下：

A．项目负责人：

参与开发策划，负责批准项目开发计划书；

安排项目组成人员

从技术和业务上总体把握；

确定项目进度及检验标准

了解开发中存在问题，并及时制定相应对策。

B．技术总协调：

负责制订软件标准。

负责支撑软件的维护。

评估将在其中部署项目最终产品的目标组织的情况。

协调目标组织的建模工作。

在必要时对业务工程工作进行讨论和协调。

对目标组织中所建议的任何变更进行成本效益分析。

C．系统分析、设计：

负责获取用户最终需求，概括系统的功能和界定系统来领导和协调需求获取及用例建模，编

写《XXX新版本软件详细设计》，制订命名规范。

软件构架设计，划分子模块并详细描述各模块功能、要求,和测试要点。

对软件架构中重要的类做详细说明，描述其属性、方法、和相互之间的关系。

数据库设计，包括定义表、索引、视图、约束条件、触发器、存储过程等。

D．软件开发：

严格按照软件详细设计说明，负责自己开发的模块的资料、软件的备份及保管工作。

在软件开发中如发现系统分析设计时漏洞提出异议，提交问题报告至项目负责人。

对各自编写的内容相互交换作单元测试。

负责《用户使用手册》的编写。

E．文档编写：

负责编写软件《详细设计说明书》、《数据库设计说明书》、《测试方案文档》。

F．软件测试：

负责对各模块的集成测试，和软件的整体评估测试，在测试完后负责编写《测试报告》。

1.4术语、首字母缩写

1.5参考资料

此软件架构文档引用文件如下：

《计算机软件开发规范》 GB8566-88

《计算机软件产品开发文件编制指南》 GB/T 8567-2003

《计算机软件需求说明编制指南》 GB9385-88

《计算机软件测试文件编写规范》 GB9386-88

《计算机软件可靠性及可维护性管理》 GB/T14394-1993

《计算机软件质量保证计划规范》 GB/T12504-1990

《计算机软件配置管理计划规范》 GB/T12505-1990

《计算机软件测试文件编制规范》 GB/T9386-1988

《软件维护指南》 GB/T14079-1993

《软件文档管理指南》 GB/T16680-1996

《软件质量评价》 ISO/IEC 14589

2.系统逻辑结构

[本章描述系统的总体逻辑结构，包括组件（子系统）的划分与依赖关系定义、组件之间的接口定义、系统功能在组件之间的实现流程、组件功能定义]

2.1总体结构

[本节定义系统的总体逻辑结构，定义组件划分以及组件之间的依赖关系。

为了能够使系统具有较好的可重用性以及能够控制对第三方系统的依赖性（如第三方系统软件、中间件等），在结构设计时可以采用分层方法。系统可以分为专用应用层、通用应用层、中间件层、系统软件层。

为了统一与便于理解，当用图形化表示组件（子系统）、组件之间的依赖关系时，要求采用UML 的符号与表示方法。

]

2.2系统功能实现

[针对《产品需求说明书》中定义的功能特性，在此描述它们在相关组件（子系统）之间是如何实现的，系统功能实现描述是定义组件之间的接口以及组件功能的基础，选择若干代表性的用例来说明。在此要求用两种方式来描述功能实现：

1）UML的顺序图；

2）对顺序图的文字解释

需要注意的是UML顺序图中的生命线代表组件（子系统）。《产品需求说明书》中各个功能特性的数据流图或顺序图描述是此处设计的基础。]

2.3组件接口

[本节明确定义：各个组件之间的接口（系统内部接口）。如果组件之间采用通信协议作为接口，则需要详细定义应用层协议以及低层通信方式。如果采用API作为接口，则需要详细定义API 接口函数（包括参数定义）。]

[系统的所有对外接口在《产品需求说明书》中明确定义。]

2.4组件功能

[本节明确定义各个组件的软件功能，其依据是《产品需求说明书》以及系统功能实现描述。本节通常按照组件进行组织。

2.4.1 组件1

]

2.5数据库关系模型

[ 本节在逻辑层面上定义系统所包含的主体数据库模型，以及主要的实体关系，通常以E-R图形式来表现。]

3.系统物理实现

[本章明确定义各个组件的可执行程序名与库名、可执行程序与库的运行环境。可以采用如下表的方式来描述（一个组件包含一个可执行程序与多个库）。这是下一步设计与开发的分工依据。