第五章系統設計

系統設計是把需求轉化為軟件系統的最重要的環節。系統設計的優劣在根本上決定

了軟件系統的質量。就象“一切帝國主義都是紙老虎”那樣可以斷定“差的系統設計必

定產生差的軟件系統。”所以我們要努力保證系統設計“根正苗紅”，把一切左傾、右傾

的設計思潮消滅在萌芽狀態。

WindowsNT的一位系統設計師擁有8輛法拉利跑車，讓Microsoft公司的一些程序

員十分眼紅。但你只能羨慕而不能憤恨，因為并不是每個程序員都有本事成為復雜軟件

系統的設計師。系統設計要比純粹的編程困難得多。即便你清楚客戶的需求，卻未必知

道應該設計什么樣的軟件系統一一既能掙最多的錢又能讓客戶滿意。“天下西湖三十六，

最美是杭州”，千年前蘇東坡大學士對西湖精采絕倫的系統設計，使杭州榮升為“天堂”,

讓后人只剩下贊嘆和破壞的份了。

本章講述系統設計的四方面內容：體系結構設計、模塊設計、數據結構與算法設計、

用戶界面設計.如果將軟件系統比嗡為人體，那么：

(1)體系結構就如同人的骨架。如果某個家伙的骨架是猴子，那么無論怎樣喂養和美容，

這家伙始終都是猴子，不會成為人。

(2)模塊就如同人的器官，具有特定的功能。人體中最出色的模塊設計之一是手，手只

有幾種動作，卻能做無限多的事情。人體中最糟糕的模塊設計之一是嘴巴，嘴巴將最有

價值但亳無相干的幾種功能如吃飯、說話、親吻混為一體，使之無法并行處理，真乃人

類之不幸。

(3)數據結構與算法就如同人的血脈和神經，它讓器官具有生命并能發揮功能。數據結

構與算法分布在休系結構和模塊中，它將協調系統的各個功能.人的耳朵和嘴巴雖然是

相對獨立的器官，但如果耳朵失聰了，嘴巴就只能發出“啊”“嗚”的聲音，等于喪失了

說話的功能(所以聾子天生就是啞巴)，可人們卻又能用手勢代替說話。人體的數據結構

與算法設計真是十分神奇并且十分可笑。

(4)用戶界面就如同人的外表，最容易讓人一見鐘情或一見惡心。象人類追求心靈美和

外表美那樣，軟件系統也追求(內在的)功能強大和(外表的)界面友好。但隨著生活

節奏的加快，人們已少有興趣去品味深藏不露的內在美。如果把Unix系統比作是健壯的

漢子和婦人，那么Windows系統就象嫵媚的小白臉和狐貍精。想不到Windows系統竟

然能興風作浪，占去大平市場。有鑒于此，我們應該鼓勵女士多買化妝品(男士付錢)

以獲得更好的界面。

在進行系統設計時，我們要深情地關注軟件的質量因素，如正確性與精確性、性能

與效率、易用性、可理解性與簡法性、可復用性與可擴充性等等。即使把系統設計做好

了，也并不意味著就能產生好的軟件系統。在程序設計、測試、維護等環節還要做大量

的工作，無論哪個環節出了差錯，都會把好事搞砸了。據說上帝把所有的女士都設計成

天使，可是天使們在下凡時有些雙腳先著地，有些臉先著地。上帝的這一疏忽讓很多女

孩傷透了心。我們在開發軟件時，一定要吸取這個教訓。

5.1體系結構設計

楊叔子院子曾這樣指點其弟子：

文學中有科學，音樂中有數學，漫畫中有現代數學的拓撲學。漫畫家可以“幾篦”

就把一個人畫出來，不管怎么美化或丑化，就是活像。為什么？因為那“幾筆”不是別

的，而是拓撲學中的特征不變量，這是事物最本質的東西。

體系結構是軟件系統中最本質的東西：

（1）體系結構是對復雜事物的一種抽象。良好的體系結構是普遍適用的，它可以高效地

處理多種多樣的個體需求。一提起“房子”，我們的腦中馬上就會出現房子的印象（而不

是地洞的印象）。“房子”是人們對住宿或辦公環境的一種抽象。不論是辦公樓還是民房，

同一類建筑物（甚至不同類的建筑物）之間都具有非常相似的體系結構和構造方式。如

果13億中國人民每個人都要用特別的方式構造奇異的房子，那么960萬平方公里的土地

將會變得千瘡百孔，終E不得安寧。

（2）體系結構在一定的時間內保持穩定。只有在穩定的環境下，人們才能干點事情，社

會才能發展.科學告訴我們，宇宙間萬物無時無刻不在運動、飛行.由于我們的生活環

境在地球上保持相對穩定，以致于我們可以無憂無慮地吃飯和睡覺，壓根就意識不到自

己是活生生的導彈。軟件開發最怕的就是需求變化，但“需求會發生變化”是個無法逃

避的現實。人們希望在需求發生變化時，最好只對軟件做些皮皮毛毛的修改，可千萬別

改動軟件的體系結構。就如人們對住宿的需求也會變動，你可以經常改變房間的裝璜和

擺設，但不會在每次變動時都要去折墻、拆柱、挖地基。如果當需求發生變化時，程序

員不得不去修改軟件的體系結構，那么這個軟件的系統設計是失敗的。

良好的體系結構意味著普適、高效和穩定。本節將論述兩種非常通用的軟件體系結

構：層次結構和客戶機/服務器（Client/Server）結構.

5.1.1層次結構

層次結構表達了這么一種常識：有些事情比較復雜，我們沒法一口氣干完，就把事

情分為好幾層，一層一層地去做。高層的工作總是建立在低層的工作之上。層次關系主

要有兩種：上下級關系和順序相鄰關系。

一、上下級關系的層次結構

我們從小學一直讀到博士研究生畢業，要讀20多年，可以分為五個層次。而范進的

知識結構只有兩層：“私班”和“秀才”，但讀了五十多年，如圖5.1所示。一般地處于

較高層次的學生應該懂得所有低層次的知識，而處于低層次學生無法懂得所有高層次的

知識。圖5.1的層次結構存在上下級關系，如同在軍隊中，上級可以命令下級，而下級

不能命令上級。如果把圖5.1的層次結構當成是一個軟件系統的結構，那么上層子系統

可以使用下層子系統的功能，而下層子系統不能夠使用上層子系統的功能。

二、順序相鄰關系的層次結構

順序相鄰關系的層次結構表明通訊只能在相鄰兩層之間發生，信息只能被一層一層

地順序傳遞。這種層次結構的經典之作是計算機網絡的OSI參考模型，如圖5.2所示。

為了減少設計的豆雜性，大多數網絡都按層（Layer）或級（Level）的方式組織。每一

層的目的都是向它的上一層提供一定的服務，而把如何實現這一服務的細節對上一層加

以屏蔽。一臺機器上的第n層與另一臺機器上的第n層進行對話。通話的規則就是第n

層的協議。數據不是從一臺機器的第n層直接傳送到另一臺機器的第n層。發送方把數

據和控制信息逐層向下傳遞。最低層是物理介質，它進行實際的通訊。接收方則將數據

和控制信息逐層向上傳遞。

每一對相鄰層之間都有接口。接口定義了下層提供的原語操作和服務。當網絡設計

者在決定一個網絡應包含多少層，每一層應當做什么的時候，其中很重要的工作是在相

鄰層之間定義清晰的接LK接口可以使得同一層能輕易地用某一種實現(Implementaiion)

來替換另一種完全不同的實現(如用衛星信道來代替所有的電話線)，只要新的實現能向

上層提供同一組服務就可以了。[Tanenbaum1998]

考上“舉人”時已五十多歲了舉人

復習報考“舉人”用了幾十年

秀才

私塾

圖5.1(b)范進的知識結構

主

機

B

圖5.2計算機網絡的OSI參考模型

三、其它的層次結構

目前在大型商業應莊軟件系統中還流行一種包含中間件(Middleware)的層次結構,

如圖5.3所示［Jacobson1997］。中間件支持與平臺無關的分布式計算，可以用DCOM和

CORBA對象來實現。

ApplicationSystems

Business-specificComponents

Middleware

SystemSoftware

圖5.3包含中間件的層次結構

S.1.2客戶機/服務器結構

讓我們先回顧一下早期的電話系統。貝爾(AlexanderGrahamBell)于1876年申請

了電話專利。那時期的電話必須一對一對地賣，用戶自己在兩個電話之間拉一根線。如

果一個電話用戶想和其它幾個電話用戶通話，他必須拉n根單獨的線到每個人的房子里。

于是在很短的時間內，城市里到處都是穿過房屋和樹木的混亂的電話線。很明顯，企圖

把所有的電話完全互聯(如圖5.4(a)所示)是行不通的。

貝爾電話公司在1878年開辦了第一個交換局。公司為每個客戶架設一條線。打電話

時，客戶搖動電話的曲柄使電話公司辦公室的鈴響起來，操作員聽到鈴聲以后根據要求

將呼叫方和被呼叫方用跳線手工連接起來。這種集中交換式的模型如圖5.4(b)所示。

很快地，貝爾系統的交換局就出現在各地。人們乂要求能打城市間的長途電話，就出現

了二級交換局，以后進一步發展為多個二級交換局。|Tanenbauml998］

5.4(a)完全互聯的電話系統5.4(b)集中交換式的電話系統

如果將圖5.4(b)中的電話看成是客戶程序，將中心的交換局看成是服務程序，那

么圖5.4(b)就是典型的客戶機/服務器結構。注意這里客戶機和服務器都是指軟件而不

是指硬件(一臺計算機可以放多個客戶機和服務器軟件)。

客戶機/服務器結構存在兩個顯然的優點：

（1）以集中的方式高效率地管理通訊。前面講電話系統的故事就是要說明這一點。

（2）可以共享資源。比如在信息管理系統中，服務器將信息集中起來，任何客戶機都可

以通過訪問服務器而獲得所需的信息。

客戶機和服務器之間的通訊以“請求一一響應”的方式進行。客戶機先向服務器發

起"請求”（Request）,服務器再響應（Response）這個請求，如圖5.5所示。

請求

客戶機服務器

<--------------------------------------

響應

圖5.5Client和Server之間的通訊以“請求一一響應”的方式進行

采用“請求一一響應”這種通訊方式的基本動機是為了解決“聚集"（Rendezvous）

問題。為了理解這一個問題，設想一個人試圖在分離的機器上啟動兩個程序并讓它們進

行通訊。還需記住，計算機的運行速度要比人的操作速度高出許多數量級。在他啟動第

一個程序后，該程序開始執行并向對等程序發送消息-在幾個微秒內，它便發現對等程

序還不存在，于是就發出一條錯誤消息，然后退出。此后，他啟動了第二個程序。不幸

的是，當第二個程序開始執行時，它也找不到第一個程序（早已退出）。即使這兩個程序

連續地重新試著通訊，但由于它們的執行速度那么高，以致于它們在同一瞬間聯系上的

概率非常低。在客戶機/服務器結構中，服務器在啟動后必須（無限期地）等待客戶機的

“請求”，因此就形成了“請求一一響應”的通訊方式。

在Internet/Intranel領域，目前“瀏覽器一Web服務器一數據庫服務器”結構是一

種非常流行的客戶機/服務器結構，如圖5.6所示。這種結構最大的優點是：客戶機統一

采用瀏覽器，這不僅讓用戶使用方便，而且使得客戶機端不存在維護的問題。當然，軟

件開發布和維護的工作不是自動消失了，而是轉移到了Web服務器端。在Web服務器

端,程序員要用腳本語言編寫響應頁面。例如用Microsoft的ASP語言查詢數據庫服務

器，將結果保存在Web頁面中，再由瀏覽器顯示出來。

圖5.6”瀏覽器一Web服務器一數據庫服務器”結構

5.2模塊設計

在設計好軟件的體系結構后，就已經在宏觀上明璘了各個模塊應具有什么功能，應

放在體系結構的哪個位置。我們習慣地從功能上劃分模塊，保持“功能獨立”是模塊化

設計的基本原則。因為，“功能獨立”的模塊可以降低開發、測試、維護等階段的代價。

但是“功能獨立”并不意味著模塊之間保持絕對的孤立。一個系統要完成某項任務，需

要各個模塊相互配合才能實現，此時模塊之間就要進行信息交流。

比如手和腳是兩個“功能獨立”的模塊。沒有腳時，手照樣能干活。沒有手時，腳

仍可以走路。但如果希望跑得快，那么邁左腳時一定要伸右臂甩左臂，邁右腳時則要伸

左臂甩右臂。在設計一個模塊時不僅要考慮“這個模塊就該提供什么樣的功能”，還要考

慮“這個模塊應該怎樣與其它模塊交流信息”。

本節將論述評價模塊設計優劣的三個特征因素：“常息隱藏”、“內聚與耦合”和“封

閉一一開放性”。

5.2.1信息隱藏

在一節不和諧的課堂里，老師嘆氣道：“要是坐在后排聊天的同學能象中間打牌的同

學那么安靜，就不會影響到前排睡覺的同學。”

這個故事告訴我們，如果不想讓壞事傳播開來，就應該把壞事隱藏起來，“家丑不可

外揚”就是這個道理C為了盡量避免某個模塊的行為去干擾同一系統中的其它模塊.在

設計模塊時就要注意信息隱藏。應該讓模塊僅僅公開必須要讓外界知道的內容，而隱藏

其它i切內容。

模塊的信息隱藏可以通過接口設計來實現。一個模塊僅提供有限個接口（Interface）,

執行模塊的功能或與模塊交流信息必須且只須通過調用公有接口來實現。如果模塊是一

個C++對象，那么該模塊的公有接口就對應于對象的公有函數。如果模塊是一個COM

對象，那么該模塊的公有接口就是COM對象的接口。一個COM對象可以有多個接口，

而每個接口實質上是一鰭函數的集合。IRogerson1999]

美國也許是世界上丑聞最多的國家，因為它追求民主，不懂得“隱藏信息”。但美

國乂是軟件產業最發達的國家，模塊化設計的方法都是美國人倡導的，他們應該很懂得

“隱藏信息”。真是前后矛盾，這些美國佬！

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數據結構與算法設計

學會設計數據結構與算法，可以讓我們編寫出高效率的程序。也許有人要問，在計

算機速度日新月異的今天，為什么還需要高效率的程序？

因為我們的雄心與能力是一起增長的，技術進步最快也快不過人們欲望的增長。計

算速度和存儲容量上的革新僅僅提供了處理更復雜問題的有效工具，所以高效率的程序

永遠不會過時。

設計高效率的程序是基于良好的數據結構與算法，而不是基于編程小技巧。大多數

計算機科學系在設置課程時，都重視學習基本的軟件工程原理，以及數據結構與算法設

計。

一般說來，數據結構與算法就是一類數據的表示及其相關的操作（這里算法不是指

數值計算的算法）。從數據表示的觀點來看，存儲在數組中的一個有序整數表也是一種數

據結構。算法是指對數據結構施加的一些操作，例如對一個線性表進行檢索、插入、刪

除等操作。一個算法如果能在所要求的資源限制（ResourceConstraints）范圍內將問題

解決好，則稱這個算法是有效率（Ffficient）的.例如一個資源限制可?能是“用于存儲

數據的內存有限”，或者“允許執行每個子任務所需的時間有限”。一個算法如果比其它

已知算法所需要的資源都少，這個算法也被稱為是有效率的。算法的代價（Cost）是指

消耗的資源量。一般說來，代價是由一個關鍵資源例如時間或空間來評估的。

毋庸置疑，人們編寫程序是為了解決問題。只有通過預先分析問題來確定必須達到

的性能目標，才有希望挑選出正確的數據結構。有相當多的程序員忽視了這一分析過程,

而直接選用某一個他們習慣使用的，但是與問題不相稱的數據結構，結果設計出一個低

效率的程序。如果使用簡單的設計就能夠達到性能目標時，選用復雜的數據結構也是沒

有道理的。

人們對常用的數據結構與算法的研究已經相當透徹，可以歸納出一些設計原則：

（1）每一種數據結構與算法都有其時間、空間的開銷和收益。當面臨一個新的設計問題

時，設計者要徹底地掌握怎樣權衡時空開銷和算法有效性的方法。這就需要懂得算法分

析的原理，而目.還需要了解所使用的物理介質的特性（例如，數據存儲在磁盤上與存儲

在內存中，就有不同的考慮）。

（2）與開銷和收益有關的是時間一一空間的權衡。通常可以用更大的時間開銷來換取空

間的收益，反之亦然。時間一一空間的權衡普遍地存在于軟件開發的各個階段中。

（3）程序員應該充分地了解一些常用的數據結構與算法，避免不必要的重發設計工作。

（4）數據結構與算法為應用服務。我們必須先了解應用的需求，再尋找或設計與實際應

用相匹配的數據結構。[Shaffer1998]

5.4用戶界面設計

某個人總有辦法讓自己保持心情愉快、信心十足。有一天，他向一名圍棋九段和一

名乒乓球世界冠軍挑戰，結果他全勝了。因為他跟圍棋九段打乒乓球，跟乒乓球冠軍下

圍棋。用戶界面的編程技術是人們熟悉得不得了的事，我決定講一講比較陌生的“用戶

界面設計美學”。

有位愛好書畫的博士后請我欣賞鋼琴演奏會。我從頭到尾只聽到“叮叮咚咚”的聲

吾，實在享受不到“高雅”，就請這位朋友指點。他雖然也不懂鋼琴，卻從欣賞書法的角

度設法解釋如何欣賞音樂。可是我既不懂書法也不懂音樂，真是坐立不安。“美”似乎真

的不可言傳。我在讀本科時，特別喜歡編寫用戶界面程序，并且常向同學演示、賣弄。

我覺得還不過癮，就寫了一篇“用戶界面設計美學”的短文［林銳1997］。凡是路過我實驗

室的同學都被我逮住，被迫聽完我得意之極的朗讀，茫然者與痛苦者居多。不久我的朗

讀便所向披糜，聞聲者逃之夭夭。現在我又把那篇短文摘錄至此，請您忍著點吧。

5.4.1界面設計中美的需求與導向作用

人們對美的向往和追求是與生俱有的。顯然沒有人愿意丑化自己的程序，也沒有用

戶嗜好丑陋的界面。軟件開發者要設計美，用戶要享受美，所以界面的美是開發者與用

戶的共同需求。

界面美的概念很抽象，以致讓人無法說清楚什么是界面的美。但它同時又很現實，

以致人人都可以去欣就和感受界面美，并且挑剔美中之不足“美學不是一種量化的學問，

如果因此而輕視美學指導，必將導致在設計過程中光依賴程序員個人的經驗與感覺。由

于程序員接受的教育主要是如何使計算機完成工作，而不是人如何工作，因此僅靠程序

員主觀想象設計而成的界面往往得不到大眾用戶的認可。

美的界面能消除用戶由感覺引起的乏味、緊張和疲勞（情緒低落），大大提高用戶的

工作效率，從而進一步為發揮用戶技能和為用戶完成任務作出貢獻。從人機界面發展歷

史與趨勢上可以看出人們對界面美的需求，以及美在界面設計中的導向作用。

界面設計已經經歷了兩個界限分明的時代。第一代是以文本為基礎的簡單交互，如

常見的命令行，字符菜單等.由于第一代界面考慮人的因素太少，用戶興趣不高。隨著

技術的發展，出現了第二代直接操縱的界面。它大量使用圖形、語音和其它交互媒介，

充分地考慮了人對美的需求。直接操縱的界面使用視聽、觸摸等技術，讓人可以憑借生

活常識、經歷和推理來操縱軟件，愉快地完成任務。更高層次的界面甚至模擬了人的生

活空間，例如虛擬現實環境。

界面的美充分體現了人機交互作用中人的特性與意圖，越來越多的用戶將通過具有

吸引力而令人愉快的人機界面與計算機打交道。

5.4.2界面美的內涵

本節從合適性、風格和廣義美三個方面論述界面美的內涵。

一、界面的合適性

界面的合適性是指界面是否與軟件功能相融洽。如果界面不適合于軟件的功能，那

么界面將亳無用處，界面美的內涵就無從談起。所以界面的合適性是界面美的首要因素，

它提醒設計者不要片面追求外觀漂亮而導致失真或華而不實。界面的合適性既提倡外美

內秀，又強調恰如其分。

合適性差的界面無疑會混淆軟件意圖，致使用戶產生誤解。即使它不損害軟件功能

與性能，也會使用廣產生不該有的情緒波動。例如一些軟件開發者喜歡為其作品加段

動畫演示，以便吸引更多用戶的關注。這本是無可非議的，問題在于這演示是否合情合

理。如果運行一個程序，它首先表演一套復雜的動畫，在后臺演奏雄壯的進行曲，電閃

雷鳴之后出來的卻是一個普通的文本編輯器。整個過程讓用戶置身于云里霧里，而結果

卻讓用戶感到驚謂而不是驚喜。合適性差的界面只會給軟件帶來厄運。

二、界面的風格

界面的風格有兩類，一是“一致性”，二是“個性化”。

商業應用軟件的界面設計注重一致性。設計者必須密切注意在相同應用領域中最流

行的軟件的界面，必須尊重用戶使用這些軟件的習慣。例如商業軟件習慣于設置FI鍵

為幫助熱鍵，如果某個設計者別出心裁地讓F1鍵成為程序終止的熱鍵，那么在用戶渴

望得到幫助而伸手擊F1鍵的一剎那，他的工作就此完蛋。相信這個用戶“一朝被蛇咬，

十年怕井繩”。

目前流行的軟件開發工具如VisualC++、VisualBasic、Delphi、C++Builder、Power

Builder等,都能夠快速地開發出非常相似的圖形用戶界面。在Internet/Intranei領域，瀏

覽器幾乎成了唯一的客戶機程序，因為用戶希望用完全一致的軟件來完成千變萬化的應

用任務”

在娛樂領域的軟件中，有個性化的界面自然比泯然于眾的界面更具有吸引力。一般

說來，計算機專業人員玩過的軟件不計其數。界面看多了，真有種“曾經滄海難為水”

的感覺。不過當我看到一個叫Sonique的放音樂的軟件時，不禁對其界面的創意嘖嘖稱

贊，忍不住象貼美女像那樣把它貼到書中，如圖5.7所示。

圖5.7Sonique軟件的幾種界面

人們經常搞不清楚什么情況下應該追求“一致性”或“個性化”。在大白天，當人們

都穿戴整齊時，有些人喜歡只掛幾片遮羞布。而當大家都赤條條地在共公浴室洗課時,

卻也有人喜歡穿著衣服。

三、界面的廣義美

盡管界面的美并沒有增加軟件的功能與性能，卻又是必為可少的。用戶使用界面時，

除了直接的感官美感外，還有很大一部分美感是間接的，它們存在于人們的使用體驗中，

例如方便，實用等。與圖形用戶界面相比，命令行是最原始的界面，它難記又難看。但

對于熟練的用戶而言，他們樂于使用命令行以獲得高效率。命令行因具有高效率而嬴得

了專業人士的喜愛，早期的Unix系統就是徹頭徹尾的命令系統。可以說，一切有利于人

機交互的界面設計因素都具有廣義美。

界面設計的一些特殊考慮也體現了廣義美，如設法使殘障人也可以使用軟件。IBM

公司在1985年已經創建了殘障人國家支持中心。Apple公司的專門教育辦公室則提供了

一些有利于殘障人使用的計算機信息產品。

5.5系統設計示例

一一支持協同工作的交互式三維區形軟件開發系統

本節論述“支持協同工作的交互式三維圖形軟件開發系統”的系統設計，作為本章

的示例(取材于作者的博士論文工作［林銳20001)。

5.5.1設計背景

圖形標準在圖形領域有著重要的地位，它不僅加速了3D應用程序的開發，而且使

3D應用程序的可移植性更好。歷史上曾出現的圖形標準(或API)有Core、GKS、PH【GS.

PEX、GL>Dore、RenderMan>Hoops、OpenGL等等。經過競爭與淘汰，目前OpenGL

成為國際上公認的3D圖形工業標準，在Unix與PC平臺得到廣泛應用。OpenGL提供

了數百個庫函數，可以方便地繪制具有真實感的3D圖形。但是在開發交互式的3D圖形

應用程序時，圖形的繪制只是一部分工作，更多的工作集中在場景數據結構、圖形對象、

三維交互和圖形用戶界面的設計上。

由于OpenGL與窗口系統無關，不提供任何交互手段，必須由程序員自己編寫所有

的交互功能。并且OpenGL的編程接口是低級的C函數，不提供可復用的對象庫或者應

用程序框架，開發效率不高。為了克服這些困難，人們往往在圖形標準之上再建立更高

級的開發工具(3DToolkit或3DEngine)o基于OpenGL的著名的開發工具有Open

InventorsIRISPerformersOptimeizer/Cosmo3D以及GLUT等等。OpenInventor被譽為

是交互式3D開發工具的“事實標準”，但顯然沒有一個3D開發工具能滿足所有的應用

需求，3D的廣泛應用需要更多的開發工具支持。

隨著計算機圖形技術與網絡技術的迅猛發展，兩者的結合勢在必行。在商、業、科研、

教育、娛樂等領域，用于分布式虛擬環境(DistributedVirtualEnvironments,DVEs)和計

算機支持協同工作(ComputerSupportedCooperativeWork,CSCW)的圖形系統已成為研

究與應用的熱點。著名的DVEs系統有DIVE、dVS、MR、Rcpo-3D等。但是這些DVEs

系統缺乏3D開發工具的交互式圖形功能以及通用性，而通用的3D開發工具如Open

Inventor則又不支持分布式計算和協同工作。由于在窗口系統、圖形支撐庫、編程語言

等方面存在差異，上述DVEs系統和3D開發工具難以方便地結合使用。

我們多方面分析了3D需求及軟硬件條件，研制完成運行于PC平臺，支持協同工作

的交互式三維圖形軟件開發系統，如圖5.8所示。其中：

(1)Intra3D2.0是基于OpenGL的通用交互式三維圖形軟件開發工具，可用于快速開發

Window9x/NT下的交互式三維圖形應用軟件。

(2)CNC1.0是支持協同工作的網絡通訊開發系統(CooperativeNetwork

Communicator),其核心是支持“發布一訂閱模式”與“組播模式”的服務器與API。

結合Intra3D2.0和CNC1.0,可以快速開發支持協同工作的交互式三維圖形應用軟

件。

通用交互式三維圖形軟件開發工具支持協同工作的網絡通訊開發系統

Intra3D2.0CNC1.0

圖5.8支持協同T作的交廳式三維圖形軟件開發系統

5.5.2通用交互式三維圖形軟件開發工具Intra3D2.0

Intra3D2.0的核心是集成了場景數據結構、圖形對象、三維交互算法和圖形用戶界

面的C++類庫與COM(ComponentObjectModel)對象庫，支持VisualC++、VisualBasic、

Delphi等語言的應用編程。Intra3D的核心庫分四層創建：

(1)第一層為"基礎對象與函數”(BasicObjectsandFunctions)；

(2)第二層為“圖形對象"(GraphicalObjects)；

(3)第三層為"場景圖與節點”(SceneGraphandNodes)；

(4)第四層為"繪制與交互”(RenderingandInteraction)。

體系結構如圖5.9所示，其中高層構件可以引用低層構件，但低層構件不能引用高層構

件。

圖5.9Intra3D2.0的體系結構

Int「a3D2.0是免費軟件，有配套書籍《交互式二維圖形技術與程序設計》。標準版軟

件約25兆，核心庫7萬多行C++代碼全部公開，用戶可以方便地修改內核以適應不同

的需求。

5.5.2.1主要模塊和功能

一、基礎對象與函數層

(1)定義了用于對象引用計數的內存管理基類；

(2)矢量、矩陣與四元組運算，鼠標跟蹤球算法：

(3)點陣字體與三維矢最字體輸出，常用于數據可視化圖形的數據標注：

(4)圖像輸入輸出以及紋理映射，支持BMP、GIF、JPEG、SGLTGA等圖像格式；

(5)常用幾何圖元的繪制，如錐、柱、球、環等，并支持Swept形體，螺旋體的繪制：

(6)提供450余種材質，在第四層中可以交互式編輯這些材質。

二、圖形對象層

圖形對象能將數據轉化為幾何模型并可以繪制出來。Intra3D2.0版提供了三類圖形

對象：

(1)常用幾何對象，如氏方體、錐體、圓柱體、球體、圓環體、Swept形體等；

(2)多邊形模型對?象，可用于繪制Autodesk公司.4#模型和Wavefront公司的chj模型：

(3)商業統計圖形對象，如柱形圖、帶狀圖、條形圖、折線圖、面積圖、餅圖、塔形圖、

曲線圖、曲面圖、進程圖、股票圖等。

圖形對象的開發與應用問題密切相關，用戶可以使用繼承方法擴充新的圖形對象，

而不會影響到其它三層的構件。

三、場景圖與節點

場景圖(SceneGraph)是有向無環圖，SceneGraph的主要節點有：(1)SceneNode

是所有節點的基類。在SceneNode中定義了局部坐標系以及相應的圖形變換，這樣便于

第四層以同樣的操作方式實現三維交互.(2)相機節點(CamcraNode)支持平行投影與

透視投影，支持多個相機切換。(3)光源節點有三種：平行光源節點(DirLightNode)、點

光源節點(PointLightNode)和錐光源節點(SpotLightNode)。(4)形體節點(ShapeNode)

用于引用圖形對象，有關圖形對象的三維交互均由ShapeNode處理。

四、繪制與交互層

Intra3D的交互分兩類：??類是對形體、光源和相機的直接操作，另?類是真實感屬

性的編輯。Intra3D的場景視圖構件(SceneView)封裝了交互式繪制的所有細節，如消

息處理.、場景節點的遍歷繪制、多重采樣消鋸齒、鼠標交互等。為了便于編輯真實感屬

性，lntra3D定制了一些常用對話;矢量字體對話(FontDialog)、顏色對話(C定。「Dialog)、

材質庫對話(MaterialLibDialog)材質對話(MaterialDialog)與光源對話(DirLightDialog,

PointLightDialog,SpotLightDialog)o

5.5.2.2用戶界面設計

Intra3D的場景視圖構件SceneView用于快速創建交互式3D應用程序的主界面。

SceneView支持selecting、scaling、rotating、translatingxcreatingxdeleting等三十余種

操作，并提供工具條方便于交互，如圖5.10所示。

為了編輯真實感屬性，常需在對話框中繪制3D圖形。Microsoft的窗口系統不提供

3D的對話窗口。使用Intra3D的Window3D構件可在對話框中創建多個3D視圖，圖5.11

的材質對話和圖5.12的材質庫對話都使用了Window3D構件。顏色編輯是3D圖形程序

中最常用的交互，材質與光源的編輯實際上是通過改變顏色分量來實現的。需要進行顏

色編輯的交互均涉及HSV與RGB模式的顏色轉換。lMra3D的“繪制與交互層”實現了

這些計算，并且提供彩色的滑動條用于鼠標交互。圖5.13、圖5.14分別為點光源對話和

顏色對話。

圖5.10用于直接操作的三維交互工具條

MaterielLib

固4▲

一

回U

…Au%t

臼

.9■SI

.■

.

.,191_

.

.9

9

.

.9

Diffuse...—9

.

.9

Specular..

9

.

Enissive.9

.9

.

-----7聚光指數.93

胃透明程度0.35Cancel

圖5.11材質對話圖5.12材質庫對話

圖5.13點光源對話圖5.14顏色對話

5.5.3支持協同工作的網絡通訊開發系統CNC1.0

最簡單的協同工作模式是讓兩個客戶機直接通訊，可以用Sockel編程實現。假設有

n個客戶機參加協同工作，每個客戶機將與所有其它的客戶機通訊。那么總共存在

n(n-l)/2個Socket直接通訊，并且每個客戶機的變動將導致其它客戶機的修改。這種

Socket直接通訊使得協同工作的管理和客戶機的程序設計變得非常困難。CNC系統提供

了支持“發布一訂閱(Publish-Subscribc)”與“組播(Multicast)”模式的服務器與API,

可以高效地管理多個組群的協同工作，并使得客戶機的程序設計十分簡單。CNC1.0的

系統結構如圖5.15所示。

CNC服務器將客戶機分組管理。在“發布一訂閱”模式中，將產生數據的進程稱為

生產者(Producer),將接受數據的進程稱為消費者(Consumer)。生產者可以向服務器

發布數據，服務器保存這些數據。消費者可以向服務器訂閱數據。每個客戶機可能是很

多數據的生產者或消費者。同一時刻，CNC系統允許有任意多個生產者和消費者存在。

CNC的“發布一訂閱”功能是用TCP協議實現的。

在“組播”模式中，服務器動態地分配每個組的組播地址。客戶機可以向服務器申

請加入任意組，允許向任意組播放消息，服務器不保存這些組播消息。CNC的“組播”

功能是用UDP協議實現的。

圖5.15CNC1.0的系統結構

5.5.3.1CNC客戶機的API設計

類CNCClient客戶機用來實現“發布一訂閱”和“組播”功能，主要接口(公有函

數)如下：

classCNCClient

public:

BOOLConnect(...);//連接服務器

BOOLDisconnect0;//與服務器斷開連接

BOOLPublishData(...);//向服務器發布數據

BOOI.QueryData(...)：//向服務器查詢數據

BOOLSubscribcData(...);//向服務器訂閱數據

GROUPIPQueryGrouplP(...);//向服務器查詢組播地址

DWORDMulticastMessage(...);//發送組播消息

virtualvoidMessageRcsponse(...);//響應組播消息

);

一、客戶程序的“發布”協議

客戶機向服務器發布的每個數據報均含有數據類型、工作組名稱、數據名稱、生命

期和數據長度的信息。報文格式如圖5.16所示，數據結構見DataPublish：

structDataPublish

BYTEiDataType;//2個字節數據類型，宏定義為DATAPUBLISH

chai-strGroupName[16];//16個字節的工作組名字

charstrDataName[16];//16個字節的數據名字

DWORDdwLifelime;//4個字節的數據生命期，以秒為單位

DWORDdwLength;//4個字節的數據內容的長度

char*pchContent://數據內容

}:

/2字節/16字節/16字節/4字節/4字節

datatypegroupnamedatanamelifetimelengthcontent

圖5.16用于發布的報文格式

二、客戶程序的“訂閱”協議

客戶機向服務器訂閱數據分兩步實現：

(1)先調用函數QueryData向服務器發送一個DataQuery格式的報文，用于查詢要訂

閱的數據是否存在。

structDataQucry

BYTEiDataType;//2個字節數據類型，宏定義為DATA_QUERY

charstrGroupName[16];//16個字節的工作組名字

charstrDataName[16];//16個字節的數據名字

)；

(2)服務器接收到查詢時，按照DataQuery結構中的strGroupName和strDataNane進

行搜索。如果該數據不存在，Server向Client發送一個FALSE標志。如果該數據存在，

服務器先向客戶機發送一個TRUE標志，之后立即再向客戶機發送該數據(DataPublish

格式)。

如果客戶機得到TRUE標志的查詢結果，就調用函數SubscribeData來接收服務器發

送過來的數據.

三、客戶程序的“組播”協議

客戶機先調用函數QueryGroupIP向服務器發送一個GroupAddress格式的報文，用

于查詢組播地址。服多器返回相應的十進制點分式的IP地址。

structGroupAddress

BYTEiDataType;//2個字節數據類型，宏定義為GROUP_ADDRESS

charstrGroupName[16];//16個字節的工作組名字

)；

客戶機調用函數MulticastMessage向指定的組(根據組播地址)播放消息。組播的

數據報結構DataMuIticast定義如下:

structDataMulticast

(

DWORDdwContentType;//組播的數據報類鷺由用戶定義

char*pchContent;//組播的數據報內容，由用戶定義

)；

如果客戶機接收到組播的消息，將自動調用函數ikssageResponse來響應該消息。

MessageResponse是虛函數，它將根據dwContentType信息決定如何處理到來的組播消

息，具體功能由用戶定義。

553.2CNC服務器的設計

一、數據結構

CNC服務器的數據結構主要由三部分組成：

(1)一張用于管理組播地址的鏈表。組播地址由服務器動態生成，客戶機可以向服務器

查詢任意組的組播地址。

(2)一張用于管理線程指針的鏈表。服務器采用多線程并發處理技術，使客戶機獲得最

快的響應。

(3)每個組都有一張用于管理“發布一訂閱”的數據的Hash表。由于同一時刻，系統

可能存在多個生產者與消費者，數據的存入、取出速度成為服務器性能的重要指標。Hash

表可以提供比鏈表更快的數據檢索速度。Hash表中的數據項結構見DataElement：

structDataElement

charstrGroupName[16];//工作組的名稱

charstrDataName[16];//數據的名稱

BYTEiStorageType;//存儲類型：STORAGE._FILE或STORAGE_MEMORY

ColoDatcTimcTimc