Cyh的博客

總序     為了保證軟件開發工作的成功，由軟件開發人員、軟件采辦人員和軟件用戶組成的集成化團隊必須具有必要的軟件工程知識和技能，以保證能按時向用戶交付正確的軟件。所謂“正確的”就是指在功能、性能和成本幾個方面都能滿足用戶要求且無缺陷；所謂“無缺陷”就是指在編碼后對軟件系統進行了徹底的窮舉測試修復了所有的缺陷，或保證編寫的代碼本身不存在缺陷。

     CMU/SEI 為了達到這個目的，提出了創造、應用和推廣的戰略。這里的“創造”是指與軟件工程研究社團一起，共同創造新的實踐或改進原有的實踐，而不墨守成規。這里的“應用”是指與一線開發人員工作、以應用、改進和確認這些新的或改進的實踐，強調理論聯系實際。這里的“推廣”是指與整個社團一起，共同鼓勵和支持這些經過驗證和確認的、新的或改進的實踐在世界范圍內的應用，通過實踐進行進一步的檢驗和提高。如此循環，往復無窮。

     本書通過對一些真實系統的案例分析，闡述了如何把軟件構架與行業組織的實際情況相結合的問題。這些實例包括如下內容：

•  在最小程度的集中控制下，在本組織范圍內快速、方便地共享文檔的設想如何最終轉化為萬維網的軟件構架。
• 在空中交通管制中，對安全性的極高需求如何使公司為了獲得極高可用性而圍繞著一個構架創建系統。
• 分散在各地的不同的開發人員開發的飛行模擬器子系統如何連接成一個構架，以便于各子系統的集成。
• 為滿足產品同時交付的需求而促使公司采用某個適當的構架，從而使該公司能夠將一組復雜的相關軟件系統構建為一個產品線。
• 在組織間和團體內標準化構架方法的需要導致了諸如 J2EE 和 EJB 這樣的基礎結構。

      作為一種開發產品，軟件構架在質量、進度和成本方面具有極高的投資回報。

      我們認為可重用的組件只有在良好的構架下才會發揮應有的作用。組件也并非是唯一能夠重用的部分。構架的重用有利于相類似的系列產品開發，而這反過來又將導致新的組織結構和新的商機。

      本書還講述了軟件構架設計、構建和評價方面的若干技巧。我們從理解對構架的實際質量要求和構建滿足這些要求的構架的角度來闡述這些技巧。我們把構架表示和重構技術視為描述和驗證軟件構架的手段。我們從分析和評價某個構架與其目標的符合程度來討論這些技巧。書中所有的技巧都來自與我們自己和在SEI工作的同事分析各種軟件系統的經驗。我們分析的一些系統長達數百萬行代碼，是由大型軟件開發商歷經數年開發出來的。

        技術方面的內容代表了軟件構架研究的現狀--即當前該領域的研究和實踐相結合的程度，這也是全書的理論基礎。

導讀      讀者對象   

•  希望了解軟件構架的技術基礎以及對構架產生影響的商業和組織因素的從業軟件工程師。
• 希望理解軟件構架如何幫助他們更有效地監督系統的構建并改進其組織的技術管理人員。
• 將本書作為軟件工程課題的主要或輔助補充讀物的計算機科學或軟件工程專業的學生。

 部分和章節   本書大致從構架商業周期的角度，分為4部分講述了構架如何適合企業的需要。

•  預想構架：第1~3章
•  創建構架：第4~10章
•  分析構架：第11~13章
•  從一個系統刀多個系統：第14~19章

       第3，6，8，13，15，16和17章提供了案例分析，在各章的標題中已明確標出。

第一章   構架商業周期

•       系統的構架視圖是抽象的，它不考慮實現、算法和數據表示的細節，集中研究“黑盒”元素的行為和交互。在設計具有所期望屬性的系統時，開發軟件構架是第一步。

        構架商業周期的概念：系統需求來自于企業目標，構架來自于系統需求，系統來自于構架。構架與設計師的經驗、當時的技術水平有著密切的聯系。

        我們關注的焦點問題是：系統的軟件構架與構建系統時的環境及系統未來所處的環境有什么關系？此問題的答案就是組織本書內容所遵循的原則。軟件構架是技術、商業和社會等諸多因素作用的結果，而軟件構架的存在反過來又會影響技術、商業和社會環境，從而影響到未來的構架。我們把這種相互影響的周期--從環境到架構又返回到環境--稱作構架商業周期(Architecture Business Cycle,ABC)。

        本書詳細討論構架商業周期如下方面：

  •  組織目標如何影響需求和開發策略
  •  如何從需求得出架構
  •  如何對構架進行分析
  • 構架如何產生體現新的組織能力和需求的系統

   

  構架的產生      構架也是若干商業和技術決策的結果。構架的設計受諸多因素的影響，而這些影響因素的實現又隨構架所處環境的不同而異。即使是同一個設計師設計某個系統，在時間要求很緊迫和時間要求比較寬松的情況下，所做的決策也會有所不同。如果對設計沒有時間限制，他會做出不同的選擇。即使在系統需求、硬件環境、支持軟件和人力資源等方面的條件完全相同的情況下，某個設計師現在所能設計出的系統和他5年前所能設計出的系統也很可能是不一樣的。

        在任何一次開發中，系統需求都能夠明確反映出對系統最終特性的某些期望。并不是系統需求中的所有內容都和系統最終具備的特性直接相關。開發過程或某個工具的選用可能會受到系統需求的制約，但對系統需求的表述僅僅是萬里長征第一步。如果不能滿足除系統需求之外的其他一些要求，所開發出來的系統很可能就像不能正常運行的系統一樣一文不值。

        我們通過確定與架構有關的影響因素開始構建ABC。

  • 構架受系統涉眾的影響      很多人和組織都對構建軟件系統感興趣。我們把這樣的人或組織稱為涉眾：客戶、最終用戶、開發人員、項目經理、維護人員以及那些對系統進行市場營銷活動的人等等。這些涉眾所關注的問題各不相同，但都要求系統能夠在他們所關注的方面提供保證或優化。這可能是要求系統在運行時具有一定的特征、能夠在特定的硬件平臺上良好運行、用戶能夠輕松地定制系統、實現短的上市時間或較低的開發成本、使公司雇用到有專長的程序員或提供廣泛的功能，如此種種，不一而足。圖1.2給出了設計師采納有幫助的涉眾的“建議”的情況。

          一個得到各方認可的系統需要在以下方面達到相應要求：性能、可靠性、可用性、平臺兼容性、內存的利用、網絡使用程度、安全性、可修改性、易用性，與其他系統的互操作性以及行為。上述屬性，以及其他一些屬性，都會影響此系統的某個涉眾對該系統的評價。

          最基本的問題是，每個涉眾所關心的問題和期望的目標各不相同，而且有些是相互矛盾的?，F實情況是設計師通常不得不填補空白并協調沖突。

    構架受開發組織的影響      除了通過需求表示的組織目標外，構架還受開發組織的結構或本質的影響。人員的技能也是一個影響因素，開發進度和預算也會對架構產生影響。

          開發組織對軟件構架的影響可以分為3類，即直接影響、長遠影響和組織結構的影響。

    •   開發組織可能會對某些資產進行直接商業投資，如現有的構架和基于這些構架的產品。開發項目的基礎可能是所有要開發的新系統是已有類似產品線的延續，其開發成本中有很大一部分屬于資產重用。
    • 開發組織可能希望對某個基礎結構進行長期的商業投資以實現某些戰略目標，并且可能會把要開發的系統視作為此基礎結構融資或進一步擴展此基礎結構的手段。
    • 開發組織本身的結構也會影響構架的形成。

    構架受設計師的素質和經驗的影響      設計架構時所做的各種選擇與設計師本人所受的教育或培訓背景、對其他成功構架的了解以及對某些性能極佳或極差的系統的了解有關。設計構架時，設計師可能想實踐一下某種構架模式，或者是嘗試使用在某本書上或某門課程中所學到的技巧。

    構架受技術環境的影響      技術環境可以看作是對設計師素質和經驗的特殊反映。設計某個構架時所處的技術環境將會對構架的設計產生影響。這里所說的技術環境包括行業中的通常做法或在設計師所屬專業團體中占主導地位的軟件工程技巧。在當今的技術環境下，如果有哪個設計師根本就不考慮用基于Web、面向對象和支持中間件的方法來設計信息系統，我們就不得不佩服他的勇氣了。

    影響構架的其他因素      影響構架的因素有很多。一些只是隱含的，還有一些則很明顯是沖突的。軟件開發者幾乎從來沒有真正理解過企業目標所要求的系統性能，更不必說完全實現了。確實，連客戶的需求都很少完全編成文檔，這意味著還沒解決不同涉眾目標之間不可避免的沖突。

          設計師需要盡早知道并理解特性、源以及對項目的限制的優先級。因此，設計師必須確定出各類涉眾，并積極促使他們表達出對系統的需求或期望。如果不做這樣的工作，在設計展開后，就會出現某些涉眾要求設計師解釋為什么不采用所提出的其他方案的情況，這顯然會影響項目的開發進度，降低工作效率。如果早期工作做得好，設計師就能清楚在設計構架時所應考慮的制約條件，調整對系統的期望，與有關各方商討各因素的優先級并進行權衡。構架評審和迭代原型建立是實現此目標的兩個手段。

          要設計好的構架，設計師僅具有高超的專業技術是不夠的，這個道理顯而易見。設計師需要不斷地向涉眾解釋針對不同屬性所做的各種取舍，以及為何無法滿足涉眾的所有要求。因此，成功的設計師還必須具備與人交往、談判和交流的技巧。 圖1.3給出了對設計師（因此也是對構架）的影響。如圖所示，設計師會受到產品需求（從涉眾那兒獲得）、所在開發組織的結構和目標、可利用的技術環境及自身的素質和經驗的影響。

    構架對諸影響因素的反作用      本書的主旨就是要闡明企業目標、產品需求、設計師的經驗、構架和最終系統之間的關系--它們構成帶有反饋回路的、可由開發組織實施管理的周期。開發組織對這個周期管理得好，就能夠不斷成長壯大，拓展其經營范圍，充分利用以前在構架和系統構建方面的投資。圖1.4給出了該周期中的這些反饋回路。可以看到，有些反饋是來自構架本身的，而有些則來自根據構架所構建的系統。

     

    下面我們就來看一下該周期是如何運作的：

    1. 構架影響著開發組織的結構。構架規定了系統的結構。特別地，就像我們將會看到的一樣，構架規定了必須實現（或獲得）并集成在系統中的軟件單元。這些單元是開發項目的結構的基礎。每個軟件單元都要由專門的開發小組來完成，開發、測試和集成工作都是圍繞這些單元展開的。同樣，進度和預算也都要和這些組件相對應，并為之分配所需的資源。如果某個開發公司擅長構建相類似的系列系統，它就會為每個小組進行適當的投資，以保證各小組在其從事的領域達到較高的水準。這些小組也就稱為該開發組織中不可或缺的組成部分。這就是從構架到開發組織的反饋。
    2. 構架會影響開發組織的目標。成功地開發出一個系統，可以使開發公司在相應的市場上占有一些之地。該系統的構架又可以為類似系統的有效生產和部署提供良好的機會，組織可以調整其目標，以利用其新發現的技術來拓寬市場。這就是從該系統到開發組織以及它所構建的系統的反饋。
    3. 構架可能會影響可會對下一個系統的要求。這是因為與完全重新開始設計相比，利用已有的構架可使客戶更為及時地獲得更可靠、更經濟的系統。從經濟的角度考慮，客戶可能會愿意放棄某些性能需求。套裝軟件提供給廣大用戶的解決方案并不是針對某個用戶開發的，但這種軟件價格低廉，而且（綜合考慮）質量較高。產品線對那些不能確切表述自己在各種情況下的需求的用戶也產生了類似的影響。
    4. 構建系統的過程豐富了整個開發團隊的經驗，從而將影響設計師對后繼系統的設計。
    5. 一些典型的系統會影響并實際改變軟件工程的發展，也就是系統開發人員學習和實踐的技術環境。

    上述以及其他反饋機制構成我們所稱的構架商業周期。圖1.4所示的構架商業周期向我們展示了開發組織的業務和文化對軟件構架的影響。而構架反過來又成為影響所開發系統各方面屬性的決定性因素。但我們也應當認識到，構架商業周期還與精明的開發組織利用開發構架時所做的組織上的或技術經驗上的效應有關，這些組織通常會適當調整企業經營策略，以適應未來項目的開發。

  軟件過程和構架商業周期      我們把對軟件開發活動的組織、規范和管理稱為軟件過程。在創建軟件構架，使用該構架實現設計，然后實現或管理目標系統或應用軟件的演變的過程中，涉及到哪些活動？這些活動包括

  •  為系統構建一個商業案例
  •  理解系統需求
  •  創建或選擇構架
  •  將構架編成文檔，并與有關各方進行交流
  •  對此構架進行分析和評價
  •  根據此構架實現系統
  •  保證系統實現符合構架的要求

  構架活動      就像構架商業周期的結構所顯示的那樣，這些活動之間存在著復雜的反饋關系。下面我們就對這些活動逐一進行簡單的介紹。

  • 為系統創建商業案例。創建商業案例的含義要比簡單地評估某個系統的市場需求廣泛得多。這是創建并限制任何未來需求的重要一步。該軟件系統定價將會是多少？其目標市場是什么？預期于什么時間正式推出？是否需要與其他系統連接的接口？有什么必須要遵從的限制條件？   這些問題的解決必須要有系統設計師的參與。當然這些決策不能僅靠設計師來制定，但如果在創建商業案例的過程中沒有設計師的參與，將無法實現這些商業目標。
  • 理解需求。可以使用很多技巧獲取涉眾的需求。 創建原型是另一種有助于理解系統需求的有效方法。原型有助于對所期望的行為進行建模，有助于設計用戶接口或分析資源使用情況。這可以使涉眾對所開發的系統及早有一個“真實”的體驗，從而促使很快做出關于系統的設計和其用戶接口設計的決策。      在獲取系統需求時無論采用什么技巧，所有開發系統的期望的質量屬性都會確定其構架的形狀。設計師長期以來一直使用具體的的戰術來實現特定的質量屬性。構架設計包含了許多權衡，在指定需求時，并不是所有這些權衡都是明顯。直到創建了構架后需求中的某些權衡才會變得明顯，并迫使確定出需求優先級。
  • 創建或選擇構架。   在里程碑式的書籍《人月神話》中，Fred Brooks以令人信服的論證清楚地闡明：概念完整性是成功設計系統的關鍵，而只有通過以小組的形式共同設計系統構架才能真正實現概念完整性。
  • 構架的交流。   要使構架真正成為系統設計的砥柱，就必須向與構架有關的所有涉眾清楚而準確地表述構架。為此，構架文檔的信息必須豐富、確切清楚，要保證具有不同教育背景的相關人員都能理解。
  • 構架的分析和評價。   在任何設計過程中都會有多個候選的設計方案。以一種合理的方式在這些方案中進行選擇是設計師所面臨的最大挑戰之一。
  • 實現基于該構架的系統。   這個階段的主要任務是，保證開發人員在實際開發中忠實于構架所規定的結構，遵守關于各部分之間交互的約定。表述清楚并為各方所理解的構架是保證實際設計與構架一致的重要條件。如果能有一個幫助設計人員創建并維護構架的環境或基礎結構，這一階段的工作就會做的更好。
  • 使構架符合原來的表述。   最后，當構架已經創建完畢并投入使用時，開發工作就進入了維護階段。在這一階段，要始終保持清醒的頭腦，以保證構架符合原來的表述。

  什么樣的構架才算好      構架并不是注定是好的或是壞的。各種構架總是能夠或多或少的滿足某些系統的要求，但是，在設計構架時必須遵循一些實踐準則。當然，忽視某一條準則并不一定意味著所設計的構架醬油知名的缺陷，但至少應當把準則當作一個警示，進行相應的研究分析。  

        我們把從軟甲開發中所得到的經驗分為兩大類：關于過程的建議和關于產品（或結構）的建議。我們所提出的關于過程的建議主要有如下幾條：

  • 構架的設計應該由一位設計師來完成，或者由一個在某位設計師領導下的小組來完成。
  • 設計師（或構架小組）應全面掌握系統的功能需求，并且應有一份所設計構架應滿足的劃分了優先級的質量屬性列表（如安全性或可修改性）
  • 構架的文檔應該完備，至少應有一個靜態視圖和一個動態視圖，應該采用所有人都認同的文檔形式，以保證所有涉眾都能夠理解這些文檔
  • 應該把構架設計方案交由所有涉眾傳閱，讓涉眾積極參與設計方案的評審。
  • 應該對構架認真進行分析，得出可應用的量化度指標（如最大吞吐量）。也應該對質量屬性進行正式評估，以避免出現發現問題時為時已晚的情況。
  • 構架的設計應有助于增量式實現。為此，可先創建一個粗略的、具備雛形但功能最簡單的系統，通過這個骨架系統逐步細化、擴大來得到所期望的系統。這種做法可簡化集成和測試的工作
  • 允許構架帶來一定的（少量的）資源爭用，但應清楚地給出這些資源爭用的解決方案，告之于有關各方，并保證這些解決方案切實可行。

  我們所提出的關于結構的建議主要有如下幾條：

  • 構架應采用定義良好的模塊，各模塊的功能責任劃分應基于信息隱藏和相互獨立的原則。信息隱藏模塊應該包括那些封裝了計算基礎結構特性的模塊，以將大部分軟件與計算基礎結構的變化隔離開。
  • 應該使用特定于每個屬性的眾所周知的構架戰術來實現質量屬性。
  • 構架絕對不可以依賴于某個特定版本的商業產品或工具。如果確實依賴于某個商業商品，則要合理設計構架，使得當所依賴的商業產品發生變化時，能夠方便、經濟地適應。
  • 應將產生數據的模塊和使用數據的模塊分離開。未來的變化往往僅限于數據的產生或數據的使用，所以，這樣做一般可以提高系統的可修改性。如果系統中需要添加新數據，則這兩個部分都要做相應的修改，但如果這兩個部分是相互獨立的，就可以對系統進行分階段逐步（增量式）升級。
  • 對于并行處理系統，構架應該采用定義良好的進程或任務，它們未必反映模塊分解結構。也就是說，有些進程的運行涉及刀若干個模塊，而模塊中的某個過程可能也要為若干個進程所調用。
  • 每個任務或進程的編寫都要考慮到與特定處理器的關系，并保證能夠方便地改變這種關系。
  • 構架應該采用少量的、簡單的交互模式。即在整個運行過程中，系統的功能應保持一致。這可使系統易于理解，有助于縮短開發時間、提高可靠性、增強可修改性。它還應該展示構架中的概念完整性--雖然無法度量，但卻有利于系統開發的順利進行。