《架构之美》摘录一
架構之美
譯者：王海鵬
第一章 架構概述
1.1 簡介
(1).架構：“建造的藝術或科學；特別是設計和建造人類使用的建筑時的藝術或實踐，同時考慮到美學因素和實用因素。”
(2).我們談到交響樂的“構架”，反過來，又將架構稱為“凝固的音樂”。
(3).當代的架構師可以會說，待構建的對象或系統必須具有以下特征：
<1>.具備客戶要求的功能；
<2>.能夠在要求的工期內安全地構建；
<3>.性能足夠好；
<4>.可靠的；
<5>.可用的，并且使用時不會造成傷害；
<6>.安全的；
<7>.成本是可以接受的；
<8>.符合法規標準；
<9>.將超越前人及其競爭者。
1.1.1 建筑師的角色
音樂作曲與軟件架構
雖然人們常用建筑架構設計來類比軟件架構，但音樂作曲可能是更好的類比。建筑師創建的是相對靜止的結構（該架構必須考慮到人員和服務在建筑內的移動，以及承重結構）的靜態描述（藍圖或其他圖紙）。
在音樂作曲和軟件設計中，作曲家（軟件架構師）創建一段音樂的靜態描述（架構描述和代碼），這段音樂以后將演奏（執行）許多次。在音樂和軟件中，設計都依靠許多組件的交互來得到期望的效果，結構依賴于演奏者、演奏環境，以及演奏者所做的詮釋。
1.1.2 軟件架構師的角色
軟件架構師的職責：
<1>.建筑師可以回顧幾千年的歷史，看看過去的建筑師都做過些什么，他們可以參觀并研究那些矗立了幾百年的建筑，有時甚至有上千年歷史的建筑，而它們仍在使用。在軟件業，我們只有幾十年的歷史，并且我們的設計常常是不公開的。
此外，建筑師擁有并利用標準來描述他們制作的圖紙和規格說明，這讓現在的建筑師能夠從記錄下來的架構歷史中受益。
<2>.建筑是有形的產品，在建筑師制作的規劃和工人修造的建筑之間存在著明顯的區別。
1.1.3 軟件架構的含義
一個程序或計算系統的軟件架構是系統的一種結構或一組結構，它包含軟件元素，這些元素的外部可見的屬性，以及元素之間的關系。“外部可見”的屬性是其他元素對該元素可以做出的假定，諸如它提供的服務、執行時的特征、錯誤處理、共享資源的使用等。
1.1.4 架構與設計
架構是系統設計的一部分，它突出了某些細節，并通過抽象省略掉另一些細節。所以架構是設計的一個子集。關注實現系統組件的開發者可能不會特別關心所有組件如何裝配在一起，而是主要關注少數組件的設計和開發，包括他們必須遵守的架構約束和可以應用的規則。因此，開發者和架構師面對的是系統設計的不同方面。
1.2 創建軟件架構
(1).軟件架構師的首要關注點不是系統的功能。
(2).一個“基于WEB的應用”，你首先問頁面布局和導航樹，還是問下面這些問題：
<1>.誰提供應該主機托管？托管的環境有什么技術限制嗎？
<2>.你想運行在Windows服務器上還是在LAMP棧上？
<3>.你想支持多少并發用戶？
<4>.應用需要怎樣的安全性？有需要保護的數據嗎？應用將運行在公網上還是私有的內部網上？
<5>.你能為這些答案排列優先級嗎？例如，用戶數是否比響應時間更重要？ 根據我們對這些問題和一些其他問題的回答，你就可以畫出系統架構的草圖。
(3).品質關注點指明了功能必須以何種方式交付，才能被系統的利益相關人所接受，系統的結果包含這些人的既定利益。
成功架構師的兩項關鍵實踐：讓利益相關人參與以及同時關注功能和品質。作為一名架構師，你首先問我們想從系統中得到什么，有怎樣的優先級。在實際項目中，你會找出其他的利益相關人。典型的利益相關人和他們的關注點包括：
<1>.投資人，他們想知道項目是否能夠在給定的資源和進度約束下完成。
<2>.架構師、開發人員和測試人員，他們首先考慮的是最初的構建和以后的維護與演進。
<3>.項目經理，他們需要組織團隊，制定迭代計劃。
<4>.市場人員，他們想通過品質特點實現與競爭者的差異化。
<5>.企業用戶，包括最終用戶、系統管理員，以及安裝、部署、準備、配置人員。
<6>.技術支出人員，他們關注幫助平臺電話呼入的數目和復雜性。 每個系統都有自己的品質關注點。有些關注點可能定義得很好，如性能、安全、可伸縮性等。但是，另一些同樣主要的關注點卻可能沒有詳細規定，如可變性、可維護性和可用性等。
(4).架構師的第一項任務，就是與利益相關人協作，理解這些品質關注點和約束，并為他們排列優先級。為什么不從功能需求開始？因為通常有許多種可能的系統分解方式。架構師通常必須進行架構層面的系統重構。
(5).架構團隊的挑戰在于，在創建架構時保持同一種思考方式和同一種哲學。讓團隊保持盡可能小，讓他們在充分溝通、高度協作的環境工作，讓一兩個“首席架構師”擔任仁慈的獨裁者，最終做出所有決定。這種架構模式常見于成功的團隊，不論是公司開發還是開源開發，由此得到的概念完整性是美麗架構的一種特性。
(6).每個關注點都以問題的方式表述，架構師在項目過程中可能需要考慮它。當然，具體系統會有其他關鍵的關注點：
<1>.功能性(Functionality) 產品向它的用戶提供哪些功能？
<2>.可變性(Changeability) 軟件將來可能需要哪些變化？哪些變化不可能發生，不需要特別容易進行這些改變？
<3>.性能(Performance) 產品將達到怎樣的性能？
<4>.容量(Capacity) 多少用戶將并發使用該系統？該系統將為用戶保存多少數據？
<5>.生態系統(Ecosystem) 在部署的生態環境中，該系統將與其他系統進行那些交互？
<6>.模塊化(Modularity) 如何將編寫軟件的任務分解為工作指派(模塊)，特別是這些模塊可以獨立的開發，并能夠準確而容易的滿足彼此的需要？
<7>.可構建性(Buildability) 如何將軟件構建為一組組件，并能夠獨立實現和驗證這些組件？那些組件應該復用其他的產品，那些應該從外部供應商處得到？
<8>.產品化(Producibility) 如果產品將以幾種變體的形式存在，如何開發一個產品線，并利用這些變體的共性？產品線中的產品以怎樣懂得步驟開發？在創建一條軟件產品線時，要進行哪些投資？開發產品線中不同變體的選擇，預期會得到怎樣的回報？特別是，是否可能先開發最小的有用產品，然后再添加(擴展)組件，在不改變以前編寫的代碼的情況下，開發產品線的其他成員？
<9>.安全性(Security) 產品是否需要用戶認證，或者必須限制對數據的訪問？數據的安全性如何得到保證？如何抵擋“拒絕服務”攻擊或其他攻擊？
最后，一個好的架構師會認識到，架構會影響組織機構。
1.3 架構結構
一個好的架構師如何處理這些關注點？我們曾經提到過，需要將系統組織成一些結構，每種結構都定義了特定類型的組件之間的具體關系。架構師的主要關注點就是對系統進行組織，讓每種結構有助于解答一個關注點所定義的問題。關鍵的結構決定將產品劃分為組件，并定義了這些組件之間的關系。
1.3.1 信息隱藏結構
<1>.組件與關系：主要組件是一些“信息隱藏模塊”，每個模塊都是針對一組開發人員的工作指派，每個模塊都包含了一種設計決定。如果一項決定可以改變，同時又不影響任何其他模塊，我們就說這項設計就是一個模塊的秘密。模塊間最基本的關系是“整體-部分”關系。
<2>.“整體-部分”結構是層次狀的。在這個層次結構的葉節點上的模塊不包含可識別的子模塊。“包含”結構也是層次狀的，因為每個程序都只包含在一個模塊之中。“依賴”關系不一定是層次狀的，因為兩個模塊可能互相依賴，要么是這屆互相依賴，要么是通過一個較長的“依賴”關系形成的環。請注意“依賴”不應該與后面小節中定義的“使用”混淆。
<3>.信息隱藏結構是面向對象設計方法的基礎。如果一個信息隱藏模塊設計為一個類，這個類的公有方法就屬于該模塊的接口。 滿足的關注點：信息隱藏結構的設計應該能滿足可變性、模塊化和可構建性的要求。
1.3.2 使用結構
<1>.組件與關系：信息隱藏模塊包含一個或多個程序。當且僅當兩個程序共享一個秘密時，它們才屬于同一個模塊。“使用結構”的組件是一些可以單獨調用的程序。只有在相同綁定時間操作的程序之間，我們才考慮形成一種使用結構。首先只考慮運行時操作的程序可能最容易。以后，我們也可以考慮那些編譯時或載入時操作的程序之間的使用關系。
<2>.通常大型的軟件系統包含太多的程序，這讓程序間使用關系的描述不容易理解。在這種情況下，使用關系可以用于程序的組合，如模塊、類或包。這樣的組合描述喪失了重要的信息，但有助于展示“全局”。
<3>.在某些項目中，系統的使用關系開始并沒有完全確定，要到系統實現時才能確定，因為開發者會在實現過程中決定他們使用哪些程序。但是系統的架構師可能在設計時創建一種“允許使用”關系，約束開發者的選擇。定義良好的使用結構將創建系統的適當子集，可以用于驅動迭代式或增量式的開發模式。 滿足的關注點：產品化和生態系統。
1.3.3 進程結構
(1).組件與關系：信息隱藏模塊結構和使用結構是靜態的結構，存在于設計時和編碼時。現在轉向運行時結構，參與進行結構的組件是進程。進程是運行時的事件序列，由程序控制。每個程序都作為一個或多個進行的一部分執行。一個事件序列的執行獨立于另一個進程中的事件序列，除非這兩個進程彼此同步。
(2).進程是幾種不同關系中的組件：
<1>.進程提供工作 一個進程可能會創建工作，該項工作必須由其他進程完成，這種結構在確定系統是否死鎖時是很重要的。
<2>.進程取得資源 在動態分配資源的系統中，一個進程可能控制由另一個進程使用的資源，后者必須請求并歸還這些資源。
<3>.進程共享資源 兩個進程可能共享資源，如打印機、內存或端口等。如果兩個進程共享一項資源，就需要通過同步來防止使用沖突。每一種資源可能有不同的關系。
<4>.進程包含在模塊中 每個進程由一個程序控制，正如前面提到的，每個程序包含在一個模塊中。
因此，我們可以認為進程包含在模塊之中。 滿足的關注點：性能和容量。
1.3.4 訪問結構
系統中的數據可能劃分成具有屬性的段，如果程序對段中的任何數據擁有訪問權，就對該段中的所有數據有了訪問權。請注意，為了簡化描述，我們應該讓段的規模最大化，具體做法是添加一個條件，即如果兩個段被同一組程序訪問，這兩個段就應該合并。 數據訪問結構包含兩種類型的組件：程序和段。
這種關系被命名“有權訪問”，它是程序和數據段之間的關系。如果這種結構讓程序訪問的權限最小，并且嚴格執行，我們就認為系統更安全。
滿足的關注點：安全性。
1.4 好的架構
(1).我們曾提到，架構師玩的是折中的游戲。對于一組給定的功能需求和品質需求，沒有唯一的正確架構和唯一的“正確答案”。我們從經驗中得知，應該對架構進行評估，確定它是否滿足其需求，然后再投入資金來構建、測試和部署這個系統。
(2).架構評估的兩種方式。
<1>.第一種評估方式是確定架構的屬性，通常通過建模或模擬系統的一個或多個方面。如性能建模來評估吞吐量和伸縮性，通過失效樹模型來評估可靠性和可訪問性。其他類型的模型包括復雜性和耦合指標，用于評估可變性和可維護性。
<2>.第二種評估方式，也是最廣泛使用的方式，就是通過對架構師提出質詢來評估該架構。有許多結構化的質詢方法。如：軟件架構復查委員會(Software Architecture Review Board,SARB)
(3).質詢方法
<1>.質詢方法的另一種變體是架構折中分析方法(Architecture Trade-off Analysis Method,ATAM),它尋找架構不能滿足品質關注點的風險。ATAM使用了場景分析，每種場景都描述了特定的利益相關人對系統的品質關注點。架構師然后解釋該架構如何支持每一種場景。
<2>.主動復審是另一種質詢方法，它改變了復審過程的開始方式，要求架構師向復審者提供架構師認為重要而需要回答的問題。然后，復查者利用已有的架構文檔和描述來回答這些問題。(可以試試查找“Software Architecture Review Checklist(軟件架構復審檢查清單)”)。
1.5 美麗的架構
(1).所有前面的方法都有助于我們判斷一個架構是否“足夠好”---也就是說，是否有可能知道開發者和測試者構建一個系統，并滿足系統的利益相關人的功能和質量關注點。“軟件架構名人堂”進行“軟件產品線名人堂”的條件包括獲得商業上的成功、影響其他產品線的架構（其他產品線可能“借用、復制、竊取”這個架構）、擁有足夠的文檔從而讓其他人“不必通過道聽途說”就能夠理解該架構。
(2).“架構名人堂”或“美麗架構藝術館”
<1>.架構的實用性。好的架構應該每天被許多人使用。
<2>.架構的可構建性。具有定義良好的使用結構的架構，支持增量式構建，構建的過程是透明的、可見的。
<3>.架構的持久性。好的架構要經得起時間考驗，可以預期到變更的需要，允許期望的修改能夠容易而有效的進行。
<4>.架構的客戶滿意度。好的架構要讓開發人員、測試人員、使用該軟件的客戶由衷的高興。
<5>.架構的概念完整性。架構概念完整性是一項跨越所有領域的特征，一致的架構學習起來更容易、更快，代碼更干凈，測試集更小。
?
總結
- 上一篇： Visual Studio 2008 可
- 下一篇： Eclipse-配置workspace路