第五章 系 统 设 计

第五章 系 统 设 计

系统设计是把需求转化为软件系统的最重要的环节。系统设计的优劣在根本上决定了软

件系统的质量。就象“一切帝国主义都是纸老虎”那样可以断定“差的系统设计必定产生差

的软件系统。”所以我们要努力保证系统设计“根正苗红”，把一切左倾、右倾的设计思潮消

灭在萌芽状态。

Windows NT的一位系统设计师拥有8辆法拉利跑车，让Microsoft公司的一些程序员

十分眼红。但你只能羡慕而不能愤恨，因为并不是每个程序员都有本事成为复杂软件系统的

设计师。系统设计要比纯粹的编程困难得多。即便你清楚客户的需求，却未必知道应该设计

什么样的软件系统——既能挣最多的钱又能让客户满意。“天下西湖三十六，最美是杭州”，

千年前苏东坡大学士对西湖精采绝伦的系统设计，使杭州荣升为“天堂”，让后人只剩下赞

叹和破坏的份了。

本章讲述系统设计的四方面内容：体系结构设计、模块设计、数据结构与算法设计、用

户界面设计。如果将软件系统比喻为人体，那么：

（1）体系结构就如同人的骨架。如果某个家伙的骨架是猴子，那么无论怎样喂养和美容，

这家伙始终都是猴子，不会成为人。

（2）模块就如同人的器官，具有特定的功能。人体中最出色的模块设计之一是手，手只有

几种动作，却能做无限多的事情。人体中最糟糕的模块设计之一是嘴巴，嘴巴将最有价值但

毫无相干的几种功能如吃饭、说话、亲吻混为一体，使之无法并行处理，真乃人类之不幸。

（3）数据结构与算法就如同人的血脉和神经，它让器官具有生命并能发挥功能。数据结构

与算法分布在体系结构和模块中，它将协调系统的各个功能。人的耳朵和嘴巴虽然是相对独

立的器官，但如果耳朵失聪了，嘴巴就只能发出“啊”“呜”的声音，等于丧失了说话的功

能（所以聋子天生就是哑巴），可人们却又能用手势代替说话。人体的数据结构与算法设计

真是十分神奇并且十分可笑。

（4）用户界面就如同人的外表，最容易让人一见钟情或一见恶心。象人类追求心灵美和外

表美那样，软件系统也追求（内在的）功能强大和（外表的）界面友好。但随着生活节奏的

加快，人们已少有兴趣去品味深藏不露的内在美。如果把Unix系统比作是健壮的汉子和妇

人，那么Windows系统就象妩媚的小白脸和狐狸精。想不到Windows系统竟然能兴风作浪，

占去大半市场。有鉴于此，我们应该鼓励女士多买化妆品（男士付钱）以获得更好的界面。

在进行系统设计时，我们要深情地关注软件的质量因素，如正确性与精确性、性能与效

率、易用性、可理解性与简法性、可复用性与可扩充性等等。即使把系统设计做好了，也并

不意味着就能产生好的软件系统。在程序设计、测试、维护等环节还要做大量的工作，无论

哪个环节出了差错，都会把好事搞砸了。据说上帝把所有的女士都设计成天使，可是天使们

在下凡时有些双脚先着地，有些脸先着地。上帝的这一疏忽让很多女孩伤透了心。我们在开

发软件时，一定要吸取这个教训。

5.1 体系结构设计

杨叔子院子曾这样指点其弟子：

文学中有科学，音乐中有数学，漫画中有现代数学的拓扑学。漫画家可以“几笔”就把

一个人画出来，不管怎么美化或丑化，就是活像。为什么？因为那“几笔”不是别的，而是

拓扑学中的特征不变量，这是事物最本质的东西。

 

体系结构是软件系统中最本质的东西：

（1）体系结构是对复杂事物的一种抽象。良好的体系结构是普遍适用的，它可以高效地处

理多种多样的个体需求。一提起“房子”，我们的脑中马上就会出现房子的印象（而不是地

洞的印象）。“房子”是人们对住宿或办公环境的一种抽象。不论是办公楼还是民房，同一类

建筑物（甚至不同类的建筑物）之间都具有非常相似的体系结构和构造方式。如果13亿中

国人民每个人都要用特别的方式构造奇异的房子，那么960万平方公里的土地将会变得千疮

百孔，终日不得安宁。

（2）体系结构在一定的时间内保持稳定。只有在稳定的环境下，人们才能干点事情，社会

才能发展。科学告诉我们，宇宙间万物无时无刻不在运动、飞行。由于我们的生活环境在地

球上保持相对稳定，以致于我们可以无忧无虑地吃饭和睡觉，压根就意识不到自己是活生生

的导弹。软件开发最怕的就是需求变化，但“需求会发生变化”是个无法逃避的现实。人们

希望在需求发生变化时，最好只对软件做些皮皮毛毛的修改，可千万别改动软件的体系结构。

就如人们对住宿的需求也会变动，你可以经常改变房间的装璜和摆设，但不会在每次变动时

都要去折墙、拆柱、挖地基。如果当需求发生变化时，程序员不得不去修改软件的体系结构，

那么这个软件的系统设计是失败的。

良好的体系结构意味着普适、高效和稳定。本节将论述两种非常通用的软件体系结构：

层次结构和客户机/服务器（Client/Server）结构。

5.1.1 层次结构

层次结构表达了这么一种常识：有些事情比较复杂，我们没法一口气干完，就把事情分

为好几层，一层一层地去做。高层的工作总是建立在低层的工作之上。层次关系主要有两种：

上下级关系和顺序相邻关系。

一、上下级关系的层次结构

我们从小学一直读到博士研究生毕业，要读20多年，可以分为五个层次。而范进的知

识结构只有两层：“私塾”和“秀才”，但读了五十多年，如图5.1所示。一般地处于较高层

次的学生应该懂得所有低层次的知识，而处于低层次学生无法懂得所有高层次的知识。图

5.1的层次结构存在上下级关系，如同在军队中，上级可以命令下级，而下级不能命令上级。

如果把图5.1的层次结构当成是一个软件系统的结构，那么上层子系统可以使用下层子系统

的功能，而下层子系统不能够使用上层子系统的功能。

二、顺序相邻关系的层次结构

顺序相邻关系的层次结构表明通讯只能在相邻两层之间发生，信息只能被一层一层地顺

序传递。这种层次结构的经典之作是计算机网络的OSI参考模型，如图5.2所示。为了减少

设计的复杂性，大多数网络都按层（Layer）或级（Level）的方式组织。每一层的目的都是

向它的上一层提供一定的服务，而把如何实现这一服务的细节对上一层加以屏蔽。一台机器

上的第n层与另一台机器上的第n层进行对话。通话的规则就是第n层的协议。数据不是从

一台机器的第n层直接传送到另一台机器的第n层。发送方把数据和控制信息逐层向下传递。

最低层是物理介质，它进行实际的通讯。接收方则将数据和控制信息逐层向上传递。

每一对相邻层之间都有接口。接口定义了下层提供的原语操作和服务。当网络设计者在

决定一个网络应包含多少层，每一层应当做什么的时候，其中很重要的工作是在相邻层之间

定义清晰的接口。接口可以使得同一层能轻易地用某一种实现（Implementation）来替换另

一种完全不同的实现（如用卫星信道来代替所有的电话线），只要新的实现能向上层提供同

一组服务就可以了。[Tanenbaum 1998]

 

考上“举人”时已五十多岁了

复习报考“举人”用了几十年

图5.1（a）从小学读到博士存在的五个学习阶段 图5.1（b）范进的知识结构

图5.2 计算机网络的OSI参考模型

三、其它的层次结构

目前在大型商业应用软件系统中还流行一种包含中间件（Middleware）的层次结构，如

图5.3所示[Jacobson 1997]。中间件支持与平台无关的分布式计算，可以用DCOM和CORBA

对象来实现。

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

5.1.2 客户机/服务器结构

テキスト ボックス: ? 士（2-3年）テキスト ボックス: 本 科（4年）テキスト ボックス: 秀才テキスト ボックス: 中 学（6年）テキスト ボックス: 私 塾テキスト ボックス: 博 士（3-4年）テキストボックス: ?人テキスト ボックス: ?用?テキスト ボックス: ?用?テキストボックス: 表示?テキスト ボックス: 表示?テキスト ボックス: 会??テキスト ボックス: 主

机

A

テキスト ボックス: 会??テキスト ボックス: ???テキスト ボックス: ???テキスト ボックス: 主

机

B

テキスト ボックス: 网??テキスト ボックス: 网??テキスト ボックス: 数据?路?テキスト ボックス: 数据?路?テキスト ボックス: 物理?テキスト ボックス: 物理?テキストボックス: Middlewareテキスト ボックス: Application Systemsテキスト ボックス: Business-specific Componentsテキストボックス: System Software

让我们先回顾一下早期的电话系统。贝尔（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）问

题。为了理解这一个问题，设想一个人试图在分离的机器上启动两个程序并让它们进行通讯。

还需记住，计算机的运行速度要比人的操作速度高出许多数量级。在他启动第一个程序后，

该程序开始执行并向对等程序发送消息。在几个微秒内，它便发现对等程序还不存在，于是

就发出一条错误消息，然后退出。此后，他启动了第二个程序。不幸的是，当第二个程序开

始执行时，它也找不到第一个程序（早已退出）。即使这两个程序连续地重新试着通讯，但

由于它们的执行速度那么高，以致于它们在同一瞬间联系上的概率非常低。在客户机/服务

器结构中，服务器在启动后必须（无限期地）等待客户机的“请求”，因此就形成了“请求

テキスト ボックス: 交?局テキスト ボックス: 服?器テキスト ボックス: 客?机

——响应”的通讯方式。

在Internet/Intranet领域，目前“浏览器—Web 服务器—数据库服务器” 结构是一种非

常流行的客户机/服务器结构，如图5.6所示。这种结构最大的优点是：客户机统一采用浏览

器，这不仅让用户使用方便，而且使得客户机端不存在维护的问题。当然，软件开发布和维

护的工作不是自动消失了，而是转移到了Web 服务器端。在Web 服务器端，程序员要用

脚本语言编写响应页面。例如用Microsoft的ASP语言查询数据库服务器，将结果保存在

Web 页面中，再由浏览器显示出来。

HTTP 请求

查询

HTTP 响应

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

5.2 模 块 设 计

在设计好软件的体系结构后，就已经在宏观上明确了各个模块应具有什么功能，应放在

体系结构的哪个位置。我们习惯地从功能上划分模块，保持“功能独立”是模块化设计的基

本原则。因为，“功能独立”的模块可以降低开发、测试、维护等阶段的代价。但是“功能

独立”并不意味着模块之间保持绝对的孤立。一个系统要完成某项任务，需要各个模块相互

配合才能实现，此时模块之间就要进行信息交流。

比如手和脚是两个“功能独立”的模块。没有脚时，手照样能干活。没有手时，脚仍可

以走路。但如果希望跑得快，那么迈左脚时一定要伸右臂甩左臂，迈右脚时则要伸左臂甩右

臂。在设计一个模块时不仅要考虑“这个模块就该提供什么样的功能”，还要考虑“这个模

块应该怎样与其它模块交流信息”。

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

——开放性”。

5.2.1 信息隐藏

在一节不和谐的课堂里，老师叹气道：“要是坐在后排聊天的同学能象中间打牌的同学

那么安静，就不会影响到前排睡觉的同学。”

这个故事告诉我们，如果不想让坏事传播开来，就应该把坏事隐藏起来，“家丑不可外

扬”就是这个道理。为了尽量避免某个模块的行为去干扰同一系统中的其它模块，在设计模

块时就要注意信息隐藏。应该让模块仅仅公开必须要让外界知道的内容，而隐藏其它一切内

容。

模块的信息隐藏可以通过接口设计来实现。一个模块仅提供有限个接口（Interface），执

行模块的功能或与模块交流信息必须且只须通过调用公有接口来实现。如果模块是一个C++

对象，那么该模块的公有接口就对应于对象的公有函数。如果模块是一个COM对象，那么

该模块的公有接口就是COM对象的接口。一个COM对象可以有多个接口，而每个接口实

质上是一些函数的集合。[Rogerson 1999]

美国也许是世界上丑闻最多的国家，因为它追求民主，不懂得“隐藏信息”。但美国又

是软件产业最发达的国家，模块化设计的方法都是美国人倡导的，他们应该很懂得“隐藏信

テキスト ボックス: 数据?

服?器

テキスト ボックス: Web 服?器テキスト ボックス: 客?机

テキスト ボックス: ASP Engine

テキスト ボックス: ??器

 

息”。真是前后矛盾，这些美国佬！

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 用 户 界 面 设 计

 

某个人总有办法让自己保持心情愉快、信心十足。有一天，他向一名围棋九段和一名乒

乓球世界冠军挑战，结果他全胜了。因为他跟围棋九段打乒乓球，跟乒乓球冠军下围棋。用

户界面的编程技术是人们熟悉得不得了的事，我决定讲一讲比较陌生的“用户界面设计美

学”。

有位爱好书画的博士后请我欣赏钢琴演奏会。我从头到尾只听到“叮叮咚咚”的声音，

实在享受不到“高雅”，就请这位朋友指点。他虽然也不懂钢琴，却从欣赏书法的角度设法

解释如何欣赏音乐。可是我既不懂书法也不懂音乐，真是坐立不安。“美”似乎真的不可言

传。我在读本科时，特别喜欢编写用户界面程序，并且常向同学演示、卖弄。我觉得还不过

瘾，就写了一篇“用户界面设计美学”的短文[林锐 1997]。凡是路过我实验室的同学都被我

逮住，被迫听完我得意之极的朗读，茫然者与痛苦者居多。不久我的朗读便所向披糜，闻声

者逃之夭夭。现在我又把那篇短文摘录至此，请您忍着点吧。

5.4.1 界面设计中美的需求与导向作用

人们对美的向往和追求是与生俱有的。显然没有人愿意丑化自己的程序，也没有用户嗜

好丑陋的界面。软件开发者要设计美，用户要享受美，所以界面的美是开发者与用户的共同

需求。

界面美的概念很抽象，以致让人无法说清楚什么是界面的美。但它同时又很现实，以致

人人都可以去欣赏和感受界面美，并且挑剔美中之不足。美学不是一种量化的学问，如果因

此而轻视美学指导，必将导致在设计过程中光依赖程序员个人的经验与感觉。由于程序员接

受的教育主要是如何使计算机完成工作，而不是人如何工作，因此仅靠程序员主观想象设计

而成的界面往往得不到大众用户的认可。

美的界面能消除用户由感觉引起的乏味、紧张和疲劳（情绪低落），大大提高用户的工

作效率，从而进一步为发挥用户技能和为用户完成任务作出贡献。从人机界面发展历史与趋

势上可以看出人们对界面美的需求，以及美在界面设计中的导向作用。

界面设计已经经历了两个界限分明的时代。第一代是以文本为基础的简单交互，如常见

的命令行，字符菜单等。由于第一代界面考虑人的因素太少，用户兴趣不高。随着技术的发

展，出现了第二代直接操纵的界面。它大量使用图形、语音和其它交互媒介，充分地考虑了

人对美的需求。直接操纵的界面使用视听、触摸等技术，让人可以凭借生活常识、经历和推

理来操纵软件，愉快地完成任务。更高层次的界面甚至模拟了人的生活空间，例如虚拟现实

环境。

界面的美充分体现了人机交互作用中人的特性与意图，越来越多的用户将通过具有吸引

力而令人愉快的人机界面与计算机打交道。

5.4.2 界面美的内涵

本节从合适性、风格和广义美三个方面论述界面美的内涵。

一、界面的合适性

界面的合适性是指界面是否与软件功能相融洽。如果界面不适合于软件的功能，那么界

面将毫无用处，界面美的内涵就无从谈起。所以界面的合适性是界面美的首要因素，它提醒

设计者不要片面追求外观漂亮而导致失真或华而不实。界面的合适性既提倡外美内秀，又强

调恰如其分。

合适性差的界面无疑会混淆软件意图，致使用户产生误解。即使它不损害软件功能与性

能，也会使用户产生不该有的情绪波动。例如一些软件开发者喜欢为其作品加一段动画演示，

以便吸引更多用户的关注。这本是无可非议的，问题在于这演示是否合情合理。如果运行一

 

个程序，它首先表演一套复杂的动画，在后台演奏雄壮的进行曲，电闪雷鸣之后出来的却是

一个普通的文本编辑器。整个过程让用户置身于云里雾里，而结果却让用户感到惊谔而不是

惊喜。合适性差的界面只会给软件带来厄运。

二、界面的风格

界面的风格有两类，一是“一致性”，二是“个性化”。

商业应用软件的界面设计注重一致性。设计者必须密切注意在相同应用领域中最流行的

软件的界面，必须尊重用户使用这些软件的习惯。例如商业软件习惯于设置F1键为帮助热

键，如果某个设计者别出心裁地让F1键成为程序终止的热键，那么在用户渴望得到帮助而

伸手击F1键的一刹那，他的工作就此完蛋。相信这个用户“一朝被蛇咬，十年怕井绳”。

目前流行的软件开发工具如Visual C++、Visual Basic、Delphi、C++ Builder、Power Builder

等，都能够快速地开发出非常相似的图形用户界面。在Internet/Intranet领域，浏览器几乎成

了唯一的客户机程序，因为用户希望用完全一致的软件来完成千变万化的应用任务。

在娱乐领域的软件中，有个性化的界面自然比泯然于众的界面更具有吸引力。一般说来，

计算机专业人员玩过的软件不计其数。界面看多了，真有种“曾经沧海难为水”的感觉。不

过当我看到一个叫Sonique的放音乐的软件时，不禁对其界面的创意啧啧称赞，忍不住象贴

美女像那样把它贴到书中，如图5.7所示。

图5.7 Sonique软件的几种界面

人们经常搞不清楚什么情况下应该追求“一致性”或“个性化”。在大白天，当人们都

穿戴整齐时，有些人喜欢只挂几片遮羞布。而当大家都赤条条地在共公浴室洗澡时，却也有

人喜欢穿着衣服。

三、界面的广义美

尽管界面的美并没有增加软件的功能与性能，却又是必为可少的。用户使用界面时，除

了直接的感官美感外，还有很大一部分美感是间接的，它们存在于人们的使用体验中，例如

方便，实用等。与图形用户界面相比，命令行是最原始的界面，它难记又难看。但对于熟练

 

的用户而言，他们乐于使用命令行以获得高效率。命令行因具有高效率而赢得了专业人士的

喜爱，早期的Unix系统就是彻头彻尾的命令系统。可以说，一切有利于人机交互的界面设

计因素都具有广义美。

界面设计的一些特殊考虑也体现了广义美，如设法使残障人也可以使用软件。IBM公

司在1985年已经创建了残障人国家支持中心。Apple公司的专门教育办公室则提供了一些

有利于残障人使用的计算机信息产品。

5.5 系统设计示例

——支持协同工作的交互式三维图形软件开发系统

本节论述“支持协同工作的交互式三维图形软件开发系统”的系统设计，作为本章的示

例（ 取材于作者的博士论文工作[林锐 2000]）。

5.5.1 设计背景

图形标准在图形领域有着重要的地位，它不仅加速了3D应用程序的开发，而且使3D

应用程序的可移植性更好。历史上曾出现的图形标准（或API）有Core、GKS、PHIGS、PEX、

GL、Dore、RenderMan、Hoops、OpenGL等等。经过竞争与淘汰，目前OpenGL成为国际

上公认的3D图形工业标准，在Unix与PC平台得到广泛应用。OpenGL提供了数百个库函

数，可以方便地绘制具有真实感的3D图形。但是在开发交互式的3D图形应用程序时，图

形的绘制只是一部分工作，更多的工作集中在场景数据结构、图形对象、三维交互和图形用

户界面的设计上。

由于OpenGL与窗口系统无关，不提供任何交互手段，必须由程序员自己编写所有的交

互功能。并且OpenGL 的编程接口是低级的C函数，不提供可复用的对象库或者应用程序

框架，开发效率不高。为了克服这些困难，人们往往在图形标准之上再建立更高级的开发工

具(3D Toolkit或3D Engine)。基于OpenGL的著名的开发工具有Open Inventor、IRIS

Performer、Optimeizer/Cosmo3D以及GLUT等等。Open Inventor被誉为是交互式3D开发

工具的“事实标准”，但显然没有一个3D开发工具能满足所有的应用需求，3D的广泛应用

需要更多的开发工具支持。

随着计算机图形技术与网络技术的迅猛发展，两者的结合势在必行。在商业、科研、教

育、娱乐等领域，用于分布式虚拟环境（Distributed Virtual Environments, DVEs）和计算机

支持协同工作（Computer Supported Cooperative Work, CSCW）的图形系统已成为研究与应

用的热点。著名的DVEs系统有DIVE、dVS、MR、Repo-3D等。但是这些DVEs系统缺乏

3D开发工具的交互式图形功能以及通用性，而通用的3D开发工具如Open Inventor则又不

支持分布式计算和协同工作。由于在窗口系统、图形支撑库、编程语言等方面存在差异，上

述DVEs系统和3D开发工具难以方便地结合使用。

我们多方面分析了3D需求及软硬件条件，研制完成运行于PC平台，支持协同工作的

交互式三维图形软件开发系统，如图5.8所示。其中：

（1）Intra3D 2.0是基于OpenGL的通用交互式三维图形软件开发工具，可用于快速开发

Window 9x/NT下的交互式三维图形应用软件。

（2）CNC 1.0是支持协同工作的网络通讯开发系统（Cooperative Network Communicator），

其核心是支持“发布—订阅模式”与“组播模式”的服务器与API。

结合Intra3D 2.0和CNC 1.0，可以快速开发支持协同工作的交互式三维图形应用软件。

テキスト ボックス: 支持?同工作的网?通???系?

CNC 1.0

テキスト ボックス: 通用交互式三??形?件??工具

Intra3D 2.0

 

图5.8 支持协同工作的交互式三维图形软件开发系统

5.5.2 通用交互式三维图形软件开发工具 Intra3D 2.0

Intra3D 2.0的核心是集成了场景数据结构、图形对象、三维交互算法和图形用户界面的

C++类库与COM（Component Object Model）对象库，支持Visual C++、Visual Basic、Delphi

等语言的应用编程。Intra3D的核心库分四层创建：

（1）第一层为“基础对象与函数”（Basic Objects and Functions）；

（2）第二层为“图形对象”（Graphical Objects）；

（3）第三层为“场景图与节点”（Scene Graph and Nodes）；

（4）第四层为“绘制与交互”（Rendering and Interaction）。

体系结构如图5.9所示，其中高层构件可以引用低层构件，但低层构件不能引用高层构件。

图5.9 Intra3D 2.0 的体系结构

Intra3D 2.0是免费软件，有配套书籍《交互式三维图形技术与程序设计》。标准版软件

约25兆，核心库7万多行C++代码全部公开，用户可以方便地修改内核以适应不同的需求。

5.5.2.1 主要模块和功能

一、基础对象与函数层

（1）定义了用于对象引用计数的内存管理基类；

（2）矢量、矩阵与四元组运算，鼠标跟踪球算法；

（3）点阵字体与三维矢量字体输出，常用于数据可视化图形的数据标注；

（4）图像输入输出以及纹理映射，支持BMP、GIF、JPEG、SGI、TGA等图像格式；

（5）常用几何图元的绘制，如锥、柱、球、环等，并支持Swept形体，螺旋体的绘制；

（6）提供450余种材质，在第四层中可以交互式编辑这些材质。

二、图形对象层

图形对象能将数据转化为几何模型并可以绘制出来。Intra3D 2.0版提供了三类图形对

象：

（1）常用几何对象，如长方体、锥体、圆柱体、球体、圆环体、Swept形体等；

（2）多边形模型对象，可用于绘制Autodesk公司.3ds模型和Wavefront公司的.obj模型；

（3）商业统计图形对象，如柱形图、带状图、条形图、折线图、面积图、饼图、塔形图、

曲线图、曲面图、进程图、股票图等。

テキスト ボックス: 4、 ?制与交互?テキスト ボックス: Intra3D

COM

?

テキスト ボックス: Intra3D

C++

??

テキスト ボックス: 3、 ?景的?与?点?テキスト ボックス: 2、 ?形?象?テキスト ボックス: 1、 基??象与函数?テキスト ボックス: Window 9x/NT + OpenGL + Visual C++

图形对象的开发与应用问题密切相关，用户可以使用继承方法扩充新的图形对象，而不

会影响到其它三层的构件。

三、场景图与节点

场景图（Scene Graph）是有向无环图，Scene Graph的主要节点有：（1）SceneNode是

所有节点的基类。在SceneNode中定义了局部坐标系以及相应的图形变换，这样便于第四

层以同样的操作方式实现三维交互。（2）相机节点（CameraNode）支持平行投影与透视投

影，支持多个相机切换。（3）光源节点有三种：平行光源节点(DirLightNode)、点光源节点

(PointLightNode)和锥光源节点(SpotLightNode)。（4）形体节点（ShapeNode）用于引用图形

对象，有关图形对象的三维交互均由ShapeNode处理。

四、绘制与交互层

Intra3D的交互分两类：一类是对形体、光源和相机的直接操作，另一类是真实感属性

的编辑。Intra3D的场景视图构件（SceneView）封装了交互式绘制的所有细节，如消息处理、

场景节点的遍历绘制、多重采样消锯齿、鼠标交互等。为了便于编辑真实感属性，Intra3D

定制了一些常用对话：矢量字体对话（FontDialog）、颜色对话（ColorDialog）、材质库对话

（MaterialLibDialog）、材质对话（MaterialDialog）与光源对话（DirLightDialog,

PointLightDialog, SpotLightDialog）。

5.5.2.2 用户界面设计

Intra3D的场景视图构件SceneView用于快速创建交互式3D应用程序的主界面。

SceneView支持selecting、scaling、rotating、translating、creating、deleting等三十余种操作，

并提供工具条方便于交互，如图5.10所示。

为了编辑真实感属性，常需在对话框中绘制3D 图形。Microsoft的窗口系统不提供3D

的对话窗口。使用Intra3D的Window3D构件可在对话框中创建多个3D视图，图5.11的材

质对话和图5.12的材质库对话都使用了Window3D构件。颜色编辑是3D图形程序中最常

用的交互，材质与光源的编辑实际上是通过改变颜色分量来实现的。需要进行颜色编辑的交

互均涉及HSV与RGB模式的颜色转换。Intra3D的“绘制与交互层”实现了这些计算，并

且提供彩色的滑动条用于鼠标交互。图5.13、图5.14分别为点光源对话和颜色对话。

图5.10 用于直接操作的三维交互工具条

图5.11 材质对话 图5.12 材质库对话

 

图5.13 点光源对话 图5.14 颜色对话

5.5.3 支持协同工作的网络通讯开发系统 CNC 1.0

最简单的协同工作模式是让两个客户机直接通讯，可以用Socket编程实现。假设有 n 个

客户机参加协同工作，每个客户机将与所有其它的客户机通讯。那么总共存在n(n-1)/2 个

Socket直接通讯，并且每个客户机的变动将导致其它客户机的修改。这种Socket直接通讯

使得协同工作的管理和客户机的程序设计变得非常困难。CNC系统提供了支持“发布—订

阅（Publish-Subscribe）”与“组播（Multicast）” 模式的服务器与API，可以高效地管理多

个组群的协同工作，并使得客户机的程序设计十分简单。CNC 1.0的系统结构如图5.15所

示。

CNC 服务器将客户机分组管理。在“发布—订阅”模式中，将产生数据的进程称为生

产者（Producer），将接受数据的进程称为消费者（Consumer）。生产者可以向服务器发布数

据，服务器保存这些数据。消费者可以向服务器订阅数据。每个客户机可能是很多数据的生

产者或消费者。同一时刻，CNC系统允许有任意多个生产者和消费者存在。CNC的“发布

—订阅” 功能是用TCP协议实现的。

在“组播” 模式中，服务器动态地分配每个组的组播地址。客户机可以向服务器申请

加入任意组，允许向任意组播放消息，服务器不保存这些组播消息。CNC的“组播”功能

是用UDP协议实现的。

图5.15 CNC 1.0 的系统结构

5.5.3.1 CNC 客户机的API设计

类CNCClient客户机用来实现“发布—订阅”和“组播”功能，主要接口（公有函数）

テキスト ボックス: CNC

客?机

テキスト ボックス: CNC

服?器

テキスト ボックス: CNC APIテキスト ボックス: 基于TCP??的

?布???模式

テキスト ボックス: 基于UDP??的

?播模式

 

如下：

class CNCClient

{ public:

BOOL Connect(…); // 连接服务器

BOOL Disconnect(); // 与服务器断开连接

BOOL PublishData(…); // 向服务器发布数据

BOOL QueryData(…); // 向服务器查询数据

BOOL SubscribeData(…); // 向服务器订阅数据

GROUPIP QueryGroupIP(…); // 向服务器查询组播地址

DWORD MulticastMessage(…); // 发送组播消息

virtual void MessageResponse(…);// 响应组播消息

…

};

一、客户程序的“发布”协议

客户机向服务器发布的每个数据报均含有数据类型、工作组名称、数据名称、生命期和

数据长度的信息。报文格式如图5.16所示，数据结构见 DataPublish ：

struct DataPublish

{

BYTE iDataType; // 2 个字节数据类型，宏定义为DATA_PUBLISH

char strGroupName[16]; // 16个字节的工作组名字

char strDataName[16]; // 16个字节的数据名字

DWORD dwLifeTime; // 4 个字节的数据生命期，以秒为单位

DWORD dwLength; // 4 个字节的数据内容的长度

char *pchContent; // 数据内容

};

2字节 16字节 16字节 4字节 4字节

图5.16 用于发布的报文格式

二、客户程序的“订阅”协议

客户机向服务器订阅数据分两步实现：

（1）先调用函数QueryData向服务器发送一个 DataQuery格式的报文，用于查询要订阅的

数据是否存在。

struct DataQuery

{

BYTE iDataType; // 2 个字节数据类型，宏定义为DATA_QUERY

char strGroupName[16]; // 16个字节的工作组名字

char strDataName[16]; // 16个字节的数据名字

};

（2）服务器接收到查询时，按照 DataQuery结构中的strGroupName和strDataName进行

搜索。如果该数据不存在，Server向Client发送一个FALSE标志。如果该数据存在，服务

テキスト ボックス: data type group name data name life time length content

器先向客户机发送一个TRUE标志，之后立即再向客户机发送该数据（DataPublish格式）。

如果客户机得到TRUE标志的查询结果，就调用函数SubscribeData来接收服务器发送过

来的数据。

三、客户程序的“组播”协议

客户机先调用函数QueryGroupIP向服务器发送一个GroupAddress格式的报文，用于查

询组播地址。服务器返回相应的十进制点分式的IP地址。

struct GroupAddress

{

BYTE iDataType; // 2 个字节数据类型，宏定义为GROUP_ADDRESS

char strGroupName[16]; // 16个字节的工作组名字

};

客户机调用函数MulticastMessage向指定的组（根据组播地址）播放消息。组播的数据

报结构 DataMulticast定义如下：

struct DataMulticast

{

DWORD dwContentType; // 组播的数据报类型，由用户定义

char *pchContent; // 组播的数据报内容，由用户定义

};

如果客户机接收到组播的消息，将自动调用函数MessageResponse来响应该消息。

MessageResponse是虚函数，它将根据dwContentType信息决定如何处理到来的组播消息，

具体功能由用户定义。

5.5.3.2 CNC 服务器的设计

一、数据结构

CNC 服务器的数据结构主要由三部分组成：

（1）一张用于管理组播地址的链表。组播地址由服务器动态生成，客户机可以向服务器查

询任意组的组播地址。

（2）一张用于管理线程指针的链表。服务器采用多线程并发处理技术，使客户机获得最快

的响应。

（3）每个组都有一张用于管理“发布—订阅”的数据的Hash表。由于同一时刻，系统可

能存在多个生产者与消费者，数据的存入、取出速度成为服务器性能的重要指标。Hash表

可以提供比链表更快的数据检索速度。Hash表中的数据项结构见DataElement ：

struct DataElement

{

char strGroupName[16]; // 工作组的名称

char strDataName[16]; // 数据的名称

BYTE iStorageType; // 存储类型： STORAGE_FILE 或 STORAGE_MEMORY

ColeDateTime TimeToDie; // 作废时刻

BOOL bLock; // 锁定标志： TRUE 或 FALSE

DWORD dwLength; // 数据的长度

char *pchContent; // 数据内容

};

 

存储类型（iStorageType）的用途：把数据全部保存在内存中将非常消耗服务器的内存

资源，在很多情况下是没有必要的。为了提高内存的使用效率，服务器仅把生命期较短或者

长度较短的数据保存在内存中（即为STORAGE_MEMORY类型），而把生命期较长或者长度较长

的数据保存在文件中（即为STORAGE_FILE类型）。

作废时刻（TimeToDie）的用途：客户机发布的数据均指定了生命期，服务器在接收到

数据时即可计算出作废时刻。服务器将定期扫描Hash表，若发现有数据超出作废时刻（并

且没有被锁定），即可删除此数据。

锁定标志（bLock）的用途：很多客户机可能同时订阅某个数据，而该数据可能已超出

作废时刻即将被删除。为避免冲突，规定只要有客户机订阅数据，就用iLock标志来锁定此

数据，直到订阅完成后才消除锁定。

二、多线程并发技术

服务器有一个主线程和多个子线程。主线程负责客户机的入连接请求，然后创建一个子

线程来处理这个TCP连接。每个子线程按照CNC API的协议与客户机通讯。由于有多个子线

程共享服务器中的数据，多线程对共享资源的同步访问成为实现的难点。CNC 主要采用了关

键区、互斥对象等同步手段解决这个问题。

三、Winsock的使用

CNC 1.0运行于Windows 9x/NT系统下，底层的网络通讯程序用Winsock编写。Winsock

有两种工作方式：阻塞方式和非阻塞方式。阻塞方式的优点是编程简单，可靠性好。缺点是

容易使应用程序阻塞住，不能处理其它事务。非阻塞方式是利用Windows 消息机制实现的。

优点是在数据到来的时候，系统向应用程序窗口发送消息，使得应用程序不必总在等待数据，

提高了工作效率。缺点是在发送和接收数据时，应用程序并不将事情做完（不阻塞），以至

于应用程序要维护复杂的状态机。

鉴于阻塞方式和非阻塞方式各有优缺点，CNC 服务器采用了混合方式。主线程采用非阻

塞的消息驱动方式，可以快速响应客户机的入连接。在子线程中，仍采用非阻塞的消息驱动

方式接受客户机的请求，只有在响应请求时，采用阻塞的方式一次性地完成数据的发送或接

收。

5.5.4 应用示例

图5.17、图5.18是参加协同工作的两个客户程序示例，这两个程序均用Intra3D 2.0 和

CNC 1.0开发。图5.17的客户程序向CNC 服务器订阅 .3ds和 .obj格式的多边形模型数据

并执行交互式绘制。图5.18的客户程序向CNC 服务器订阅商业统计图形数据并执行交互

式绘制。另有一个客户机（数据源）向CNC 服务器发布各种数据，并用组播来通知各个客

户机当前发布了什么数据（短消息）。

Intra3D 2.0和CNC 1.0目前已经可以实用，请与作者联系，免费索取软件。

5.6 小 结

让我们用著名3D游戏软件Quake的设计师Michael Abrash 的话总结本章：“所有真正

杰出的设计一旦被设计好，看起来都是那么的简单和显而易见。但是在获得杰出设计的过程

中，需要付出令人难以置信的努力。”[Abrash 1998]

 

图5.17 绘制.3ds和.obj模型的客户程序

图5.18 绘制商业统计图形的客户程序