完整word版软件架构设计模板讲解.docx

完整word版软件架构设计模板讲解.docx

《完整word版软件架构设计模板讲解.docx》由会员分享，可在线阅读，更多相关《完整word版软件架构设计模板讲解.docx（13页珍藏版）》请在冰豆网上搜索。

完整word版软件架构设计模板讲解

架构设计说明书

产品发布标识

［填写说明：

模板中用方括号括起来并以蓝色斜体显示的文本，用于向作者提供指导，在文档编辑完成后应该将其删除。

文档正文应使用常规、黑色、五号字体即系统设置的“正文”样式

文档页眉处的”xxxx系统”和“版本号”仅为示例，请注意更新封页与页眉符合实际情况。

此处的版本号指的是产品版本号

封页简要表中的产品名，如无可以不填写。

当某一章/节没有内容时，必须注明N/A，同时标注理由。

例如：

本章/节内容无需考虑。

特别说明：

当某章/节内容参见其它文档时，不能注明N/A，而应该写明参见某文档的具体章节。

］

文档版本号：

文档编号：

文档密级：

归属部门/项目：

产品名：

子系统名：

编写人：

编写日期：

华为科技（深圳）有限公司版权所有

内部资料注意保密

修订记录:

版本号

修订人

修订日期

修订描述

V1.0A

王巍

2004-5-11

创建初稿

V1.0B

周旳

2006-4-23

根据CMMI新流程予以修订

V1.0C

ENG-TWG

2006-8-9

根据CMMI要求予以修订

派发清单:

发文人/部门

日期

电话/传真

受文人/部门

动作类型*

日期

电话/传真

*动作类型：

批准、审核、通知、归档、参与会议，其它（请说明）

1简介6

1.1目的6

1.2文档范围6

1.3预期的读者和阅读建议6

1.4参考文档8

1.4.1包含文档8

1.4.2相关文档8

1.5缩略语和术语8

2总体设计思路9

2.1设计方法9

2.2设计可选方案9

3系统逻辑结构10

3.1总体结构10

3.2子系统定义10

3.2.1子系统一11

3.2.2子系统二11

3.3接口设计11

3.3.1产品外部接口11

3.3.2子系统间接口11

3.4主要数据模型11

4系统物理结构12

4.1总体结构12

4.2组件定义12

4.2.1组件一12

4.3组件接口设计12

4.4组件与子系统对应关系12

5系统部署13

5.1网络结构图13

5.2部署模式13

6关键技术及公用机制13

6.1关键技术设计13

6.2公用机制说明13

7系统重用设计13

7.1第三方硬件设备说明15

7.2第三方软件说明15

8系统非功能特性设计15

8.1可扩展性15

8.2可维护性15

8.3安全16

8.4容错性16

8.5可移植性16

8.6可部署性16

8.7…•16

9总体约束16

9.1遵循标准16

9.2文件约定17

9.3目录约定17

9.4对后续设计的约束17

9.5……17

10风险17

11附录17

1简介

1.1目的

［描述本架构设计文档的主要目的。

架构文档从构架方面对系统进行综合概述，描述了系统最高层次上的逻辑结构、物理结构以及各种指南。

它用于记录并表述已在构架方面对系统作出的重要决定，并对相关子系统的设计起总体上的指导作用。

］

1.2文档范围

［简要说明此文档的范围：

它的相关项目以及受到此文档影响的任何其它事物

例如，本文档适用的产品、模块，覆盖的范围等，受这份文档影响的相关产品、模块等,不在该文档覆盖范围内的但可能引起疑义的问题。

］

1.3预期的读者和阅读建议

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

如：

XXX系统开发过程的各角色：

产品角色、系统分析架构角色、项目管理角色、代码角色、测试角色、文档角色

XXX系统的部署角色、培训角色、维护角色；

XXX公司售前技术支持角色

此文档的第2章描述•••••

系统体系结构图

子系统

模坎组件

子模抉

4

单无

进程、线殺类库等

例如：

本文档组织方式:

第一章简介，描述文档的目的；

第二章描述总体设计思路，包括设计方法及备选设计方案和方案的选择；

第三章描述系统的逻辑结构。

从最高层次上描述系统的逻辑组成；

第四章描述系统的物理结构。

从最高层次上描述系统的物理组成；

第五章描述系统的部署情况；

第六章对系统架构中的关键技术及公用设计机制进行描述；

第七章如何重用以往设计产物及现有设计如何对将来重用产生影响进行描述；

第八章对系统中重要的用例或者有技术难度的部分进行功能实现的描述，以方便设计人员在进行设计、开发时进行参考；

第九章对系统依赖的第三方软硬件进行描述；

第十章对系统的非功能特性设计进行描述；产品经理应当关注该部分的描述是否与产品需求中产品的非功能性需求一致；开发人员应当在后续设计过程中对这部分设计进行关注，避免遗漏；测试人员应当根据这部分的描述制定测试案例，验证是否可以达到产品需求的要求。

第十一章描述系统架构设计中的约束条件；

第十二章描述架构设计中识别的风险，产品经理、设计人员、开发人员和测试人员

都应当随时关注这些风险，避免风险发生并及时采取规避、减轻措施。

第十三章附录

］

1.4参考文档

［架构设计的参考文档应当包括但不限于：

产品需求说明书等；

同时，文档中说明为引用、参考的文档也应该在这里列出。

参考文档需要按包含、相关的关系分别在下面的小节中列出。

］

1.4.1包含文档

［当本文有包含文档时，需要提供相关的包含文档列表。

包含文档：

作为本架构设计的一部分，是不可分割的组成部分，读者阅读本架构设计时必须同时也阅读的文档。

如当架构设计非常复杂而有分册时，贝分册就属于本文档的包含文档。

］

142相关文档

［当本文有相关文档时，需要提供相关文档列表。

相关文档：

具有关联关系的文档。

读者在阅读架构说明书时如果有必要可以参考阅读的文档。

］

1.5缩略语和术语

［适当时，提供与此文档相关的术语及缩略语的定义。

］

缩略语/术语全称说明

2总体设计思路

2.1设计方法

［本软件系统所采取的设计方法，以及主要的设计原则。

设计方法可包括但不限于：

1）采用RUP的设计方法论；

2）采用从业务而下的系统分解，从技术至上的系统抽象方法

以及具体应用系统的特定设计方法等。

］

2.2设计可选方案

［对本系统的几种设计方案进行分析、比较，并确定所采用的方案。

可选方案不仅是对同一需求的不同处理方式，也可以是需求与设计元素之间配置的不同思考，包括新研发的技术，或者是不同应用的成熟技术及维持现有方法，目标是将整体的解决方案最佳化，而非个别设计的优劣。

可选解决方案涵盖可接受的成本、计划、效能的范围。

产品关键需求与设计问题、限制及准则一起用于开发备选方案。

评选的准则通常必须强调成本（例如：

时间、人员、费用）、效益（例如：

性能、有效性）及风险（例如：

技术、成本、计划）。

详细的可选解决方案及评选的准则可包括但不限于：

成本（研发、购买、支持、产品生命周期）

技术性能

技术限制

产品的扩展及成长性

需求与技术的演进

最终用户及操作者的能力与限制

构建方法与材料的敏感度

风险

以上为最基本的考虑因素，研发团队应该开发与目标一致的备选方案节选准则，以缩小可选清单，并可以通过决策分析的方法来进行评估选择。

例如：

1）可选方案一

2）可选方案二

3）方案的评选策略及准则

需要包括决策分析单。

tppserverselect\d

4）最佳化的方案

］

3系统逻辑结构

［本章描述系统的总体逻辑结构，包括子系统的划分与依赖关系定义、子系统之间的接口定义、子系统功能定义。

］

3.1总体结构

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

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

］

3.2子系统定义

［本节明确定义各个子系统的功能以及子系统的设计思路，本节通常按照子系统进行组织。

］

321子系统一

［包括：

子系统概述

子系统功能

子系统设计思路］

322子系统二

3.3接口设计

［定义接口设计的策略，识别接口，以及接口完成的功能，具体接口定义另行定义文档承载，采用接口设计说明书模板。

］

3.3.1产品外部接口

［描述产品对外接口的相关定义。

］

3.3.2子系统间接口

［描述产品内部子系统间接口的相关定义。

］

3.4主要数据模型

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

具体的数据字典及数据结构在数据库设计文档中定义，在高层设计阶段完成。

4系统物理结构

［定义系统总体物理结构、包括组件划分及依赖关系定义，每个组件中要完成的功能及组件间接口。

如功能已经在前面的子系统分解中有描述，则重点描述本组件完成了哪些子系统的哪些功能。

组件是物理上的运行结构元素。

例如：

进程、线程等。

］

4.1总体结构

［本节定义系统的总体物理结构，定义组件划分以及组件之间的关系。

］

4.2组件定义

421组件一

［包括：

组件名称

组件类型

组件功能］

4.3组件接口设计

［定义接口设计的策略，组件间的接口主要是描述一些共享内存，协议数据，消息等，具体接口如有需要可另行定义文档承载，采用接口设计说明书模板］

4.4组件与子系统对应关系

［定义组件与子系统的关系，即各组件实现哪些子系统功能，可通过列表的形式定义，如有需要，可通过图示的形式加以说明。

］

5系统部署

［本章描述系统部署，说明用来部署并运行该系统的一种或多种物理网络（硬件）配置。

对于每种配置，应该指出执行该系统的物理节点（计算机、网络设备）配置情况（包括硬件、操作系统、支撑软件）、节点之间的连接方式、采用何种通信协议、网络带宽。

另外还要包括各进程到物理节点的映射。

］

5.1网络结构图

［描述系统所处的整体网络结构。

］

5.2部署模式

［描述系统几种可能的部署模式，并解释在定义配置时要遵循的一般映射规则。

例如：

在不同的业务规模情况下，存在的不同部署模式。

］

6关键技术及公用机制

6.1关键技术设计

［描述系统的关键技术设计，以解决重要或高风险的问题］

6.2公用机制说明

［描述系统实现所需要的公用机制，例如采用的中间件技术、通用缓存等］

7系统重用设计

［软件重用是指通过对已有软件的各种有关知识来建立新的软件，这些知识包括：

领域知识、开发经验、设计经验、设计决定、体系结构、需求、设计、编码、测试和文档等。

这个定义蕴含着软件重用所必须包含的两个方面：

1.系统地开发可重用的软件产品。

2.系统地使用这些软件产品作为构筑新的软件产品，来建立新的系统。

软件重用目的是降低软件开发和维护的成本，提高软件开发效率，提高软件的质量。

软件重用的过程一般包括，抽象、选取、特化、集成：

抽象，对已有软件产品的概念描述，从中抽取该产品的本质信息（即可重用部分）。

选取：

用户根据已有软件产品的抽象，寻找、比较和选择最适合需要的软件产品（可重用件）。

特化：

对已有软件产品（可重用件）的修改或形成它的一个实例（实例化后的重用件）集成：

将实例化后的重用件集成到应用系统。

软件重用的形式，常用的为垂直式重用和水平式重用：

垂直式重用：

指在一类具有较多公共性的应用领域之间进行软件重用，由于存在许多共性或相似性，因此重用面较广，且有助于获得系统的通用模型。

首先进行领域分析，根据应

用领域的特征及相似性预测软件的可重用性；然后进行相应的软件开发。

一旦确认了软件的重用价值，即可进行通用化，以便能够适应新的类似的应用领域；最后，对软件及其文档进行管理，成为可供后续项目使用的可重用资源。

水平式重用：

重用不同应用领域中的软件元素，例如数据结构、分类算法、人机界面构件等。

标准函数库是一种典型的原始的水平式重用机制。

软件重用的粒度主要有以下几种：

1.源代码模块或者类一级的重用。

这是最基本的软件重用形式。

2.二进制形式的重用。

如组件重用。

3.组装式重用。

比如：

把好几个应用程序的功能集成在一起。

例如，要建立一个门户站点应用，登陆用户既可以查询天气情况，又可以查看股市行情，还可以在线购物。

这些功能由不同网络应用服务供应商提供，通过这种组装式重用，就可以非常容易地把上述功能都集成到新的门户站点中。

4.分析级别重用。

5.设计级别重用。

6.软件文档重用。

软件重用技术

软件重用技术包括：

库函数，模板，面向对象、设计模式、构件、体系架构、体系架构模式/风格等。

1.库函数

对于库函数的使用者，只要知道函数的名称，返回值的类型，函数参数和函数功能就可以对其进行调用。

2.面向对象

面向对象技术通过方法、消息、类、继承、封装、和实例等机制构造软件系统，并为软件重用提供强有力的支持。

如VC++中的MFC。

3.模板

模板相当于工业生产中所用的“模具”。

有各种各样的模板（如文档模板，网页模板等），

利用这些模板可以比较快速地建立对应的软件产品。

模板把不变的封装在内部，对可能变化

本号，运行环境，参数以及简要描述］

7.1第三方硬件设备说明

［描述系统可使用的第三方硬件需求，以及第三方硬件的简要描述。

例如：

需要加密卡提供高速逻辑加密功能；需要网络交换机提供四层交换功能等。

］

7.2第三方软件说明

［描述系统可使用的第三方软件需求，以及第三方软件的简要描述。

］

8系统非功能特性设计

［本章描述系统的整体性能、安全性、可用性、可扩展性、容错等非功能特性设计。

］

8.1可扩展性

［描述系统可扩展性设计与实现方案。

需要对性能、功能、网管/审计、报表的可扩展性进行描述。

例如：

考虑组件化设计，以使系统能够适应将来可能出现的新业务和可能出现的一些变

化。

新增业务功能时不应需要改造原软件系统，可通过动态加载新增组件的方式实现。

］

［描述系统性能设计与实现方案。

例如：

采用多种数据/对象的缓存机制；采用并发处理机制；采用异步处理方式等。

］

8.2可维护性

［描述系统可维护性设计与实现方案。

系统可维护性包括系统监控与告警、系统配置、数据备份及清理。

例如：

考虑在线修改配置信息，而不中断业务的设计机制。

］

8.3安全

［描述系统安全性设计与实现方案。

系统安全性包括网络安全、系统安全、数据安全、交曰方仝毕易安全等。

例如：

IP地址鉴权；各类数据加密机制；各类通讯加密机制；身份识别及认证等。

］

8.4容错性

［描述系统容错处理机制，以及各类错误的处理要求。

例如：

数据库双机热备容错机制；应用错误捕获及保护机制等。

］

8.5可移植性

［描述系统可移植性设计与实现方案。

例如：

应用软件对多种第三方硬件及软件的无依赖性设计等。

］

8.6可部署性

［描述系统可部署性设计与实现方案。

例如：

考虑应用及数据的加载策略，降低系统故障恢复时间等。

］

8.7

［描述未列在上述分类的产品非功能特性设计。

］

9总体约束

［本章给出设计人员与编码人员必须遵循的设计要求与编码要求，包括各种代码的命名、配置文件、日志文件格式定义。

可以通过引用的方式来写本章节。

］

9.1遵循标准

［描述本软件所遵循的标准、规范。

］

9.2文件约定

［规定系统的所有配置、日志等文件命名方式与格式。

］

9.3目录约定

［规定系统的目录结构，包括运行目录、源文件目录、配置目录、日志目录、数据目录等］

9.4对后续设计的约束

［规定后续设计中必须遵循的约束条件。

］

9.5……

［定义未列在上述分类中的总体设计约束。

］

10风险

［指明架构设计过程中遇到的或者考虑过的技术风险，说明减少潜在风险的策略，可通过列表的形式进行描述。

例如：

编号

风险

严重程度

规避措施

1

对数据库表/视图做了修改，新增多个字段、表，升级工作量大。

中

规划升级方案；

选择业务最少时段升级；

11附录

［定义需要列在架构设计文档中的附加性信息等。

］