软件架构设计规范

需要考虑的要素：

1、需求的符合性：正确性、完整性；功能性需求、非功能性需求

软件项目最主要的目标是满足客户需求。在进行构架设计的时候，大家考虑更多的是使

用哪个运行平台、编成语言、开发环境、数据库管理系统等问题，对于和客户需求相关的问

题考虑不足、不够系统。如果无论怎么好的构架都无法满足客户明确的某个功能性需求或非

功能性需求，就应该与客户协调在项目范围和需求规格说明书中删除这一需求。否则，架构

设计应以满足客户所有明确需求为最基本目标，尽量满足其隐含的需求。（客户的非功能性

需求可能包括接口、系统安全性、可靠性、移植性、扩展性等等，在其他小节中细述）

一般来说，功能需求决定业务构架、非功能需求决定技术构架，变化案例决定构架的范

围。需求方面的知识告诉我们，功能需求定义了软件能够做些什么。我们需要根据业务上的

需求来设计业务构架，以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、

效率上的一些约束、规则。而我们的技术构架要能够满足这些约束和规则。变化案例是对未

来可能发生的变化的一个估计，结合功能需求和非功能需求，我们就可以确定一个需求的范

围，进而确定一个构架的范围。

这里讲一个前几年因客户某些需求错误造成构架设计问题而引起系统性能和可靠性问

题的小小的例子：此系统的需求本身是比较简单的，就是将某城市的某业务的全部历史档案

卡片扫描存储起来，以便可以按照姓名进行查询。需求阶段客户说卡片大约有20万张，需

求调研者出于对客户的信任没有对数据的总量进行查证。由于是中小型数据量，并且今后数

据不会增加，经过计算20万张卡片总体容量之后，决定使用一种可以单机使用也可以联网

的中小型数据库管理系统。等到系统完成开始录入数据时，才发现数据至少有60万，这样

使用那种中小型数据库管理系统不但会造成系统性能的问题，而且其可靠性是非常脆弱的，

不得不对系统进行重新设计。从这个小小的教训可以看出，需求阶段不仅对客户的功能需求

要调查清楚，对于一些隐含非功能需求的一些数据也应当调查清楚，并作为构架设计的依据。

对于功能需求的正确性，在构架设计文档中可能不好验证（需要人工、费力）。对于功

能需求完整性，就应当使用需求功能与对应模块对照表来跟踪追溯。对于非功能需求正确性

和完整性，可以使用需求非功能与对应设计策略对照表来跟踪追溯评估。

“软件设计工作只有基于用户需求，立足于可行的技术才有可能成功。”

2、总体性能

性能其实也是客户需求的一部分，当然可能是明确的，也有很多是隐含的，这里把它单

独列出来在说明一次。性能是设计方案的重要标准，性能应考虑的不是单台客户端的性能，

而是应该考虑系统总的综合性能；

性能设计应从以下几个方面考虑：内存管理、数据库组织和内容、非数据库信息、任务

并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响；

几点提示：算法优化及负载均衡是性能优化的方向。经常要调用的模块要特别注意优化。

占用内存较多的变量在不用时要及时清理掉。需要下载的网页主题文件过大时应当分解为若

干部分，让用户先把主要部分显示出来。

3、运行可管理性

系统的构架设计应当为了使系统可以预测系统故障，防患于未然。现在的系统正逐步向

复杂化、大型化发展，单靠一个人或几个人来管理已显得力不从心，况且对于某些突发事件

杨天帅

2014

的响应，人的反应明显不够。因此通过合理的系统构架规划系统运行资源，便于控制系统运

行、监视系统状态、进行有效的错误处理；为了实现上述目标，模块间通信应当尽可能简单，

同时建立合理详尽的系统运行日志，系统通过自动审计运行日志，了解系统运行状态、进行

有效的错误处理；（运行可管理性与可维护性不同）

4、与其他系统接口兼容性（解释略）

5、与网络、硬件接口兼容性及性能（解释略）

6、系统安全性

随着计算机应用的不断深入和扩大，涉及的部门和信息也越来越多，其中有大量保密信

息在网络上传输，所以对系统安全性的考虑已经成为系统设计的关键，需要从各个方面和角

度加以考虑，来保证数据资料的绝对安全。

7、系统可靠性

系统的可靠性是现代信息系统应具有的重要特征，由于人们日常的工作对系统依赖程度

越来越多，因此系统的必须可靠。系统构架设计可考虑系统的冗余度，尽可能地避免单点故

障。系统可靠性是系统在给定的时间间隔及给定的环境条件下，按设计要求，成功地运行程

序的概率。成功地运行不仅要保证系统能正确地运行，满足功能需求，还要求当系统出现意

外故障时能够尽快恢复正常运行，数据不受破坏。

8、业务流程的可调整性

应当考虑客户业务流程可能出现的变化，所以在系统构架设计时要尽量排除业务流程的

制约，即把流程中的各项业务结点工作作为独立的对象，设计成独立的模块或组件，充分考

虑他们与其他各种业务对象模块或组件的接口，在流程之间通过业务对象模块的相互调用实

现各种业务，这样，在业务流程发生有限的变化时（每个业务模块本身的业务逻辑没有变的

情况下），就能够比较方便地修改系统程序模块或组件间的调用关系而实现新的需求。如果

这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数

据字典里的模块或组件调用规则即可。

9、业务信息的可调整性

应当考虑客户业务信息可能出现的变化，所以在系统构架设计时必须尽可能减少因为业

务信息的调整对于代码模块的影响范围。

10、使用方便性

使用方便性是不须提及的必然的需求，而使用方便性与系统构架是密切相关的。WinCE

（1.0）的失败和后来改进版本的成功就说明了这个问题。WinCE（1.0）有太多层次的视窗

和菜单，而用户则更喜欢简单的界面和快捷的操作。失败了应当及时纠正，但最好不要等到

失败了再来纠正，这样会浪费巨大的财力物力，所以在系统构架阶段最好能将需要考虑的因

素都考虑到。当然使用方便性必须与系统安全性协调平衡统一，使用方便性也必须与业务流

程的可调整性和业务信息的可调整性协调平衡统一。“满足用户的需求，便于用户使用，同

时又使得操作流程尽可能简单。这就是设计之本。”

11、构架样式的一致性

杨天帅

2014

软件系统的构架样式有些类似于建筑样式（如中国式、哥特式、希腊复古式）。软件构

架样式可分为数据流构架样式、调用返回构架样式、独立组件构架样式、以数据为中心的构

架样式和虚拟机构架样式，每一种样式还可以分为若干子样式。构架样式的一致性并不是要

求一个软件系统只能采用一种样式，就像建筑样式可以是中西结合的，软件系统也可以有异

质构架样式（分为局部异质、层次异质、并行异质），即多种样式的综合，但这样的综合应

该考虑其某些方面的一致性和协调性。每一种样式都有其使用的时机，应当根据系统最强调

的质量属性来选择。

源代码的组织结构方面的考虑：

1、开发可管理性

便于人员分工（模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开

发的影响：一个好的构架同时应有助于减少项目组的压力和紧张，提高软件开发效率）、利

于配置管理、大小的合理性、适度复杂性；

1）便于人员分工－模块独立性、层次性

模块独立性、层次性是为了保证项目开发成员工作之间的相对独立性，模块联结方式应

该是纵向而不是横向,模块之间应该是树状结构而不是网状结构或交叉结构，这样就可以把

开发人员之间的通信、模块开发制约关系减到最少。同时模块独立性也比较利于配置管理工

作的进行。现在有越来越多的的软件开发是在异地进行，一个开发组的成员可能在不同城市

甚至在不同国家，因此便于异地开发的人员分工与配置管理的源代码组织结构是非常必要

的。

2）便于人员分工－开发工作的负载均衡

不仅仅是开发出来的软件系统需要负载均衡，在开发过程中开发小组各成员之间工作任

务的负载均衡也是非重要的。所谓工作任务的负载均衡就是通过合理的任务划分按照开发人

员特点进行分配任务，尽量让项目组中的每个人每段时间都有用武之地。这就需要在构架设

计时应当充分考虑项目组手头的人力资源，在实现客户需求的基础上实现开发工作的负载均

衡，以提高整体开发效率。

3）便于人员分工－进度安排优化；

进度安排优化的前提是模块独立性并搞清楚模块开发的先后制约关系。利用工作分解结

构对所有程序编码工作进行分解，得到每一项工作的输入、输出、所需资源、持续时间、前

期应完成的工作、完成后可以进行的工作。然后预估各模块需要时间，分析各模块的并行与

串行（顺序制约），绘制出网络图，找出影响整体进度的关键模块，算出关键路径，最后对

网络图进行调整，以使进度安排最优化。

有个家喻户晓的智力题叫烤肉片策略：约翰逊家户外有一个可以同时烤两块肉片的烤肉

架，烤每块肉片的每一面需要10分钟，现要烤三块肉片给饥肠辘辘急不可耐的一家三口。

问题是怎样才能在最短的时间内烤完三片肉。一般的做法花20分钟先烤完前两片，再花20

分钟烤完第三片。有一种更好的方法可以节省10分钟，大家想想。

4）便于人员分工－预防员工人员流动对开发的影响

人员流动在软件行业是司空见惯的事情，已经是一个常见的风险。作为对这一风险的有

效的防范对策之一，可以在构架设计中考虑到并预防员工人员流动对开发的影响。主要的思

路还是在模块的独立性上追求高内聚低耦合），组件化是目前流行的趋势。

5）利于配置管理（独立性、层次性）

杨天帅

2014

利于配置管理与利于人员分工有一定的联系。除了逻辑上的模块组件要利于人员分工

外，物理上的源代码层次结构、目录结构、各模块所处源代码文件的部署也应当利于人员分

工和配置管理。（尽管现在配置管理工具有较强大的功能，但一个清楚的源码分割和模块分

割是非常有好处的）。

6）大小的合理性与适度复杂性

大小的合理性与适度复杂性可以使开发工作的负载均衡，便于进度的安排，也可以使系

统在运行时减少不必要的内存资源浪费。对于代码的可阅读性和系统的可维护性也有一定的

好处。另外，过大的模块常常是系统分解不充分，而过小的模块有可能降低模块的独立性，

造成系统接口的复杂。

2、可维护性

便于在系统出现故障时及时方便地找到产生故障的原因和源代码位置，并能方便地进行

局部修改、切割；（可维护性与运行可管理性不同）

3、可扩充性：系统方案的升级、扩容、扩充性能

系统在建成后会有一段很长的运行周期，在该周期内，应用在不断增加，应用的层次在

不断升级，因此采用的构架设计等方案因充分考虑升级、扩容、扩充的可行性和便利。

4、可移植性

不同客户端、应用服务器、数据库管理系统：如果潜在的客户使用的客户端可能使用不

同的操作系统或浏览器，其可移植性必须考虑客户端程序的可移植性，或尽量不使业务逻辑

放在客户端；数据处理的业务逻辑放在数据库管理系统中会有较好的性能，但如果客户群中

不能确定使用的是同一种数据库管理系统，则业务逻辑就不能数据库管理系统中；

达到可移植性一定要注重标准化和开放性：只有广泛采用遵循国际标准，开发出开放性

强的产品，才可以保证各种类型的系统的充分互联，从而使产品更具有市场竞争力，也为未

来的系统移植和升级扩展提供了基础。

5、需求的符合性

从源代码的组织结构看需求的符合型主要考虑针对用户需求可能的变化的软件代码及

构架的最小冗余（同时又要使得系统具有一定的可扩展性）。

构架工作应该在需求开发完成约80％的时候开始进行，不必等到需求开发全部完成，

需要项目经理以具体的判断来评估此时是否足以开始构建软件构架。

给出一致的轮廓：系统概述。一个系统构架需要现有概括的描述，开发人员才能从上千

个细节甚至数十个模块或对象类中建立一致的轮廓。

构架的目标应该能够清楚说明系统概念，构架应尽可能简化，最好的构架文件应该简单、

简短，清晰而不杂乱，解决方案自然。

构架应单先定义上层的主要子系统，应该描述各子系统的任务，并提供每个子系统中各

模块或对象类的的初步列表。

构架应该描述不同子系统间相互通信的方式，而一个良好的构架应该将子系统间的通信

关系降到最低。

成功构架的一个重要特色，在于标明最可能变更的领域，应当列出程序中最可能变更的

部分，说明构架的其他部分如何应变。

复用分析、外购：缩短软件开发周期、降低成本的有效方案未必是自行开发软件，可以

杨天帅

2014

对现有软件进行复用或进行外购。应考虑其对构架的影响。

除了系统组织的问题，构架应重点考虑对于细节全面影响的设计决策，深入这些决策领

域：外部软件接口（兼容性、通信方式、传递数据结构）、用户接口（用户接口和系统层次

划分）、数据库组织和内容、非数据库信息、关键算法、内存管理（配置策略）、并行性、

安全性、可移植性、网络多人操作、错误处理。

要保证需求的可追踪性，即保证每个需求功能都有相应模块去实现。

构架不能只依据静态的系统目标来设计，也应当考虑动态的开发过程，如人力资源的情

况，进度要求的情况，开发环境的满足情况。构架必须支持阶段性规划，应该能够提供阶段

性规划中如何开发与完成的方式。不应该依赖无法独立运行的子系统构架。将系统各部分的、

依赖关系找出来，形成一套开发计划。

杨天帅

2014