软件工程思想(5)

System Software
 
 

图5.3  包含中间件的层次结构

5.1.2  客户机/服务器结构

让我们先回顾一下早期的电话系统。贝尔（Alexander Graham Bell）于1876年申请了电话专利。那时期的电话必须一对一对地卖，用户自己在两个电话之间拉一根线。如果一个电话用户想和其它几个电话用户通话，他必须拉n根单独的线到每个人的房子里。于是在很短的时间内，城市里到处都是穿过房屋和树木的混乱的电话线。很明显，企图把所有的电话完全互联（如图5.4（a）所示）是行不通的。

贝尔电话公司在1878年开办了第一个交换局。公司为每个客户架设一条线。打电话时，客户摇动电话的曲柄使电话公司办公室的铃响起来，操作员听到铃声以后根据要求将呼叫方和被呼叫方用跳线手工连接起来。这种集中交换式的模型如图5.4（b）所示。很快地，贝尔系统的交换局就出现在各地。人们又要求能打城市间的长途电话，就出现了二级交换局，以后进一步发展为多个二级交换局。[Tanenbaum 1998]

交换局
 
 

5.4（a）完全互联的电话系统               5.4（b）集中交换式的电话系统

如果将图5.4（b）中的电话看成是客户程序，将中心的交换局看成是服务程序，那么图5.4（b）就是典型的客户机/服务器结构。注意这里客户机和服务器都是指软件而不是指硬件（一台计算机可以放多个客户机和服务器软件）。

客户机/服务器结构存在两个显然的优点：

（1）以集中的方式高效率地管理通讯。前面讲电话系统的故事就是要说明这一点。

（2）可以共享资源。比如在信息管理系统中，服务器将信息集中起来，任何客户机都可以通过访问服务器而获得所需的信息。

客户机和服务器之间的通讯以“请求——响应”的方式进行。客户机先向服务器发起“请求”（Request），服务器再响应（Response）这个请求，如图5.5所示。

                                    请求

客户机
 
服务器
 
 

                                    响应

图5.5  Client和Server之间的通讯以“请求——响应”的方式进行

采用“请求——响应”这种通讯方式的基本动机是为了解决“聚集”（Rendezvous）问题。为了理解这一个问题，设想一个人试图在分离的机器上启动两个程序并让它们进行通讯。还需记住，计算机的运行速度要比人的操作速度高出许多数量级。在他启动第一个程序后，该程序开始执行并向对等程序发送消息。在几个微秒内，它便发现对等程序还不存在，于是就发出一条错误消息，然后退出。此后，他启动了第二个程序。不幸的是，当第二个程序开始执行时，它也找不到第一个程序（早已退出）。即使这两个程序连续地重新试着通讯，但由于它们的执行速度那么高，以致于它们在同一瞬间联系上的概率非常低。在客户机/服务器结构中，服务器在启动后必须（无限期地）等待客户机的“请求”，因此就形成了“请求——响应”的通讯方式。

　　在Inte.net/Intranet领域，目前“浏览器—Web 服务器—数据库服务器” 结构是一种非常流行的客户机/服务器结构，如图5.6所示。这种结构最大的优点是：客户机统一采用浏览器，这不仅让用户使用方便，而且使得客户机端不存在维护的问题。当然，软件开发布和维护的工作不是自动消失了，而是转移到了Web 服务器端。在Web 服务器端，程序员要用脚本语言编写响应页面。例如用Microsoft的ASP语言查询数据库服务器，将结果保存在Web 页面中，再由浏览器显示出来。

客户机

数据库

服务器
 
Web 服务器
 
 

ASP Engine
 
 

浏览器
 
                     HTTP 请求

                                                    查询

                     HTTP 响应

图5.6  “浏览器—Web 服务器—数据库服务器”结构

5.2  模 块 设 计

在设计好软件的体系结构后，就已经在宏观上明确了各个模块应具有什么功能，应放在体系结构的哪个位置。我们习惯地从功能上划分模块，保持“功能独立”是模块化设计的基本原则。因为，“功能独立”的模块可以降低开发、测试、维护等阶段的代价。但是“功能独立”并不意味着模块之间保持绝对的孤立。一个系统要完成某项任务，需要各个模块相互配合才能实现，此时模块之间就要进行信息交流。

比如手和脚是两个“功能独立”的模块。没有脚时，手照样能干活。没有手时，脚仍可以走路。但如果希望跑得快，那么迈左脚时一定要伸右臂甩左臂，迈右脚时则要伸左臂甩右臂。在设计一个模块时不仅要考虑“这个模块就该提供什么样的功能”，还要考虑“这个模块应该怎样与其它模块交流信息”。

本节将论述评价模块设计优劣的三个特征因素：“信息隐藏”、“内聚与耦合”和“封闭——开放性”。

5.2.1 信息隐藏

在一节不和谐的课堂里，老师叹气道：“要是坐在后排聊天的同学能象中间打牌的同学那么安静，就不会影响到前排睡觉的同学。”

这个故事告诉我们，如果不想让坏事传播开来，就应该把坏事隐藏起来，“家丑不可外扬”就是这个道理。为了尽量避免某个模块的行为去干扰同一系统中的其它模块，在设计模块时就要注意信息隐藏。应该让模块仅仅公开必须要让外界知道的内容，而隐藏其它一切内容。

模块的信息隐藏可以通过接口设计来实现。一个模块仅提供有限个接口（Interface），执行模块的功能或与模块交流信息必须且只须通过调用公有接口来实现。如果模块是一个C++对象，那么该模块的公有接口就对应于对象的公有函数。如果模块是一个COM对象，那么该模块的公有接口就是COM对象的接口。一个COM对象可以有多个接口，而每个接口实质上是一些函数的集合。[Rogerson 1999]

 美国也许是世界上丑闻最多的国家，因为它追求民主，不懂得“隐藏信息”。但美国又是软件产业最发达的国家，模块化设计的方法都是美国人倡导的，他们应该很懂得“隐藏信息”。真是前后矛盾，这些美国佬！

 5.2.2 内聚与耦合

     内聚（Cohesion）是一个模块内部各成分之间相关联程度的度量。耦合（Coupling）是模块之间依赖程度的度量。内聚和耦合是密切相关的，与其它模块存在强耦合的模块通常意味着弱内聚，而强内聚的模块通常意味着与其它模块之间存在弱耦合。模块设计追求强内聚，弱耦合。

一、内聚强度

内聚按强度从低到高有以下几种类型：

（1）偶然内聚。如果一个模块的各成分之间毫无关系，则称为偶然内聚。

（2）逻辑内聚。几个逻辑上相关的功能被放在同一模块中，则称为逻辑内聚。如一个模块读取各种不同类型外设的输入。尽管逻辑内聚比偶然内聚合理一些，但逻辑内聚的模块各成分在功能上并无关系，即使局部功能的修改有时也会影响全局，因此这类模块的修改也比较困难。

（3）时间内聚。如果一个模块完成的功能必须在同一时间内执行（如系统初始化），但这些功能只是因为时间因素关联在一起，则称为时间内聚。

（4）过程内聚。如果一个模块内部的处理成分是相关的，而且这些处理必须以特定的次序执行，则称为过程内聚。

（5）通信内聚。如果一个模块的所有成分都操作同一数据集或生成同一数据集，则称为通信内聚。

（6）顺序内聚。如果一个模块的各个成分和同一个功能密切相关，而且一个成分的输出作为另一个成分的输入，则称为顺序内聚。

（7）功能内聚。模块的所有成分对于完成单一的功能都是必须的，则称为功能内聚。

二、耦合强度

耦合的强度依赖于以下几个因素：（1）一个模块对另一个模块的调用；（2）一个模块向另一个模块传递的数据量；（3）一个模块施加到另一个模块的控制的多少；（4）模块之间接口的复杂程度。

耦合按从强到弱的顺序可分为以下几种类型：

（1）内容耦合。当一个模块直接修改或操作另一个模块的数据,或者直接转入另一个模块时，就发生了内容耦合。此时，被修改的模块完全依赖于修改它的模块。

（2）公共耦合。两个以上的模块共同引用一个全局数据项就称为公共耦合。

（3）控制耦合。一个模块在界面上传递一个信号（如开关值、标志量等）控制另一个模块，接收信号的模块的动作根据信号值进行调整，称为控制耦合。

（4）标记耦合。模块间通过参数传递复杂的内部数据结构，称为标记耦合。此数据结构的变化将使相关的模块发生变化。

（5）数据耦合。模块间通过参数传递基本类型的数据，称为数据耦合。

（6）非直接耦合。模块间没有信息传递时，属于非直接耦合。

如果模块间必须存在耦合，就尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，坚决避免使用内容耦合。

5.2.3 封闭——开放性

如果一个模块可以作为一个独立体被其它程序引用，则称模块具有封闭性。如果一个模块可以被扩充，则称模块具有开放性。

从字面上看，让模块具有“封闭——开放性”是矛盾的，但这种特征在软件开发过程中是客观存在的。当着手一个新问题时，我们很难一次性解决问题。应该先纵观问题的一些重要方面，同时作好以后补充的准备。因此让模块存在“开放性”并不是坏事情。“封闭性”也是需要的，因为我们不能等到完全掌握解决问题的信息后再把程序做成别人能用的模块。

模块的“封闭——开放性”实际上对应于软件质量因素中的可复用性和可扩充性。采用面向过程的方法进行程序设计，很难开发出既具有封闭性又具有开放性的模块。采用面向对象设计方法可以较好地解决这个问题。

5.3  数据结构与算法设计

学会设计数据结构与算法，可以让我们编写出高效率的程序。也许有人要问，在计算机速度日新月异的今天，为什么还需要高效率的程序？

因为我们的雄心与能力是一起增长的，技术进步最快也快不过人们欲望的增长。计算速度和存储容量上的革新仅仅提供了处理更复杂问题的有效工具，所以高效率的程序永远不会过时。

设计高效率的程序是基于良好的数据结构与算法，而不是基于编程小技巧。大多数计算机科学系在设置课程时，都重视学习基本的软件工程原理，以及数据结构与算法设计。

一般说来，数据结构与算法就是一类数据的表示及其相关的操作（这里算法不是指数值计算的算法）。从数据表示的观点来看，存储在数组中的一个有序整数表也是一种数据结构。算法是指对数据结构施加的一些操作，例如对一个线性表进行检索、插入、删除等操作。一个算法如果能在所要求的资源限制（Resource Constraints）范围内将问题解决好，则称这个算法是有效率（Efficient）的。例如一个资源限制可能是“用于存储数据的内存有限”，或者“允许执行每个子任务所需的时间有限”。一个算法如果比其它已知算法所需要的资源都少，这个算法也被称为是有效率的。算法的代价（Cost）是指消耗的资源量。一般说来，代价是由一个关键资源例如时间或空间来评估的。

毋庸置疑，人们编写程序是为了解决问题。只有通过预先分析问题来确定必须达到的性能目标，才有希望挑选出正确的数据结构。有相当多的程序员忽视了这一分析过程，而直接选用某一个他们习惯使用的，但是与问题不相称的数据结构，结果设计出一个低效率的程序。如果使用简单的设计就能够达到性能目标时，选用复杂的数据结构也是没有道理的。

人们对常用的数据结构与算法的研究已经相当透彻，可以归纳出一些设计原则：

（1）每一种数据结构与算法都有其时间、空间的开销和收益。当面临一个新的设计问题时，设计者要彻底地掌握怎样权衡时空开销和算法有效性的方法。这就需要懂得算法分析的原理，而且还需要了解所使用的物理介质的特性（例如，数据存储在磁盘上与存储在内存中，就有不同的考虑）。

（2）与开销和收益有关的是时间——空间的权衡。通常可以用更大的时间开销来换取空间的收益，反之亦然。时间——空间的权衡普遍地存在于软件开发的各个阶段中。

（3）程序员应该充分地了解一些常用的数据结构与算法，避免不必要的重复设计工作。

（4）数据结构与算法为应用服务。我们必须先了解应用的需求，再寻找或设计与实际应用相匹配的数据结构。[Shaffer 1998]

5.4  用 户 界 面 设 计

某个人总有办法让自己保持心情愉快、信心十足。有一天，他向一名围棋九段和一名乒乓球世界冠军挑战，结果他全胜了。因为他跟围棋九段打乒乓球，跟乒乓球冠军下围棋。用户界面的编程技术是人们熟悉得不得了的事，我决定讲一讲比较陌生的“用户界面设计美学”。