2024年4月19日发(作者：)

BS架构与CS构架

第一、什么是C/S结构。

C/S（Client/Server）结构，即大家熟知的客户机和服务器结构。它是软件系统体系

结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server

端来实现，降低了系统的通讯开销。目前大多数应用软件系

统都是Client/Server形式的两层结构，由于现在的软件应用系统正在向分布式的

Web应用发展，Web和Client/Server应用都可以进行同样的业务处理，应用不同的模块

共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有

应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。

传统的C／S体系结构虽然采用的是开放模式，但这只是系统开发一级的开放性，在

特定的应用中无论是Client端还是Server端都还需要特定的软件支持。由于没能提供用

户真正期望的开放环境，C/S结构的软件需要针对不同的操作系统系统开发不同版本的软

件，加之产品的更新换代十分快，已经很难适应百台电脑以上局域网用户同时使用。而且

代价高，效率低。

第二、什么是B/S结构。

B/S（Browser/Server）结构即浏览器和服务器结构。它是随着

Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户

工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端

（Browser）实现，但是主要事务逻辑在服务器端（Server）实现，形成所谓三层3-tier

结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低

了用户的总体成本（TCO）。

以目前的技术看，局域网建立B/S结构的网络应

用，并通过Internet/Intranet模式下数据库应用，相对易于把握、成本也是较低的。

它是一次性到位的开发，能实现不同的人员，从不同的地

点，以不同的接入方式（比如LAN,WAN,Internet/Intranet等）访问和操作共同的数

据库；它能有效地保护数据平台和管理访问权限，服

务器数据库也很安全。特别是在JAVA这样的跨平台语言出现之后，B/S架构管理软

件更是方便、快捷、高效。

第三、管理软件主流技术。

管理软件技术的主流技术与管理思想一样，也经历了三个发展时期。首先，界面技术

从上世纪DOS字符界面到Windows图形界面（或图形用户界面GUI），直至Browser浏

览器界面三个不同的发展时期。其次，今天所有电脑的

浏览器界面，不仅直观和易于使用，更主要的是基于浏览器平台的任何应用软件其风

格都是一样的，使用人对操作培训的要求不高，而且软件可操作性强，易于识

别；再者，平台体系结构也从过去单用户发展到今天的文件/服务器（F/S）体系、客

户机/服务器（C/S）体系和浏览器/服务器（B/S）体系。

二、C/S和B/S之比较

C/S和B/S是当今世界开发模式技术架构的两大主流技术。C/S是美国Borland公司

最早研发，B/S是美国微软公司研发。目前，这两项技术以被世界各国所掌握，国内

公司以C/S和B/S技术开发出产品也很多。这两种技术都有自己一定的市

场份额和客户群，各家企业都说自己的管理软件架构技术功能强大、先进、方便，都

能举出各自的客户群体，都有一大群文人墨客为自己摇旗呐喊，广告满天飞，可

谓仁者见仁，智者见智。

1、C/S架构软件的优势与劣势

（1）、应用服务器运行数据负荷较轻。

最简单的C/S体系结构的数据库应用由两部分组成，即客户应用程序和数据库服务器

程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序的机器，也称为应用

服务器。一旦服务器程序被启动，就随时等待响应客户程序发来的请求；客户应用程序运

行在用户自己的电脑上，对应于数据库服务器，可称为客户电脑，当需要对数据库中的数

据进行任何操作时，客户程序就自动地寻找服务器程序，并向其发出请求，服务器程序根

据预定的规则作出应答，送回结果，应用服务器运行数据负荷较轻。

（2）、数据的储存管理功能较为透明。

在数据库应用中，数据的储存管理功能，是由服务器程序和客户应用程序分别独立进

行的，前台应用可以违反的规则，并且通常把那些不同的（不管是已知还是未知的）运行

数据，在服务器程序中不集中实现，例如访问者的权限，编号可以重复、必须有客户才能

建立定单这样的规则。所有这些，对于工作在前台程序上的最终用户，是“透明”的，他

们无须过问（通常也无法干涉）背后的过程，就可以完成自己的一切工作。在客户服务器

架构的应用中，前台程序不是非常“瘦小”，麻烦的事情都交给了服务器和网络。在C/S

体系的下，数据库不能真正成为公共、专业化的仓库，它受到独立的专门管理。

（3）、C/S架构的劣势是高昂的维护成本且投资大。

首先，采用C/S架构，要选择适当的数据库平台来实现数据库数据的真正“统一”，

使分布于两地的数据同步完全交由数据库系统去管理，但逻辑上两地的操作者要直接访问

同一个数据库才能有效实现，有这样一些问题，如果需要建立“实时”的数据同步，就必

须在两地间建立实时的通讯连接，保持两地的数据库服务器在线运行，网络管理工作人员

既要对服务器维护管理，又要对客户端维护和管理，这需要高昂的投资和复杂的技术支持，

维护成本很高，维护任务量大。

其次，传统的C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，由

于产品的更新换代十分快，代价高和低效率已经不适应工作需要。在JAVA这样的跨平台

语言出现之后，B/S架构更是猛烈冲击C/S，并对其形成威胁和挑战。

2、B/S架构软件的优势与劣势

（1）、维护和升级方式简单。

目前，软件系统的改进和升级越来越频繁，B/S架构的产品明显体现着更为方便的特

性。对一个稍微大一点单位来说，系统管理人员如果需要在几百甚至上千部电脑之间来回

奔跑，效率和工作量是可想而知的，但B/S架构的软件只需要管理服务器就行了，所有的

客户端只是浏览器，根本不需要做任何的维护。无论用户的规模有多大，有多少分支机构

都不会增加任何维护升级的工作量，所有的操作只需要针对服务器进行；如果是异地，只

需要把服务器连接专网即可，实现远程维护、升级和共享。所以客户机越来越“瘦”，而

服务器越来越“胖”是将来信息化发展的主流方向。今后，软件升级和维护会越来越容易，

而使用起来会越来越简单，这对用户人力、物力、时间、费用的节省是显而易见的，惊人

的。因此，维护和升级革命的方式是“瘦”客户机，“胖”服务器。

（2）、成本降低，选择更多。

大家都知道windows在桌面电脑上几乎一统天下，浏览器成为了标准配置，但在服

务器操作系统上windows并不是处于绝对的统治地位。现在的趋势是凡使用B/S架构的

应用管理软件，只需安装在Linux服务器上即可，而且安全性高。所以服务器操作系统的

选择是很多的，不管选用那种操作系统都可以让大部分人使用windows作为桌面操作系

统电脑不受影响，这就使的最流行免费的Linux操作系统快速发展起来，Linux除了操作

系统是免费的以外，连数据库也是免费的，这种选择非常盛行。

比如说很多人每天上“网易”（原文为新浪）网，只要安装了浏览器就可以了，并不

需要了解“网易”的服务器用的是什么操作系统，而事实上大部分网站确实没有使用

windows操作系统，但用户的电脑本身安装的大部分是windows操作系统。

（3）、应用服务器运行数据负荷较重。

由于B/S架构管理软件只安装在服务器端（Server）上，网络管理人员只需要管理服

务器就行了，用户界面主要事务逻辑在服务器（Server）端完全通过WWW浏览器实现，

极少部分事务逻辑在前端（Browser）实现，所有的客户端只有浏览器，网络管理人员只

需要做硬件维护。但是，应用服务器运行数据负荷较重，一旦发生服务器“崩溃”等问题，

后果不堪设想。因此，许多单位都备有数据库存储服务器，以防万一。

3，C/S与B/S区别

Client/Server是建立在局域网的基础上的，Browser/Server是建立在广域网的基础

上的。

（1）、硬件环境不同：C/S一般建立在专用的网络上，小范围里的网络环境，局域网

之间再通过专门服务器提供连接和数据交换服务。

B/S建立在广域网之上的，不必是专门的网络硬件环境，例如电话上网，租用设备，

信息自己管理，有比C/S更强的适应范围，一般只要有操作系统和浏览器就行。

（2）、对安全要求不同

C/S一般面向相对固定的用户群，对信息安全的控制能力很强。一般高度机密的信息

系统采用C/S结构适宜，可以通过B/S发布部分可公开信息。

B/S建立在广域网之上，对安全的控制能力相对弱，面向是不可知的用户群。

（3）、对程序架构不同

C/S程序可以更加注重流程，可以对权限多层次校验，对系统运行速度可以较少考虑。

B/S对安全以及访问速度的多重的考虑，建立在需要更加优化的基础之上。比C/S有

更高的要求，B/S结构的程序架构是发展的趋势，从MS的.Net系列的

BizTalk2000Exchange2000等，全面支持网络的构件搭建的系统。SUN和IBM推的

JavaBean构件技术等，使B/S更加成熟。

（4）、软件重用不同

C/S程序可以不可避免的整体性考虑，构件的重用性不如在B/S要求下的构件的重用

性好。

B/S对的多重结构，要求构件相对独立的功能。能够相对较好的重用。就如买来的餐

桌可以再利用，而不是做在墙上的石头桌子。

（5）、系统维护不同

系统维护是软件生存周期中，开销大，相当重要

C/S程序由于整体性，必须整体考察，处理出现的问题以及系统升级难，可能是再做

一个全新的系统。

B/S构件组成方面构件个别的更换，实现系统的无缝升级。系统维护开销减到最小，

用户从网上自己下载安装就可以实现升级。

（6）、处理问题不同

C/S程序可以处理用户面固定，并且在相同区域，安全要求高的需求，与操作系统相

关，应该都是相同的系统。

B/S建立在广域网上，面向不同的用户群，分散地域，这是C/S无法作到的，与操作

系统平台关系最小。

（7）、用户接口不同

C/S多是建立在Window平台上，表现方法有限，对程序员普遍要求较高。

B/S建立在浏览器上，有更加丰富和生动的表现方式与用户交流，并且大部分难度减

低，降低开发成本。

（8）、信息流不同

C/S程序一般是典型的中央集权的机械式处理，交互性相对低。

B/S信息流向可变化，B－B、B－C、B－G等信息流向的变化，更象交易中心.

系统构架设计应考虑的因素

作者：厦门巨龙软件工程有限公司 卢琳生

摘要：

本文从程序的运行时结构和源代码的组织结构两个方面探讨了系统构架设计应考虑的

各种因素，列举了系统构架设计文档应考虑的一些问题。

关键字：

系统构架、设计、考虑、因素

正文：

约公元前25年，古罗马建筑师维特鲁威说：“理想的建筑师应该既是文学家又是数字

家，他还应通晓历史，热衷于哲学研究，精通音乐，懂得医药知识，具有法学造诣，深谙

天文学及天文计算。”（好难哪，软件构架设计师的要求呢？大家好好想想吧。）

一、与构架有关的几个基本概念：

1、模块（module）：一组完成指定功能的语句，包括：输入、输出、逻辑处理功能、

内部信息、运行环境（与功能对应但不是一对一关系）。

2、组件（component）：系统中相当重要的、几乎是独立的可替换部分，它在明确定

义的构架环境中实现确切的功能。

3、模式（pattern）：指经过验证，至少适用于一种实用环境（更多时候是好几种环境）

的解决方案模板（用于结构和行为。在 UML 中：模式由参数化的协作来表示，但 UML 不

直接对模式的其他方面（如使用结果列表、使用示例等，它们可由文本来表示）进行建模。

存在各种范围和抽象程度的模式，例如，构架模式、分析模式、设计模式和代码模式或实

施模式。模式将可以帮助我们抓住重点。构架也是存在模式的。比如，对于系统结构设计，

我们使用层模式；对于分布式系统，我们使用代理模式（通过使用代理来替代实际的对象，

使程序能够控制对该对象的访问）；对于交互系统，我们使用MVC（M模型(对象)／V视

图(输出管理)／C控制器(输入处理)）模式。模式是针对特定问题的解，因此，我们也可以

针对需求的特点采用相应的模式来设计构架。

4、构架模式（architectural pattern）：表示软件系统的基本结构组织方案。它提供

了一组预定义的子系统、指定它们的职责，并且包括用于组织其间关系的规则和指导。

5、层（layer）：对模型中同一抽象层次上的包进行分组的一种特定方式。通过分层，

从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可

以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。（层是对构架

的横向划分，分区是对构架的纵向划分）。

6、系统分层的几种常用方法：

1） 常用三层服务：用户层、业务逻辑层、数据层；

2） 多层结构的技术组成模型：表现层、中间层、数据层；

3） 网络系统常用三层结构：核心层、汇聚层和接入层；

4） RUP典型分层方法：应用层、专业业务层、中间件层、系统软件层；

5） 基于Java的B/S模式系统结构：浏览器端、服务器端、请求接收层、请求处理

层；

6） 某六层结构：功能层（用户界面）、模块层、组装层（软件总线）、服务层（数据

处理）、数据层、核心层；

7、构架（Architecture，愿意为建筑学设计和建筑物建造的艺术与科学）: 在RUP

中的定义：软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要

构件通过接口与不断减小的构件与接口所组成的构件进行交互；《软件构架实践》中的定义：

某个软件或者计算系统的软件构架即组成该系统的一个或者多个结构，他们组成软件的各

个部分，形成这些组件的外部可见属性及相互间的联系；IEEE 1471-2000中的定义：the

fundamental organization of a system emboided in its components,their

relationships to each other,and to the enviroment and the principles guiding its

design and evolution，构架是系统在其所处环境中的最高层次的概念。软件系统的构架

是通过接口交互的重要构件（在特定时间点）的组织或结构，这些构件又由一些更小的构

件和接口组成。（“构架”可以作为名词，也可作为动词，作为动词的“构架”相当于“构

架设计”）

8、构架的描述方式：“4＋1”视图（用例视图、设计视图、实现视图、过程视图、配

置视图）是一个被广为使用的构架描述的模型；RUP过程的构架描述模板在“4＋1”视图

的基础上增加了可选的数据视图（从永久性数据存储方面来对系统进行说明）；HP公司的

软件描述模板也是基于“4＋1”视图。

9、结构：软件构架是多种结构的体现，结构是系统构架从不同角度观察所产生的视图。

就像建筑物的结构会随着观察动机和出发点的不同而有多种含义一样，软件构架也表现为

多种结构。常见的软件结构有：模块结构、逻辑或概念结构、进程或协调结构、物理结构、

使用结构、调用结构、数据流、控制流、类结构等等。

二、构架设计应考虑的因素概揽：

模块构架设计可以从程序的运行时结构和源代码的组织结构方面考虑。

1、程序的运行时结构方面的考虑：

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

2） 总体性能（内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多

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

3） 运行可管理性：便于控制系统运行、监视系统状态、错误处理；模块间通信的简

单性；与可维护性不同；

4） 与其他系统接口兼容性；

5） 与网络、硬件接口兼容性及性能；

6） 系统安全性；

7） 系统可靠性；

8） 业务流程的可调整性；

9） 业务信息的可调整性

10） 使用方便性

11） 构架样式的一致性

注：运行时负载均衡可以从系统性能、系统可靠性方面考虑。

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

1） 开发可管理性：便于人员分工（模块独立性、开发工作的负载均衡、进度安排优

化、预防人员流动对开发的影响）、利于配置管理、大小的合理性与适度复杂性；

2） 可维护性：与运行可管理性不同；

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

4） 可移植性：不同客户端、应用服务器、数据库管理系统；

5） 需求的符合性（源代码的组织结构方面的考虑）。

三、程序的运行时结构方面的考虑：

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

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

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

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

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

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

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

细述）

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

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

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

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

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

一个需求的范围，进而确定一个构架的范围。（此段From林星）

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

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

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

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

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

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

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

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

户的功能需求要调查清楚，对于一些隐含非功能需求的一些数据也应当调查清楚，并作为

构架设计的依据。

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

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

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

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

2、总体性能

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

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

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

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

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

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

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

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

3、运行可管理性

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

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

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

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

可能简单，同时建立合理详尽的系统运行日志，系统通过自动审计运行日志，了解系统运

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

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

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

6、系统安全性

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

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

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

7、系统可靠性

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

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

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

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

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

8、业务流程的可调整性

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

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

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

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

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

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

只需修改数据字典里的模块或组件调用规则即可。

9、业务信息的可调整性

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

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

10、使用方便性

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

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

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

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

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

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

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

11、构架样式的一致性

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

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

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

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

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

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

统最强调的质量属性来选择。

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

1、开发可管理性

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

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

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

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

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

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

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

管理工作的进行。现在有越来越多的的软件开发是在异地进行，一个开发组的成员可能在

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

非常必要的。

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

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

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

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

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

的负载均衡，以提高整体开发效率。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

分割是非常有好处的）。

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

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

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

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

立性，造成系统接口的复杂。

2、可维护性

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

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

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

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

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

4、可移植性

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

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

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

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

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

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

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

5、需求的符合性

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

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

五、写系统构架设计文档应考虑的问题

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

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

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

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

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

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

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

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

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

信关系降到最低。

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

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

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

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

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

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

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

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

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

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

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

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

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

六、结语

系统构架设计和千差万别的具体的开发平台密切相关，因此在此无法给出通用的解决

方案，主要是为了说明哪些因素是需要考虑的。对于每个因素的设计策略和本文未提到的

因素需要软件构架设计师在具体开发实践中灵活把握。不同因素之间有时是矛盾的，构架

设计时需要根据具体情况进行平衡。

参考文献

《软件构架实践》SEI软件工程译丛，林·巴斯著

《微软项目：求生法则》Steve McConnell著，余孟学译

《实用软件工程》第二版，郑人杰、殷人昆、陶永雷等著

《软件工程：实践者的研究方法》（第5版）Roger an著

《软件开发的科学与艺术》陈宏刚等著