軟件系統(tǒng)設計方案分析報告

10/46第五章系統(tǒng)設計系統(tǒng)設計是把需求轉化為軟件系統(tǒng)的最重要的環(huán)節(jié)。系統(tǒng)設計的優(yōu)劣在根本上打算了軟件系統(tǒng)的質量。就象“一切帝國主義都是紙老虎”那樣可以斷定“差的系統(tǒng)設計必WindowsNT的一位系統(tǒng)設計師擁有8Microsoft能憤怒，由于并不是每個程序員都有本領成為簡單軟件系統(tǒng)的設計師。系統(tǒng)設計要比純粹的編程困難得多。即便你清楚客戶的需求，卻未必知道應當設計什么樣的軟件系統(tǒng)——既能掙最多的錢又能讓客戶滿足。“天下西湖三十六，本章表達系統(tǒng)設計的四方面容：體系構造設計、模塊設計、數(shù)據(jù)構造與算法設計、用戶界面設計。假設將軟件系統(tǒng)比方為人體，那么：體系構造就如同人的骨架。假設某個家伙的骨架是猴子，那么無論怎樣喂養(yǎng)和美容，這家伙始終都是猴子，不會成為人。模塊就如同人的器官，具有特定的功能。人體中最出色的模塊設計之一是手，手只有幾種動作，卻能做無限多的事情。人體中最糟糕的模塊設計之一是嘴巴，嘴巴將最有價值但毫無相干的幾種功能如吃飯、說話、親吻混為一體，使之無法并行處理，真乃人類之不幸。數(shù)據(jù)構造與算法就如同人的血脈和神經(jīng)，它讓器官具有生命并能發(fā)揮功能。數(shù)據(jù)構造與算法分布在體系構造和模塊中，它將協(xié)調系統(tǒng)的各個功能。人的耳朵和嘴巴雖然是相對獨立的器官，但假設耳朵失聰了，嘴巴就只能發(fā)出〔所以聾子天生就是啞巴構造與算法設計真是格外奇特并且格外可笑。用戶界面就如同人的外表，最簡潔讓人一見鐘情或一見惡心。象人類追求心靈美和外表美那樣，軟件系統(tǒng)也追求〔在的〕功能強大和〔外表的〕界面友好。但隨著生活節(jié)奏的加快，人們已少有興趣去品嘗深藏不露的在美。假設把UnixWindows系統(tǒng)就象嫵媚的小白臉和狐貍精。想不到Windows能興風作浪，占去大半市場。有鑒于此，我們應當鼓舞女士多買化裝品〔男士付錢〕以獲得更好的界面。如正確性與準確性、性能與效率、易用性、可理解性與簡法性、可復用性與可擴大性等等。即使把系統(tǒng)設計做好了，也并不意味著就能產(chǎn)生好的軟件系統(tǒng)。在程序設計、測試、維護等環(huán)節(jié)還要做大量的工作，無論哪個環(huán)節(jié)出了過失，都會把好事搞砸了。據(jù)說上帝把全部的女士都設計成天使，可是天使們在下凡時有些雙腳先著地，有些臉先著地。上帝的這一疏忽讓很多女孩傷透了心。我們在開發(fā)軟件時，肯定要吸取這個教訓。體系構造設計叔子院子曾這樣教導其弟子：文學中有科學，音樂中有數(shù)學，漫畫中有現(xiàn)代數(shù)學的拓撲學。漫畫家可以“幾筆”就把一個人畫出來，不管怎么美化或丑化，就是活像。為什么？由于那“幾筆”不是別的，而是拓撲學中的特征不變量，這是事物最本質的東西。體系構造是軟件系統(tǒng)中最本質的東西：體系構造是對簡單事物的一種抽象。良好的體系構造是普遍適用的，它可以高效地處理多種多樣的個體需求?！捕皇堑囟吹挠∠蠓N抽象。不管是辦公樓還是民房，同一類建筑物〔甚至不同類的建筑物〕之間都具有格外相像的體系構造和構造方式。假設13億中國人民每個人都要用特別的方式構造奇異的房子，那么960終日不得清靜。體系構造在肯定的時間保持穩(wěn)定。只有在穩(wěn)定的環(huán)境下，人們才能干點事情，社會才能進展?？茖W告知我們，宇宙間萬物無時無刻不在運動、飛行。由于我們的生活環(huán)境在地球上保持相對穩(wěn)定，以致于我們可以無憂無慮地吃飯和睡覺，壓根就意識不到自己是活生生的。軟件開發(fā)最怕的就是需求變化，但“需求會發(fā)生變化”是個無法躲避的現(xiàn)實。人們期望在需求發(fā)生變化時，最好只對軟件做些皮皮毛毛的修改，可千萬別改動軟件的體系構造。就如人們對住宿的需求也會變動，你可以常常轉變房間的裝璜和擺設，但不會在每次變動時都要去折墻、拆柱、挖地基。假設當需求發(fā)生變化時，程序員不得不去修改軟件的體系構造，那么這個軟件的系統(tǒng)設計是失敗的。良好的體系構造意味著普適、高效和穩(wěn)定。本節(jié)將論述兩種格外通用的軟件體系構造：層次構造和客戶機/效勞器〔Client/Server〕構造。層次構造層次構造表達了這么一種常識：有些事情比較簡單，我們沒法一口氣干完，就把事情分為好幾層，一層一層地去做。高層的工作總是建立在低層的工作之上。層次關系主要有兩種：上下級關系和挨次相鄰關系。一、上下級關系的層次構造我們從小學始終讀到博士爭論生畢業(yè)，要讀20多年，可以分為五個層次。而進的學問構造只有兩層：“私塾”和5.1所示。一般地處于較高層次的學生應當懂得全部低層次的學問，而處于低層次學生無法懂得全部高層次的學問。圖5.1上下級關系，如同在軍隊中，上級可以命令下級，而下級不能命令上級。假設把圖5.1系統(tǒng)的構造，那么上層子系統(tǒng)可以使用下層子系統(tǒng)的功能，而下層子系統(tǒng)不能夠使用上層子系統(tǒng)的功能。二、挨次相鄰關系的層次構造挨次相鄰關系的層次構造說明通訊只能在相鄰兩層之間發(fā)生，信息只能被一層一層地挨次傳遞。這種層次構造的經(jīng)典之作是計算機網(wǎng)絡的OSI參考模型，如圖5.2所示。為了削減設計的簡單性，大多數(shù)網(wǎng)絡都按層〔Layer〕或級〔Level〕的方式組織。每一層的目的都是向它的上一層供給肯定的效勞，而把如何實現(xiàn)這一效勞的細節(jié)對上一層加以屏蔽。一臺機器上的第n層與另一臺機器上的第n層進展對話。通話的規(guī)章就是第n機器的第n層直接傳送到另一臺機器的第n層。發(fā)送方把數(shù)據(jù)和掌握信息逐層向下傳遞。最低層是物理介質，它進展實際的通訊。接收方則將數(shù)據(jù)和掌握信息逐層向上傳遞。每一對相鄰層之間都有接口。接口定義了下層供給的原語操作和效勞。當網(wǎng)絡設計者在打算一個網(wǎng)絡應包含多少層，每一層應當做什么的時候，其中很重要的工作是在相鄰層之間定義清楚的接口。接口可以使得同一層能輕易地用某一種實現(xiàn)〔Implementation〕來替換另一種完全不同的實現(xiàn)〔如用衛(wèi)星信道來代替全部的線〕，只要的實現(xiàn)能[Tanenbaum1998]碩士碩士〔2-3年〕考 上本科〔4年〕5-6本科〔4年〕復習報秀才秀才中學〔6年〕私塾私塾舉人舉人圖5.1〔a〕從小學讀到博士存在的五個學習階段5.1〔b〕進的學問構造應用層應用層應用層表示層表示層會話層表示層表示層會話層主機A 主機A會話層網(wǎng)絡層傳輸層主機B傳輸層網(wǎng)絡層網(wǎng)絡層傳輸層主機B傳輸層網(wǎng)絡層數(shù)據(jù)鏈路層數(shù)據(jù)鏈路層數(shù)據(jù)鏈路層物理層物理層物理層物理層5.2計算機網(wǎng)絡的OSI三、其它的層次構造目前在大型商業(yè)應用軟件系統(tǒng)中還流行一種包含中間件〔Middleware〕的層次構造，如圖5.3所示[Jacobson1997DCOMCORBAApplicationSystemsBusiness-specificComponentsMiddlewareSystemSystemSoftware5.3包含中間件的層次構造客戶機/效勞器構造〔AlexanderGrahamBell〕于1876年申請了專利。那時期的必需一對一對地賣，用戶自己在兩個之間拉一根線。假設一個用戶想和其它幾個用戶通話，他必需拉n于是在很短的時間，城市里處處都是穿過房屋和樹木的混亂的線。很明顯，企圖把全部的完全互聯(lián)〔如圖5.4〔a〕所示〕是行不通的。貝爾公司在1878年開辦了第一個交換局。公司為每個客戶架設一條線。打時，客戶搖動的曲柄使公司辦公室的鈴響起來，操作員聽到鈴聲以后依據(jù)要求將呼叫方和被呼叫方用跳線手工連接起來。這種集換式的模型如圖5.4〔b〕交換局所示。很快地，貝爾系統(tǒng)的交換局就消滅在各地。人們又要求能打城市間的長途，就消滅了二級交換局，以后進一[Tanenbaum1998]交換局5.4〔a〕完全互聯(lián)的系統(tǒng) 5.4〔b〕集換式的系統(tǒng)假設將圖5.4〔b〕中的看成是客戶程序，將中心的交換局看成是效勞程序，那么圖5.4〔b〕就是典型的客戶機/效勞器構造。留意這里客戶機和效勞器都是指軟件而不是指硬件〔一臺計算機可以放多個客戶機和效勞器軟件〕客戶機/效勞器構造存在兩個明顯的優(yōu)點：以集中的方式高效率地治理通訊。前面講系統(tǒng)的故事就是要說明這一點?？梢怨蚕碣Y源。比方在信息治理系統(tǒng)中，效勞器將信息集中起來，任何客戶機都可以通過訪問效勞器而獲得所需的信息?？蛻魴C和效勞器之間的通訊以“懇求——響應”的方式〔Request再響應〔Response〕這個懇求，如圖5.5懇求客戶機 效勞器響應5.5Client和Server之間的通訊以“懇求——響應”的方式進展承受“懇求——響應”這種通訊方式的根本動機是為了解決“聚攏”〔Rendezvous〕問題。為了理解這一個問題，設想一個人試圖在分別的機器上啟動兩個程序并讓它們進展通訊。還需記住，計算機的運行速度要比人的操作速度高出很多數(shù)量級。在他啟動第一個程序后，該程序開頭執(zhí)行并向對等程序發(fā)送消息。在幾個微秒，它便覺察對等程序還不存在，于是就發(fā)出一條錯誤消息，然后退出。此后，他啟動了其次個程序。不幸的是，當其次個程序開頭執(zhí)行時，它也找不到第一個程序〔早已退出。即使這兩個程序連續(xù)地重試著通訊，但由于它們的執(zhí)行速度那么高，以致于它們在同一瞬間聯(lián)系上的概率格外低。在客戶機/效勞器構造中，效勞器在啟動后必需〔無限期地〕等待客戶機在Internet/Intranet領域，目前“掃瞄器—Web服務器—數(shù)據(jù)庫效勞器”構造是一種格外流行的客戶機/效勞器構造，如圖5.6機統(tǒng)一承受掃瞄器，這不僅讓用戶使用便利，而且使得客戶機端不存在維護的問題。固然，軟件開公布和維護的工作不是自動消逝了，而是轉移到了WebWeb效勞器端，程序員要用腳本語言編寫響應頁面。例如用Microsoft的ASPWeb頁面中，再由掃瞄器顯示出來。Web效勞器ASPEngineWeb效勞器ASPEngine12/46懇求掃瞄器19/46查詢響應5.6Web效勞器—數(shù)據(jù)庫效勞器”構造模塊設計在設計好軟件的體系構造后，就已經(jīng)在宏觀上明確了各個模塊應具有什么功能，應放在體系構造的哪個位置。我們習慣地從功能上劃分模塊，保持“功能獨立”是模塊化測試、維護等階段的代價。但是“功能獨立”并不意味著模塊之間保持確定的孤立。一個系統(tǒng)要完成某項任務，需要各個模塊相互協(xié)作才能實現(xiàn)，此時模塊之間就要進展信息溝通。比方手和腳是兩個“功能獨立”的模塊。沒有腳時，手照樣能干活。沒有手時，腳仍可以走路。但假設期望跑得快，那么邁左腳時肯定要伸右臂甩左臂，邁右腳時則要伸左臂甩右臂。在設計一個模塊時不僅要考慮“這個模塊就本節(jié)將論述評價模塊設計優(yōu)劣的三個特征因素：“信息信息隱蔽天的同學能象中間打牌的同學那么安靜，就不會影響到前這個故事告知我們，假設不想讓壞事傳播開來，就應當量避開某個模塊的行為去干擾同一系統(tǒng)中的其它模塊，在設計模塊時就要留意信息隱蔽。應當讓模塊僅僅公開必需要讓外界知道的容，而隱蔽其它一切容。模塊的信息隱蔽可以通過接口設計來實現(xiàn)。一個模塊僅供給有限個接口〔Interface，執(zhí)行模塊的功能或與模塊溝通信息必需且只須通過調用公有接口來實現(xiàn)。假設模塊是一個C+有函數(shù)。假設模塊是一個COM口就是COM對象的接口。一個COM對象可以有多個接口，而每個接口實質上是一些函數(shù)的集合。[Rogerson1999]美國或許是世界上丑聞最多的國家，由于它追求，不懂化設計的方法都是美國人提倡的，他們應當很懂得“隱蔽聚與耦合聚〔Cohesion〕是一個模塊部各成分之間相關聯(lián)程度的度量。耦合〔Coupling〕是模塊之間依靠程度的度量。聚和耦合是親熱相關的，與其它模塊存在強耦合的模塊通常意味著弱聚，而強聚的模塊通常意味著與其它模塊之間存在弱耦合。模塊設計追求強聚，弱耦合。一、聚強度聚按強度從低到高有以下幾種類型：偶然聚。假設一個模塊的各成分之間毫無關系，則稱為偶然聚。規(guī)律聚。幾個規(guī)律上相關的功能被放在同一模塊中，則稱為規(guī)律聚。如一個模塊讀取各種不同類型外設的輸入。盡管規(guī)律聚比偶然聚合理一些，但規(guī)律聚的模塊各成分在功能上并無關系，即使局部功能的修改有時也會影響全局，因此這類模塊的修改也比較困難。時間聚。假設一個模塊完成的功能必需在同一時間執(zhí)行〔如系統(tǒng)初始化一起，則稱為時間聚。過程聚。假設一個模塊部的處理成分是相關的，而且這些處理必需以特定的次序執(zhí)行，則稱為過程聚。通信聚。假設一個模塊的全部成分都操作同一數(shù)據(jù)集或生成同一數(shù)據(jù)集，則稱為通信聚。挨次聚。假設一個模塊的各個成分和同一個功能親熱相關，而且一個成分的輸出作為另一個成分的輸入，則稱為挨次聚。功能聚。模塊的全部成分對于完成單一的功能都是必須的，則稱為功能聚。二、耦合強度耦合的強度依靠于以下幾個因素：〔1〕一個模塊對另一一個模塊向另一個模塊傳遞的數(shù)據(jù)量；〔3〕一個模塊施加到另一個模塊的掌握的多少；〔4〕模塊之間接口的簡單程度。耦合按從強到弱的挨次可分為以下幾種類型：容耦合。當一個模塊直接修改或操作另一個模塊的數(shù)據(jù),或者直接轉入另一個模塊時，就發(fā)生了容耦合。此時，被修改的模塊完全依靠于修改它的模塊。公共耦合。兩個以上的模塊共同引用一個全局數(shù)據(jù)項就稱為公共耦合。掌握耦合。一個模塊在界面上傳遞一個信號〔如開關值、標志量等〕掌握另一個模塊，接收信號的模塊的動作依據(jù)信號值進展調整，稱為掌握耦合。標記耦合。模塊間通過參數(shù)傳遞簡單的部數(shù)據(jù)構造，稱為標記耦合。此數(shù)據(jù)構造的變化將使相關的模塊發(fā)生變化。數(shù)據(jù)耦合。模塊間通過參數(shù)傳遞根本類型的數(shù)據(jù)，稱為數(shù)據(jù)耦合。非直接耦合。模塊間沒有信息傳遞時，屬于非直接耦合。假設模塊間必需存在耦合，就盡量使用數(shù)據(jù)耦合，少用掌握耦合，限制公共耦合的圍，堅決避開使用容耦合。封閉——開放性假設一個模塊可以作為一個獨立體被其它程序引用，則稱模塊具有封閉性。假設一個模塊可以被擴大，則稱模塊具有開放性。從字面上看，讓模塊具有“封閉——開放性”是沖突的，但這種特征在軟件開發(fā)過程中是客觀存在的。當著手一個問題時，我們很難一次性解決問題。應領先縱觀問題的一些重要方面，同時作好以后補充的預備。因此讓模塊存我們不能等到完全把握解決問題的信息后再把程序做成別人能用的模塊。模塊的“封閉——開放性”實際上對應于軟件質量因素中的可復用性和可擴大性。承受面對過程的方法進展程序設計，很難開發(fā)出既具有封閉性又具有開放性的模塊。采用面對對象設計方法可以較好地解決這個問題。數(shù)據(jù)構造與算法設計學會設計數(shù)據(jù)構造與算法，可以讓我們編寫出高效率的程序?；蛟S有人要問，在計算機速度日月異的今日，為什么還需要高效率的程序？由于我們的雄心與力量是一起增長的，技術進步最快也快不過人們欲望的增長。計算速度和存儲容量上的革僅僅供給了處理更簡單問題的有效工具，所以高效率的程序永久不會過時。設計高效率的程序是基于良好的數(shù)據(jù)構造與算法，而不是基于編程小技巧。大多數(shù)計算機科學系在設置課程時，都重視學習根本的軟件工程原理，以與數(shù)據(jù)構造與算法設計。一般說來，數(shù)據(jù)構造與算法就是一類數(shù)據(jù)的表示與其相〕。從數(shù)據(jù)表示的觀點來看，存儲在數(shù)組中的一個有序整數(shù)表也是一種數(shù)據(jù)構造。算法是指對數(shù)據(jù)構造施加的一些操作，例如對一個線性表進展檢索、插入、刪除等操作。一個算法假設能在所要求的資源限制〔ResourceConstraints〕圍將問題解決好，則稱這個算法是有效率〔Efficient〕的。例如一個資源限制可能是“用于存儲數(shù)據(jù)的存有限”，或者“允許算法所需要的資源都少，這個算法也被稱為是有效率的。算法的代價〔Cost〕是指消耗的資源量。一般說來，代價是由一個關鍵資源例如時間或空間來評估的。毋庸置疑，人們編寫程序是為了解決問題。只有通過預先分析問題來確定必需到達的性能目標，才有期望選擇出正確的數(shù)據(jù)構造。有相當多的程序員無視了這一分析過程，而直接選用某一個他們習慣使用的，但是與問題不相稱的數(shù)據(jù)構造，結果設計出一個低效率的程序。假設使用簡潔的設計就能夠到達性能目標時，選用簡單的數(shù)據(jù)構造也是沒有道理的。人們對常用的數(shù)據(jù)構造與算法的爭論已經(jīng)相當透徹，可以歸納出一些設計原則：每一種數(shù)據(jù)構造與算法都有其時間、空間的開銷和收益。當面臨一個的設計問題時，設計者要徹底地把握怎樣權衡時空開銷和算法有效性的方法。這就需要懂得算法〔例如，數(shù)據(jù)存儲在磁盤上與存儲在存中，就有不同的考慮〕。與開銷和收益有關的是時間——空間的權衡。通?？梢杂酶蟮臅r間開銷來換取空間的收益，反之亦然。時間——空間的權衡普遍地存在于軟件開發(fā)的各個階段中。程序員應當充分地了解一些常用的數(shù)據(jù)構造與算法，避開不必要的重復設計工作。數(shù)據(jù)構造與算法為應用效勞。我們必需先了解應用的需求，再查找或設計與實際應用相匹配的數(shù)據(jù)構造。[Shaffer1998]用戶界面設計某個人總有方法讓自己保持心情開心、信念十足。有一天，他向一名圍棋九段和一名乒乓球世界冠軍挑戰(zhàn)，結果他全勝了。由于他跟圍棋九段打乒乓球，跟乒乓球冠軍下圍棋。用戶界面的編程技術是人們生疏得不得了的事，我打算講一講比較生疏的“用戶界面設計美學”。有位愛好書畫的博士后請我賞識鋼琴演奏會。我從頭到尾只聽到“叮叮咚咚”的聲音，實在享受不到“高雅”，就請這位朋友教導。他雖然也不懂鋼琴，卻從賞識書法的角度設法解釋如何賞識音樂?？墒俏壹炔欢畷ㄒ膊欢魳?，特別寵愛編寫用戶界面程序，并且常向同學演示、賣弄。我覺得還不過癮，就寫了一篇“用戶界面設計美學”的短文[林銳1997]。但凡路過我試驗室的同學都被我逮住，被迫聽完我得意之極的朗讀，茫然者與苦痛者居多。不久我的朗讀便所向披糜，聽見者逃之夭夭?，F(xiàn)在我又把那篇短文摘錄至此，請您忍著點吧。界面設計中美的需求與導向作用人們對美的向往和追與生俱有的。明顯沒有人情愿丑化自己的程序，也沒有用戶嗜好丑陋的界面。軟件開發(fā)者要設計美，用戶要享受美，所以界面的美是開發(fā)者與用戶的共同需求。界面美的概念很抽象，以致讓人無法說清楚什么是界面的美。但它同時又很現(xiàn)實，以致人人都可以去賞識和感受界面美，并且挑剔美中之缺乏。美學不是一種量化的學問，假設因此而輕視美學指導，必將導致在設計過程中光依靠程序員個人的閱歷與感覺。由于程序員承受的教育主要是如何使計算機完成工作，而不是人如何工作，因此僅靠程序員主觀想象設計而成的界面往往得不到群眾用戶的認可。美的界面能消退用戶由感覺引起的乏味、緊和疲乏〔心情低落戶技能和為用戶完成任務作出奉獻。從人機界面進展歷史與趨勢上可以看出人們對界面美的需求，以與美在界面設計中的導向作用。界面設計已經(jīng)經(jīng)受了兩個界限清楚的時代。第一代是以文本為根底的簡潔交互，如常見的命令行，字符菜單等。由于第一代界面考慮人的因素太少，用戶興趣不高。隨著技術的進展，消滅了其次代直接操縱的界面。它大量使用圖形、語音和其它交互媒介，充分地考慮了人對美的需求。直接操縱的界面使用視聽、觸摸等技術，讓人可以憑借生活常識、經(jīng)受和推理來操縱軟件，開心地完成任務。更高層次的界面甚至模擬了人的生活空間，例如虛擬現(xiàn)實環(huán)境。界面的美充分表達了人機交互作用中人的特性與意圖，越來越多的用戶將通過具有吸引力而令人開心的人機界面與計算機打交道。界面美的涵一、界面的適宜性界面的適宜性是指界面是否與軟件功能相融洽。假設界面不適合于軟件的功能，那么界面將毫無用處，界面美的涵就無從談起。所以界面的適宜性是界面美的首要因素，它提示設計者不要片面追求外觀秀麗而導致失真或華而不實。界面的適宜性既提倡外美秀，又強調恰如其分。適宜性差的界面無疑會混淆軟件意圖，致使用戶產(chǎn)生誤會。即使它不損害軟件功能與性能，也會使用戶產(chǎn)生不該有的心情波動。例如一些軟件開發(fā)者寵愛為其作品加一段動畫演示，以便吸引更多用戶的關注。這本是無可非議的，問題在于這演示是否合情合理。假設運行一個程序，它首先表演一套簡單的動畫，在后臺演奏雄壯的進展曲，電閃雷鳴之后出來的卻是一個一般的文本編輯器。整個過程讓用戶置身于云里霧里，而結果卻讓用戶感到驚諤而不是驚喜。適宜性差的界面只會給軟件帶來厄運。二、界面的風格商業(yè)應用軟件的界面設計留意全都性。設計者必需親熱留意在一樣應用領域中最流行的軟件的界面，必需敬重用戶使用這些軟件的習慣。例如商業(yè)軟件習慣于設置F1鍵為幫助熱鍵，假設某個設計者別出心裁地讓F1鍵成為程序終止的熱鍵，那么在用戶渴望得到幫助而伸手擊F1鍵的一剎那，他的工作就此完蛋。信任這個用戶“一朝被蛇咬，十目前流行的軟件開發(fā)工具如VisualC+VisualBasic、DelphiC++BuilderPowerBuilder等，都能夠快速地開發(fā)出格外相像的圖形用戶界面。在Internet/Intranet領域，掃瞄器幾乎成了唯一的客戶機程序，由于用戶期望用完全全都的軟件來完成千變萬化的應用任務。在消遣領域的軟件中，有共性化的界面自然比泯然于眾的界面更具有吸引力。一般說來，計算機專業(yè)人員玩過的軟件不計其數(shù)。界面看多了，真有種“曾經(jīng)滄海難為水”的感覺。不過當我看到一個叫Sonique的放音樂的軟件時，不禁對其界面的創(chuàng)意嘖嘖贊揚，忍不住象貼美女像那樣把它貼到書中，如圖5.75.7Sonique軟件的幾種界面25/4630/46幾片遮羞布。而當大家都赤條條地在共公浴室洗澡時，卻也有人寵愛穿著衣服。三、界面的廣義美盡管界面的美并沒有增加軟件的功能與性能，卻又是必為可少的。用戶使用界面時，除了直接的感官美感外，還有很大一局部美感是間接的，它們存在于人們的使用體驗中，例如便利，有用等。與圖形用戶界面相比，命令行是最原始的界面，它難記又難看。但對于嫻熟的用戶而言，他們樂于使用命令行以獲得高效率。命令行因具有高效率而贏得了專業(yè)人士的寵愛，早期的Unix系統(tǒng)就是徹頭徹尾的命令系統(tǒng)?？梢哉f，一切有利于人機交互的界面設計因素都具有廣義美。界面設計的一些特別考慮也表達了廣義美，如設法使殘障人也可以使用軟件。IBM公司在1985年已經(jīng)創(chuàng)立了殘障Apple公司的特地教育辦公室則供給了一些有利于殘障人使用的計算機信息產(chǎn)品。系統(tǒng)設計例如——支持協(xié)同工作的交互式三維圖形軟件開發(fā)系統(tǒng)本節(jié)論述“支持協(xié)同工作的交互式三維圖形軟件開發(fā)系統(tǒng)”的系統(tǒng)設計，作為本章的例如〔取材于作者的博士論文工作[林銳2023]。設計背景圖形標準在圖形領域有著重要的地位，它不僅加速了3D應用程序的開發(fā)，而且使3D應用程序的可移植性更好。歷史上曾消滅的圖形標準〔或API〕有Core、GKS、PHIGS、PEX、GL、Dore、RenderManHoops、OpenGL等等。經(jīng)過競爭與淘汰，目前OpenGL成為國際上公認的3D圖形工業(yè)標準，在Unix與PCOpenGL供給了數(shù)百個庫函數(shù)，可以便利地繪制具有真實感的3D圖形。但是在開發(fā)交互式的3D圖形應用程序時，圖形的繪制只是一局部工作，更多的工作集中在場景數(shù)據(jù)構造、圖形對象、三維交互和圖形用戶界面的設計上。由于OpenGL與窗口系統(tǒng)無關，不供給任何交互手段，必須由程序員自己編寫全部的交互功能。并且OpenGL的編程接口是低級的C序框架，開發(fā)效率不高。為了抑制這些困難，人們往往在(3DToolkit3DEngine)OpenGL的著名的開發(fā)工具有OpenInventorIRISPerformerOptimeizer/Cosmo3D以與GLUT等等。OpenInventor被譽為是交互式3D但明顯沒有一個3D開發(fā)工具能滿足全部的應用需求，3D的廣泛應用需要更多的開發(fā)工具支持。隨著計算機圖形技術與網(wǎng)絡技術的迅猛進展，兩者的結合勢在必行。在商業(yè)、科研、教育、消遣等領域，用于分〔DistributedVirtualEnvironments,DVEs〕和計算機支持協(xié)同工作〔ComputerSupportedCooperativeWork,CSCW〕的圖形系統(tǒng)已成為爭論與應用的熱點。著名DVEs系統(tǒng)有DIVEdVSMRRepo-3D等。但是這些DVEs系統(tǒng)缺乏3D開發(fā)工具的交互式圖形功能以與通用性，而通用的3D開發(fā)工具如OpenInventor則又不支持分布式計算和協(xié)同工作。由于在窗口系統(tǒng)、圖形支撐庫、編程語言等方面存在差異，上述DVEs系統(tǒng)和3D開發(fā)工具難以便利地結合使用。我們多方面分析了3D需求與軟硬件條件，研制完成運行于PC平臺，支持協(xié)同工作的交互式三維圖形軟件開發(fā)系5.8〔1〕Intra3D2.0是基于OpenGL的通用交互式三維圖形軟件開發(fā)工具，可用于快速開發(fā)Window9x/NT下的交互式三維圖形應用軟件?！?〕CNC1.0是支持協(xié)同工作的網(wǎng)絡通訊開發(fā)系統(tǒng)〔CooperativeNetworkCommunicator—訂閱模式”與“組播模式”的效勞器與API。結合Intra3D2.0和CNC1.0工作的交互式三維圖形應用軟件。通用交互式三維圖形軟件開發(fā)工具Intra3D通用交互式三維圖形軟件開發(fā)工具Intra3D2.0CNC1.05.8支持協(xié)同工作的交互式三維圖形軟件開發(fā)系統(tǒng)通用交互式三維圖形軟件開發(fā)工具Intra3D2.0Intra3D2.0的核心是集成了場景數(shù)據(jù)構造、圖形對象、三維交互算法和圖形用戶界面的C++類庫與CO〔ComponentObjectModel〕VisualC++、VisualBasic、Delphi等語言的應用編程。Intra3D的核心庫分四層創(chuàng)立：第一層為“根底對象與函數(shù)”〔BasicObjectsandFunctions；〔GraphicalObjects；〔SceneGraphandNodes；〔4〕〔RenderingandInteraction。體系構造如圖5.9所示，其中高層構件可以引用低層構件，但低層構件不能引用高層構件。44、繪制與交互層Intra3DC++類庫3、場景的圖與節(jié)點層Intra3DCOM庫2、圖形對象層1、根底對象與函數(shù)層1、根底對象與函數(shù)層Window9x/NT + OpenGL + VisualC++Window9x/NT + OpenGL + VisualC++5.9Intra3D2.0的體系構造Intra3D2.0是免費軟件，有配套書籍《交互式三維圖形技術與程序設計》。標準版軟件約25兆，核心庫7萬多行C+需求。主要模塊和功能一、根底對象與函數(shù)層定義了用于對象引用計數(shù)的存治理基類；矢量、矩陣與四元組運算，鼠標跟蹤球算法；點陣字體與三維矢量字體輸出，常用于數(shù)據(jù)可視化圖形的數(shù)據(jù)標注；圖像輸入輸出以與紋理映射，支持BMP、GIF、JPEG、SGI、TGA常用幾何圖元的繪制，如錐、柱、球、環(huán)等，并支持Swept供給450余種材質，在第四層中可以交互式編輯這些材質。二、圖形對象層圖形對象能將數(shù)據(jù)轉化為幾何模型并可以繪制出來。Intra3D2.0常用幾何對象，如長方體、錐體、圓柱體、球體、圓環(huán)體、Swept多邊形模型對象，可用于繪制Autodesk公司.3ds模Wavefront公司的.obj商業(yè)統(tǒng)計圖形對象，如柱形圖、帶狀圖、條形圖、折線圖、面積圖、餅圖、塔形圖、曲線圖、曲面圖、進程圖、股票圖等。圖形對象的開發(fā)與應用問題親熱相關，用戶可以使用繼承方法擴大的圖形對象，而不會影響到其它三層的構件。三、場景圖與節(jié)點場景圖〔SceneGraph〕SceneGraph的主要節(jié)點有：1〕SceneNode是全部節(jié)點的基類。在SceneNode中定義了局部坐標系以與相應的圖形變換，這樣便于第四層以同樣的操作方式實現(xiàn)三維交互?！?〕相機節(jié)點〔CameraNode〕支持平行投影與透視投影，支持多個相〔3〕(DirLightNode)、點光源節(jié)點(PointLightNode)和錐光源節(jié)點(SpotLightNode)〔4〕形體節(jié)點〔ShapeNode〕用于引用圖形對象，有關圖形對象的三維交互均由 處理。四、繪制與交互層Intra3D的交互分兩類：一類是對形體、光源和相機的直接操作，另一類是真實感屬性的編輯。Intra3D的場景視圖構件〔SceneView〕封裝了交互式繪制的全部細節(jié)，如消息處理、場景節(jié)點的遍歷繪制、多重采樣消鋸齒、鼠標交互等Intra3D〔FontDialog〔ColorDialog、材質庫對話〔MaterialLibDialog、材質對話〔MaterialDialog〕與光源對話〔DirLightDialog,PointLightDialog,SpotLightDialog。用戶界面設計Intra3DSceneView式3D應用程序的主界面。SceneView支持selectingscalingrotatingtranslating、creatingdeleting等三十余種操作，并供給工具條便利于交互，如圖5.10所示。為了編輯真實感屬性，常需在對話框中繪制3D圖形。Microsoft的窗口系統(tǒng)不供給3DIntra3DWindow3D構件可在對話框中創(chuàng)立多個3D視圖，圖5.11的材質對話和圖Window3D件。顏色編輯是3D圖形程序中最常用的交互，材質與光源的編輯實際上是通過轉變顏色重量來實現(xiàn)的。需要進展顏色編輯的交互均涉與HSV與RGB模式的顏色轉換。Intra3D的“繪制與交互層”實現(xiàn)了這些計算，并且供給彩色的滑動條用于鼠標交互。圖5.135.14分別為點光源對話和顏色對話。5.10用于直接操作的三維交互工具條圖5.11材質對話 圖5.12材質庫對話34/465.13點光源對話圖5.14顏色對話支持協(xié)同工作的網(wǎng)絡通訊開發(fā)系統(tǒng)CNC1.0最簡潔的協(xié)同工作模式是讓兩個客戶機直接通訊，可以Socket編程實現(xiàn)。假設有n個客戶機參與協(xié)同工作，每個客戶機將與全部其它的客戶機通訊。那么總共存在n(n-1)/2個Socket導致其它客戶機的修改。這種Socket直接通訊使得協(xié)同工作的治理和客戶機的程序設計變得格外困難。CNC系統(tǒng)供給了支持“公布—訂閱〔Publish-Subscribe”與“組播〔Multicast”模式的效勞器與API，可以高效地治理多個組群的協(xié)同工作，并使得客戶機的程序設計格外簡潔。CNC1.05.1535/4638/46CNC效勞器將客戶機分組治理。在“公布—訂閱”模式中，將產(chǎn)生數(shù)據(jù)的進程稱為生產(chǎn)者〔Producer，將承受數(shù)據(jù)的進程稱為消費者〔Consumer。生產(chǎn)者可以向效勞器公布數(shù)據(jù)，效勞器保存這些數(shù)據(jù)。消費者可以向效勞器訂閱數(shù)據(jù)。每個客戶機可能是很多數(shù)據(jù)的生產(chǎn)者或消費者。同一時刻，CNC系統(tǒng)允許有任意多個生產(chǎn)者和消費者存在。CNC的“公布—訂閱”功能是用TCP在“組播”模式中，效勞器動態(tài)地安排每個組的組播地址。客戶機可以向效勞器申請參加任意組，允許向任意組播放消息，效勞器不保存這些組播消息。CNC的“組播”UDPCNC效勞器

CNC API公布—訂閱模式

CNC客戶機UDP協(xié)議的組播模式5.15CNC1.0的系統(tǒng)構造CNC客戶機的API類CNCClient功能，主要接口〔公有函數(shù)〕如下：classCNCClient{public:BOOLConnect(//BOOLDisconnect;//BOOLPublishData(…);//向效勞器公布數(shù)據(jù)BOOLQueryData(…);//向效勞器查詢數(shù)據(jù)BOOLSubscribeData(…);//向效勞器訂閱數(shù)據(jù)GROUPIPQueryGroupIP(…); //向效勞器查詢組播地址DWORDMulticastMessage(…);//發(fā)送組播消息virtualvoidMessageResponse();//響應組播消息…};一、客戶程序的“公布”協(xié)議客戶機向效勞器公布的每個數(shù)據(jù)報均含有數(shù)據(jù)類型、工作組名稱、數(shù)據(jù)名稱、生命期和數(shù)據(jù)長度的信息。報文格式如圖5.16所示，數(shù)據(jù)構造見DataPublish：structDataPublish{BYTEiDataType; //2個字節(jié)數(shù)據(jù)類型，宏定義為DATA_PUBLISHchar strGroupName[16];//16個字節(jié)的工作組名字char strDataName[16]; //16個字節(jié)的數(shù)據(jù)名字DWORDdwLifeTime; //4個字節(jié)的數(shù)據(jù)生命期，以秒為單位DWORDdwLength; //4個字節(jié)的數(shù)據(jù)容的長度char *pchContent; //數(shù)據(jù)容};2字節(jié) 16字節(jié)16字節(jié) 4字節(jié) 4字節(jié)datatype groupname dataname lifetime length content5.16用于公布的報文格式二、客戶程序的“訂閱”協(xié)議客戶機向效勞器訂閱數(shù)據(jù)分兩步實現(xiàn)：先調用函數(shù)QueryData向效勞器發(fā)送一個DataQuery格式的報文，用于查詢要訂閱的數(shù)據(jù)是否存在。structDataQuery{BYTE iDataType; //2個字節(jié)數(shù)據(jù)類型，宏DATA_QUERYcharstrGroupName[16]; //16名字charstrDataName[16]; //16字};〕效勞器接收到查詢時，依據(jù)DataQuery構造中的strGroupName和strDataName進展搜尋。假設該數(shù)據(jù)不存在，Server向Client發(fā)送一個FALSE存在，效勞器先向客戶機發(fā)送一個TRUE標志，之后馬上再向客戶機發(fā)送該數(shù)據(jù)〔DataPublish格式。假設客戶機得到TRUE標志的查詢結果，就調用函數(shù)SubscribeData三、客戶程序的“組播”協(xié)議客戶機先調用函數(shù)QueryGroupIP向效勞器發(fā)送一個GroupAddress回相應的十進制點分式的IPstructGroupAddress{BYTE iDataType; //2個字節(jié)數(shù)據(jù)類型，宏GROUP_ADDRESScharstrGroupName[16]; //16名字};客戶機調用函數(shù)MulticastMessage向指定的組〔依據(jù)組播地址〕播放消息。組播的數(shù)據(jù)報構造DataMulticast定義如下：structDataMulticast{DWORDdwContentType;//組播的數(shù)據(jù)報類型，由用戶定義char *pchContent; //組播的數(shù)據(jù)報容，由用戶定義};假設客戶機接收到組播的消息，將自動調用函數(shù)MessageResponseMessageResponse數(shù)，它將依據(jù)dwContentType信息打算如何處理到來的組播消息，具體功能由用戶定義。CNC效勞器的設計一、數(shù)據(jù)構造CNC效勞器的數(shù)據(jù)構造主要由三局部組成：一用于治理組播地址的鏈表。組播地址由效勞器動態(tài)生成，客戶機可以向效勞器查詢任意組的組播地址。一用于治理線