資源描述：
《如何開發(fā)一個軟件的架構(gòu)》由會員上傳分享，免費在線閱讀，更多相關內(nèi)容在行業(yè)資料-天天文庫。
1、由于本書是關于軟件構(gòu)建的，因此本節(jié)不會告訴你如何開發(fā)一個軟件的架構(gòu)；它關注是如何確定一個業(yè)已存在的架構(gòu)的質(zhì)量。因為架構(gòu)比需求離構(gòu)建活動又近了一步，所以對架構(gòu)的討論也會比對需求的討論更詳細一些。為什么要把架構(gòu)作為前期準備呢？因為架構(gòu)的質(zhì)量決定了系統(tǒng)的“概念完整性”。后者繼而決定了系統(tǒng)的最終質(zhì)量。一個經(jīng)過慎重考慮的架構(gòu)為“從頂層到底層維護系統(tǒng)的概念完整性”提供了必備的結(jié)構(gòu)和體系，它為程序員提供了指引——其細節(jié)程度與程序員的技能和手邊的工作相配。它將工作分為幾個部分，使多個開發(fā)者或者多個開發(fā)團隊可以獨立工作。好的架構(gòu)使得構(gòu)建活動變得更容易。糟糕的架構(gòu)則使構(gòu)建活動幾乎寸步難行。圖3-7顯示
2、了糟糕的架構(gòu)的另一個問題。圖3-7離開了良好的軟件架構(gòu)，你可能瞄準了正確的問題，但卻使用了錯誤的解決方案。也許完全不可能有成功的構(gòu)建在構(gòu)建期間或者更晚的時候進行架構(gòu)變更，代價也是高昂的。修復軟件架構(gòu)中的錯誤所需的時間與修復需求錯誤所需的時間處于同一數(shù)量級——即，多于修復編碼錯誤所需的時間（BasiliandPerricone1984,Willis1998）。架構(gòu)變更如同需求變更一樣，看起來一個很小的改動，影響也許是非常深遠的。無論為了修正錯誤還是改進設計而引發(fā)架構(gòu)變更，越早識別出變更越好。TypicalArchitecturalComponents架構(gòu)的典型組成部分很多組成部分是優(yōu)
3、秀的系統(tǒng)架構(gòu)所共有的。如果你自己構(gòu)建整個系統(tǒng)，那么在架構(gòu)工作會與更詳細的設計工作有重疊部分。在這種情況下，你至少應該思考架構(gòu)的每個組成部分。如果你目前從事的系統(tǒng)的架構(gòu)是別人做的，你應該能夠不費力地找出其中重要的組成部分（無須戴上獵鹿帽、牽著獵犬、手拿放大鏡）。在這兩種情況中，你都需要考慮以下的架構(gòu)組成部分。ProgramOrganization程序組織系統(tǒng)架構(gòu)首先要以概括的形式對有關系統(tǒng)做一個綜述。如果沒有這種綜述，要想將成千的局部圖片（或十多個單獨的類）拼成一幅完整的圖畫是相當傷腦筋的。如果系統(tǒng)是小小的只有12塊的智力拼圖玩具，你那一歲的小孩也能在眨眼功夫解決它。不過把12個子系
4、統(tǒng)拼到一起要困難一些，而且如果你不能將它們拼起來，那么就無法理解你正在開發(fā)的那個類對系統(tǒng)有何貢獻。在架構(gòu)中，你應該能發(fā)現(xiàn)對那些曾經(jīng)考慮過的最終組織結(jié)構(gòu)的替代方案的記敘，找到之所以選用最終的組織結(jié)構(gòu)，而不用其他替代方案的理由。如果對某個類在系統(tǒng)中的角色沒有一個清晰的構(gòu)思，那么編寫這個類就是一件令人灰心喪氣的工作。描述其他組織結(jié)構(gòu)，才能說明架構(gòu)最后選定的這種系統(tǒng)組織結(jié)構(gòu)的緣由，并且表明各個類都是慎重考慮過的。有一份對設計實踐的綜述發(fā)現(xiàn)，“維護‘設計的緣由’”至少與“維護設計本身”一樣重要(Rombach1990)。架構(gòu)應該定義程序的主要構(gòu)造塊（buildingblocks）。根據(jù)程序規(guī)
5、模不同，各個構(gòu)造塊可能是單個類，也可能是由許多類組成的一個子系統(tǒng)。每個構(gòu)造塊無論是一個類還是一組協(xié)同工作的類和子程序，它們共同實現(xiàn)一種高層功能，諸如與用戶交互、顯示W(wǎng)eb頁面、解釋命令、封裝業(yè)務規(guī)則、訪問數(shù)據(jù)，等等。每條列在需求中的功能特性(feature)都至少應該有一個構(gòu)造塊覆蓋它。如果兩個或多個構(gòu)造塊聲稱實現(xiàn)同一項功能，那么它們就應該相互配合而不會沖突。應該明確定義各個構(gòu)造塊的責任。每個構(gòu)造塊應該負責某一個區(qū)域的事情，并且對其他構(gòu)造塊負責的區(qū)域知道得越少越好。通過使各個構(gòu)造塊對其他構(gòu)造塊的了解達到最小，你能將設計的信息局限于各個構(gòu)造塊之內(nèi)。應該明確定義每個構(gòu)造塊的通信規(guī)則。對
6、于每個構(gòu)造塊，架構(gòu)應該描述它能直接使用哪些構(gòu)造塊，能間接使用哪些構(gòu)造塊，不能使用哪些構(gòu)造塊。MajorClasses主要的類架構(gòu)應該詳細定義所用的主要的類。它應該指出每個主要的類的責任，以及該類如何與其他類交互。它應該包含對類的繼承體系、狀態(tài)轉(zhuǎn)換、對象持久化等的描述。如果系統(tǒng)足夠大，它應該描述如何將這些類組織成一個個子系統(tǒng)。架構(gòu)應該記述曾經(jīng)考慮過的其他類設計方案，并給出選用當前的組織結(jié)構(gòu)的理由。架構(gòu)無須詳細說明系統(tǒng)中的每一個類。瞄準80/20法則：對那些構(gòu)成系統(tǒng)80%的行為的20%的類進行詳細說明（Jacobsen,Booch,andRumbaugh1999;Kruchten200
7、0）。DataDesign數(shù)據(jù)設計架構(gòu)應該描述所用到的主要文件和數(shù)據(jù)表的設計。它應該描述曾經(jīng)考慮過的其他方案，并說明做出選擇的理由。如果應用程序要維護一個客戶ID的列表，而架構(gòu)師決定使用順序訪問的列表(sequential-accesslist)來表示該ID表，那么文檔就應該解釋為什么順序訪問的列表比隨機訪問的列表(random-accesslist)、堆棧、散列表要好。在構(gòu)建期間，這些信息讓你能洞察架構(gòu)師的思想。在維護階段，這種洞察力是無價之寶。離開它，你就像看一部
