軟件工程思想5
第五章 系 統 設 計 系統設計是把需求轉化為軟件系統的最重要的環(huán)節(jié)。系統設計的優(yōu)劣在根本上決定了 軟件系統的質量。就象“一切帝國主義都是紙老虎”那樣可以斷定“差的系統設計必定產生 差的軟件系統?！彼晕覀円ΡＷC系統設計“根正苗紅”，把一切左傾、右傾的設計思 潮消滅在萌芽狀態(tài)。 Windows NT的一位系統設計師擁有8輛法拉利跑車，讓Microsoft公司的一些程序員十分眼紅。但 你只能羨慕而不能憤恨，因為并不是每個程序員都有本事成為復雜軟件系統的設計師。 系統設計要比純粹的編程困難得多。即便你清楚客戶的需求，卻未必知道應該設計什么 樣的軟件系統——既能掙最多的錢又能讓客戶滿意。“天下西湖三十六，最美是杭州”，千 年前蘇東坡大學士對西湖精采絕倫的系統設計，使杭州榮升為“天堂”，讓后人只剩下贊 嘆和破壞的份了。 本章講述系統設計的四方面內容：體系結構設計、模塊設計、數據結構與算法設計、 用戶界面設計。如果將軟件系統比喻為人體，那么： （1）體系結構就如同人的骨架。如果某個家伙的骨架是猴子，那么無論怎樣喂養(yǎng)和美容 ，這家伙始終都是猴子，不會成為人。 （2）模塊就如同人的器官，具有特定的功能。人體中最出色的模塊設計之一是手，手只 有幾種動作，卻能做無限多的事情。人體中最糟糕的模塊設計之一是嘴巴，嘴巴將最有 價值但毫無相干的幾種功能如吃飯、說話、親吻混為一體，使之無法并行處理，真乃人 類之不幸。 （3）數據結構與算法就如同人的血脈和神經，它讓器官具有生命并能發(fā)揮功能。數據結 構與算法分布在體系結構和模塊中，它將協調系統的各個功能。人的耳朵和嘴巴雖然是 相對獨立的器官，但如果耳朵失聰了，嘴巴就只能發(fā)出“啊”“嗚”的聲音，等于喪失了說 話的功能（所以聾子天生就是啞巴），可人們卻又能用手勢代替說話。人體的數據結構 與算法設計真是十分神奇并且十分可笑。 （4）用戶界面就如同人的外表，最容易讓人一見鐘情或一見惡心。象人類追求心靈美和 外表美那樣，軟件系統也追求（內在的）功能強大和（外表的）界面友好。但隨著生活 節(jié)奏的加快，人們已少有興趣去品味深藏不露的內在美。如果把Unix系統比作是健壯的 漢子和婦人，那么Windows系統就象嫵媚的小白臉和狐貍精。想不到Windows系統竟然能 興風作浪，占去大半市場。有鑒于此，我們應該鼓勵女士多買化妝品（男士付錢）以獲 得更好的界面。 在進行系統設計時，我們要深情地關注軟件的質量因素，如正確性與精確性、性能與 效率、易用性、可理解性與簡法性、可復用性與可擴充性等等。即使把系統設計做好了 ，也并不意味著就能產生好的軟件系統。在程序設計、測試、維護等環(huán)節(jié)還要做大量的 工作，無論哪個環(huán)節(jié)出了差錯，都會把好事搞砸了。據說上帝把所有的女士都設計成天 使，可是天使們在下凡時有些雙腳先著地，有些臉先著地。上帝的這一疏忽讓很多女孩 傷透了心。我們在開發(fā)軟件時，一定要吸取這個教訓。 5.1 體系結構設計 楊叔子院子曾這樣指點其弟子： 文學中有科學，音樂中有數學，漫畫中有現代數學的拓撲學。漫畫家可以“幾筆”就把 一個人畫出來，不管怎么美化或丑化，就是活像。為什么？因為那“幾筆”不是別的，而 是拓撲學中的特征不變量，這是事物最本質的東西。 體系結構是軟件系統中最本質的東西： （1）體系結構是對復雜事物的一種抽象。良好的體系結構是普遍適用的，它可以高效地 處理多種多樣的個體需求。一提起“房子”，我們的腦中馬上就會出現房子的印象（而不 是地洞的印象）。“房子”是人們對住宿或辦公環(huán)境的一種抽象。不論是辦公樓還是民房 ，同一類建筑物（甚至不同類的建筑物）之間都具有非常相似的體系結構和構造方式。 如果13億中國人民每個人都要用特別的方式構造奇異的房子，那么960萬平方公里的土地 將會變得千瘡百孔，終日不得安寧。 （2）體系結構在一定的時間內保持穩(wěn)定。只有在穩(wěn)定的環(huán)境下，人們才能干點事情，社 會才能發(fā)展。科學告訴我們，宇宙間萬物無時無刻不在運動、飛行。由于我們的生活環(huán) 境在地球上保持相對穩(wěn)定，以致于我們可以無憂無慮地吃飯和睡覺，壓根就意識不到自 己是活生生的導彈。軟件開發(fā)最怕的就是需求變化，但“需求會發(fā)生變化”是個無法逃避 的現實。人們希望在需求發(fā)生變化時，最好只對軟件做些皮皮毛毛的修改，可千萬別改 動軟件的體系結構。就如人們對住宿的需求也會變動，你可以經常改變房間的裝璜和擺 設，但不會在每次變動時都要去折墻、拆柱、挖地基。如果當需求發(fā)生變化時，程序員 不得不去修改軟件的體系結構，那么這個軟件的系統設計是失敗的。 良好的體系結構意味著普適、高效和穩(wěn)定。本節(jié)將論述兩種非常通用的軟件體系結構 ：層次結構和客戶機/服務器（Client/Server）結構。 5.1.1 層次結構 層次結構表達了這么一種常識：有些事情比較復雜，我們沒法一口氣干完，就把事情 分為好幾層，一層一層地去做。高層的工作總是建立在低層的工作之上。層次關系主要 有兩種：上下級關系和順序相鄰關系。 一、上下級關系的層次結構 我們從小學一直讀到博士研究生畢業(yè)，要讀20多年，可以分為五個層次。而范進的知 識結構只有兩層：“私塾”和“秀才”，但讀了五十多年，如圖5.1所示。一般地處于較高層 次的學生應該懂得所有低層次的知識，而處于低層次學生無法懂得所有高層次的知識。 圖5.1的層次結構存在上下級關系，如同在軍隊中，上級可以命令下級，而下級不能命令 上級。如果把圖5.1的層次結構當成是一個軟件系統的結構，那么上層子系統可以使用下 層子系統的功能，而下層子系統不能夠使用上層子系統的功能。 二、順序相鄰關系的層次結構 順序相鄰關系的層次結構表明通訊只能在相鄰兩層之間發(fā)生，信息只能被一層一層地 順序傳遞。這種層次結構的經典之作是計算機網絡的OSI參考模型，如圖5.2所示。為了 減少設計的復雜性，大多數網絡都按層（Layer）或級（Level）的方式組織。每一層的 目的都是向它的上一層提供一定的服務，而把如何實現這一服務的細節(jié)對上一層加以屏 蔽。一臺機器上的第n層與另一臺機器上的第n層進行對話。通話的規(guī)則就是第n層的協議 。數據不是從一臺機器的第n層直接傳送到另一臺機器的第n層。發(fā)送方把數據和控制信 息逐層向下傳遞。最低層是物理介質，它進行實際的通訊。接收方則將數據和控制信息 逐層向上傳遞。 每一對相鄰層之間都有接口。接口定義了下層提供的原語操作和服務。當網絡設計者 在決定一個網絡應包含多少層，每一層應當做什么的時候，其中很重要的工作是在相鄰 層之間定義清晰的接口。接口可以使得同一層能輕易地用某一種實現（Implementation ）來替換另一種完全不同的實現（如用衛(wèi)星信道來代替所有的電話線），只要新的實現 能向上層提供同一組服務就可以了。[Tanenbaum 1998] 考上“舉人”時已五十多歲了 復習報考“舉人”用了幾十年 圖5.1（a）從小學讀到博士存在的五個學習階段 圖5.1（b）范進的知識結構 圖5.2 計算機網絡的OSI參考模型 三、其它的層次結構 目前在大型商業(yè)應用軟件系統中還流行一種包含中間件（Middleware）的層次結構， 如圖5.3所示[Jacobson 1997]。中間件支持與平臺無關的分布式計算，可以用DCOM和CORBA對象來實現。 圖5.3 包含中間件的層次結構 5.1.2 客戶機/服務器結構 讓我們先回顧一下早期的電話系統。貝爾（Alexander Graham Bell）于1876年申請了電話專利。那時期的電話必須一對一對地賣，用戶自己在兩個電 話之間拉一根線。如果一個電話用戶想和其它幾個電話用戶通話，他必須拉n根單獨的線 到每個人的房子里。于是在很短的時間內，城市里到處都是穿過房屋和樹木的混亂的電 話線。很明顯，企圖把所有的電話完全互聯（如圖5.4（a）所示）是行不通的。 貝爾電話公司在1878年開辦了第一個交換局。公司為每個客戶架設一條線。打電話時 ，客戶搖動電話的曲柄使電話公司辦公室的鈴響起來，操作員聽到鈴聲以后根據要求將 呼叫方和被呼叫方用跳線手工連接起來。這種集中交換式的模型如圖5.4（b）所示。很 快地，貝爾系統的交換局就出現在各地。人們又要求能打城市間的長途電話，就出現了 二級交換局，以后進一步發(fā)展為多個二級交換局。[Tanenbaum 1998] 5.4（a）完全互聯的電話系統 5.4（b）集中交換式的電話系統 如果將圖5.4（b）中的電話看成是客戶程序，將中心的交換局看成是服務程序，那么 圖5.4（b）就是典型的客戶機/服務器結構。注意這里客戶機和服務器都是指軟件而不是 指硬件（一臺計算機可以放多個客戶機和服務器軟件）。 客戶機/服務器結構存在兩個顯然的優(yōu)點： （1）以集中的方式高效率地管理通訊。前面講電話系統的故事就是要說明這一點。 （2）可以共享資源。比如在信息管理系統中，服務器將信息集中起來，任何客戶機都可 以通過訪問服務器而獲得所需的信息。 客戶機和服務器之間的通訊以“請求——響應”的方式進行?？蛻魴C先向服務器發(fā)起“請 求”（Request），服務器再響應（Response）這個請求，如圖5.5所示。 請求 響應 圖5.5 Client和Server之間的通訊以“請求——響應”的方式進行 采用“請求——響應”這種通訊方式的基本動機是為了解決“聚集”（Rendezvous）問題。 為了理解這一個問題，設想一個人試圖在分離的機器上啟動兩個程序并讓它們進行通訊 。還需記住，計算機的運行速度要比人的操作速度高出許多數量級。在他啟動第一個程 序后，該程序開始執(zhí)行并向對等程序發(fā)送消息。在幾個微秒內，它便發(fā)現對等程序還不 存在，于是就發(fā)出一條錯誤消息，然后退出。此后，他啟動了第二個程序。不幸的是， 當第二個程序開始執(zhí)行時，它也找不到第一個程序（早已退出）。即使這兩個程序連續(xù) 地重新試著通訊，但由于它們的執(zhí)行速度那么高，以致于它們在同一瞬間聯系上的概率 非常低。在客戶機/服務器結構中，服務器在啟動后必須（無限期地）等待客戶機的“請 求”，因此就形成了“請求——響應”的通訊方式。 　　在Internet/Intranet領域，目前“瀏覽器—Web 服務器—數據庫服務器” 結構是一種非常流行的客戶機/服務器結構，如圖5.6所示。這種結構最大的優(yōu)點是：客 戶機統一采用瀏覽器，這不僅讓用戶使用方便，而且使得客戶機端不存在維護的問題。 當然，軟件開發(fā)布和維護的工作不是自動消失了，而是轉移到了Web 服務器端。在Web 服務器端，程序員要用腳本語言編寫響應頁面。例如用Microsoft的ASP語言查詢數據庫 服務器，將結果保存在Web 頁面中，再由瀏覽器顯示出來。 HTTP 請求 查詢 HTTP 響應 圖5.6 “瀏覽器—Web 服務器—數據庫服務器”結構 5.2 模 塊 設 計 在設計好軟件的體系結構后，就已經在宏觀上明確了各個模塊應具有什么功能，應放 在體系結構的哪個位置。我們習慣地從功能上劃分模塊，保持“功能獨立”是模塊化設計 的基本原則。因為，“功能獨立”的模塊可以降低開發(fā)、測試、維護等階段的代價。但是 “功能獨立”并不意味著模塊之間保持絕對的孤立。一個系統要完成某項任務，需要各個 模塊相互配合才能實現，此時模塊之間就要進行信息交流。 比如手和腳是兩個“功能獨立”的模塊。沒有腳時，手照樣能干活。沒有手時，腳仍可 以走路。但如果希望跑得快，那么邁左腳時一定要伸右臂甩左臂，邁右腳時則要伸左臂 甩右臂。在設計一個模塊時不僅要考慮“這個模塊就該提供什么樣的功能”，還要考慮“這 個模塊應該怎樣與其它模塊交流信息”。 本節(jié)將論述評價模塊設計優(yōu)劣的三個特征因素：“信息隱藏”、“內聚與耦合”和“封閉— —開放性”。 5.2.1 信息隱藏 在一節(jié)不和諧的課堂里，老師嘆氣道：“要是坐在后排聊天的同學能象中間打牌的同學 那么安靜，就不會影響到前排睡覺的同學。” 這個故事告訴我們，如果不想讓壞事傳播開來，就應該把壞事隱藏起來，“家丑不可外 揚”就是這個道理。為了盡量避免某個模塊的行為去干擾同一系統中的其它模塊，在設計 模塊時就要注意信息隱藏。應該讓模塊僅僅公開必須要讓外界知道的內容，而隱藏其它 一切內容。 模塊的信息隱藏可以通過接口設計來實現。一個模塊僅提供有限個接口（Interface） ，執(zhí)行模塊的功能或與模塊交流信息必須且只須通過調用公有接口來實現。如果模塊是 一個C++對象，那么該模塊的公有接口就對應于對象的公有函數。如果模塊是一個COM對 象，那么該模塊的公有接口就是COM對象的接口。一個COM對象可以有多個接口，而每個 接口實質上是一些函數的集合。[Rogerson 1999] 美國也許是世界上丑聞最多的國家，因為它追求民主，不懂得“隱藏信息”。但美國又 是軟件產業(yè)最發(fā)...
軟件工程思想5