軟件體系架構閱讀筆記(九)

軟件架構設計系統總體架構，從需求到設計的每一個細節都要考慮到，把握整個項目，使設計的項目儘可能效率高，開發容易，維護方便，升級簡單。本文從架構師職責、軟件架構定義、設計架構、評估架構、架構管理等方面來描述瞭解軟件架構的含義和怎樣設計軟件架構。

1、軟件架構師的職責

架構師分爲如下幾大類：業務架構師、主題領域架構師、技術架構師、項目架構師（J2EE架構師、.NET架構師等）、系統架構師。

一、架構師的職責主要體現

架構師的職責就是設計一個公司系統的基礎架構，並提供關於怎樣創建和維護系統的指導方針。具體來說，架構師的職責主要體如今如下幾方面：

1）、負責公司系統的架構設計、研發工做。

2）、承擔從業務向技術轉換的橋樑做用。

3）、協助項目經理制定項目計劃和控制項目進度。

4）、負責輔助並指導系統分析開展設計工做。

5）、負責組織技術研究和攻關工做。

6）、負責組織和管理公司內部的技術培訓工做。

7）、負責組織及帶領公司內部員工研究與項目相關的新技術。

8）、管理技術支撐團隊並給項目、產品開發實施團隊提供技術保障。

9）、理解系統的業務需求，制定系統的總體框架（包括、技術框架和業務框架）。

10）、對系統框架相關技術和業務進行培訓，指導開發人員開發。並解決系統開發、運行中出現的各類問題。

二、構架設計師必須具有的技能

經驗：既包括在問題領域的經驗（經過完全瞭解需求），也包括在軟件工程領域的經驗。對於一個構架團隊，這些素質要求可由各團隊成員來分別承擔，但其中至少要有一名構架設計師可以把握項目的全局。

領導才能：可以推進各個團隊的技術進展，並能在壓力下做出關鍵性的決策而後將其貫徹到底。要提升效率，構架設計師和項目經理必須緊密協做。構架設計師主要負責解決技術問題，項目經理主要負責解決行政管理問題。構架設計師必須有權在技術問題上做出決定。

溝通：可以贏得他人的信任，以對其進行說服、激勵和指導。構架設計師不能靠命令進行領導，而必需要贏得項目中其餘人員的贊同。爲了提升效率，構架設計師必須贏得項目團隊、項目經理、客戶、用戶羣體以及管理團隊的尊敬。

以目標爲中心、積極主動：不懈地追求成效。構架設計師是推進項目發展的技術動力，而不是空想家。在其職業生涯中，成功的構架設計師一直都要在捉摸不定和承受壓力的狀況下做出折衷決定。構架設計師只有將注意力集中在該作的事情上，才能在項目中取得成功。

專業：精通構架設計的理論、實踐和工具，並掌握多種參考構架、主要的可重用構架機制和模式（例如J2EE架構等）。具有系統設計員的全部技能，但涉及面更廣、抽象級別更高。

2、軟件架構、架構模式、參考模型、參考架構

一、對於軟件架構定義有不少種，通用的定義是：某個軟件或計算機系統的軟件架構是該系統的一個或多個結構，他們由軟件元素，這些元素的外部可見屬性以及這些元素之間的關係組成。
這裏所說的某個元素的「外部可見屬性」是指其餘元素對該元素所作的假設，如它所提供的服務、性能特徵、錯誤處理、共享資源的使用，等等。

其餘的定義包括：架構是一種高層設計。架構是系統的整體結構。架構是一個軟件或系統的組件、組件之間的相互關係以及管理其設計和演變的原理和方針的結構。架構是組件和鏈接器。

二、架構模式是對元素和關係類型以及一組對其使用方式的限制的描述。

三、參考模型是一種考慮數據流的功能劃分。

四、參考架構是映射到軟件元素（它們相互協做，共同實如今參考模型中定義的功能）及元素之間數據流上的參考模型。

五、軟件架構、架構模式、參考模型、參考架構之間的關係：

軟件結構	關係	適用環境
分解	是一個子模塊；與之共享祕密	資源分配、項目結構化和規劃；信息隱藏、封裝；配置控制
使用	要求正確出現	設計子集；設計擴展
分層	要求正確的出現、使用服務、提供抽象	增量式開發；在「虛擬機」可移植性之上實現系統
類	是一個實例；共享訪問方法	在面向對象的設計系統中，從一個公共的模版中產生快速的、相近的實現
客戶機-服務器	與之通訊；依賴於	分佈式操做；關注點分離；性能分析；負載平衡
進程	與之併發運行、可能會與之併發運行；排除；優先於等	調度分析；性能分析
併發	在相同的邏輯線程上運行	肯定存在資源爭用，線程能夠交叉、鏈接、被建立或被殺死的位置
共享數據	產生數據；使用數據	性能；數據完整性；可修改性
部署	分配給；移植到	性能、可用性、安全性分析
實現	存儲在	配置控制、集成、測試活動
工做分配	分配到	項目管理、最佳利用專業技術、管理通用性

注：在＜Pattern-Oriented Software Architecture (面向模式的軟件體系架構) ＞中首次提出了8種體系結構模式： 層（Layers）、管道和過濾器(Pipes and Filters) 、黑板(Black board )、代理者（Broker）、模型-視圖-控制器（Model-View-Controller）、表示-抽象-控制（Presentation-Abstraction-Control）、微核（Microkernel）、映像（Reflection）。

六、架構定義中指出系統由多種結構構成的，下面列出一些常見的結構。

七、質量屬性

系統從設計、實現到部署的整個過程當中考慮質量屬性的實現。質量屬性包括下列三類：

（1）、系統的質量屬性。（可用性、可修改性、性能、安全性、可測試性和易用性）

（2）、受架構影響的商業屬性。（上市時間、成本和收益、所但願的系統生命期的長短、目標市場、推出計劃、與老系統的集成）

（3）、與架構自己相關的一些質量屬性。（概念完整性、正確性與完整性、可構建性）

六個質量屬性的戰術列表：

3、設計架構

幾乎在咱們遇到的全部成功的面向對象系統中都具備但失敗的系統中缺乏的兩個特性是：存在一個強大的構架構想，應用管理良好的迭代式增量開發週期。功能、質量和商業需求的某個集合「塑造」了構架。咱們把這些塑造需求稱爲「構架驅動因素」。

構架設計必須按需求分析進行，但不須要在需求分析完成後在開始構架設計。實際上，在肯定了關鍵的構架驅動因素後，就能夠開始構架設計了。當設計了構架的足夠多的部分後，就能夠開始開發骨架系統了。該骨架系統在上面進行迭代開發（以及其在任何一個點交付的能力）的框架。組織結構對構架產生影響。

屬性驅動的設計(ADD)是一個用於設計構架以知足質量需求和功能需求的方法。ADD把一組質量屬性場景做爲輸入，並使用對質量屬性實現和構架之間的關係的瞭解，對構架進行設計。

ADD步驟：

（1） 選擇要分解的模塊。

（2） 根據這些步驟對模塊進行求精。

對須要進一步分解的每一個模塊重複上述步驟。

在設計架構過程當中能夠重用架構，重用一些技術以方便來實現架構與設計。高層重用技術分類

高層重用

設計模式

框架

軟件架構

架構風格

架構設計風格

架構框架

架構平臺

設計模式：使用相互通訊的類和對象可爲常見的設計問題提供通用的解決方案。爲了幫助用戶掌握模式的概念並有效地設計模式，我一般爲設計模式的描述提供一個帶有比喻性的抽象。常見的設計模式有：Fvacade（外觀模式），它爲子系統中的一系列動做提供一個統一接口；Ovbserver（觀察者模式），具體的設計模式內容參考GOF23設計模式。
框架：提供一組相互協做的類及運行時對象，用於生成某些特定領域的應用軟件。咱們能夠根據特定應用的需求方便地對框架中的抽象和類進行定製，以重用框架的設計和代碼。

軟件架構：編制軟件也稱爲架構軟件。一個可操做的軟件內部應具備某種形式的架構。軟件架構技術中可重用的實體能夠進一步地分爲4類：架構風格、架構設計風格、架構框架、架構平臺。

架構風格給出了精心設計的軟件全局的通用形態。例如，Shaw和Garlan提出了7種架構風格：管道和過濾器、面向對象的組織、隱式調用、分層系統、倉庫、狀態機、解釋器，及過程控制。

架構設計風格給出了軟件架構的設計方法論。Shaw將衆多的設計風格分類爲以下8種：功能分解、數據流、面向對象、狀態機、面向事情、過程控制、數據結構及決定表。

架構框架是來爲詳細而完整的框架，它爲開發特定領域的應用系統使用了一系列多種架構設計風格。一個採用了某些設計風格的軟件架構製品，只有當它具備完備的文檔，並具有包含一個特定的應用領域所須要的充分靈活性時才能夠做爲軟件框架來重用。

架構平臺提供了一個能夠適應多種應用系統的靈活的底層結構，架構平臺的設計目的便是爲了應用軟件的互操做性提供硬件平臺及操做系統平臺無關環境。咱們能夠將它們用作底層結構，以促進對象級的協做和重用。對象管理組織(OMG)的通用對象請求代理體系結構（Common Object Request Broker Architecture，CORBA）便是一個示例。

4、架構評估方法

軟件構架的評估方法：SAAM和ATAM。這裏只詳細說明ATAM方法。

ATAM一種進行構架評估的綜合方法，ATAM是評估軟件構架的一個健壯的方法。在該方法中，項目決策者和涉衆要清晰地闡述一個準確的質量屬性需求列表（以場景的方式），並說明與實現每一個高優先場景相關的構架決策。而後，把這些決策肯定爲有風險決策或無風險決策，以找到構架中任何存在問題的地方。

ATAM不是需求評估。

ATAM不是代碼評估。

ATAM不包括實際的系統測試。

ATAM不是一個準確的手段，但它識別了構架中可能存在風險的區域。這些風險包含在敏感點和權衡中。

ATAM活動的4個階段：

在第0階段（合做關係和準備）肯定細節：人員名單，時間，地點；評估小組獲取資料並進行初步瞭解分析。

第1階段，評估階段，決策者參與，小組開始信息收集與分析；耗時約1周。1～2週中斷期，評估小組進一步以非正式方式瞭解構架。

第2階段，評估階段，涉衆參與，分析繼續；約2天。

第3階段，後續階段，生成最終報告，進行評估活動總結；1周。

評估階段的步驟：

第1步：ATAM方法的表述。評估負責人向決策者表述ATAM方法，使你們理解其過程，瞭解角色佈局。

第2步：商業動機的表述。決策者介紹系統商業動機、重要功能、各類限制（任何相關的技術、管理、經濟和政治限制）、商業目標和上下文、主要的涉衆、驅動因素等。

第3步：構架的表述。首席設計師或架構小組介紹構架，技術限制、所用模式等。

第4步：對構架方法進行分類。評估小組利用全部已知信息對構架方法進行分類。

第5步：生成質量屬性效用樹。生成質量屬性效用樹，捕獲詳細的需求信息，爲每一個場景分配一個級別，如（高，中），前者爲重要度，後者爲實現難易度，重點放在（高，高）的場景；此處場景具有刺激、環境、響應三要素就能夠了。

第6步：分析構架方法。評估小組分析全部重要場景，設計師解釋如何支持該場景，檢查所用構架方法，分析風險點、權衡點、敏感點。

通過一段中斷期，第2階段開始，此時涉衆開始參與；首先仍然須要一個對ATAM方法的介紹，並使涉衆瞭解已有的成果。

第7步：集體討論並肯定場景的優先級。集體討論並分析場景的優先級，以瞭解更普遍的涉衆的想法；該過程可能產生新的場景；使用「有限票數法」投票肯定每一個場景的優先級——此處不考慮實現難度。

第8步：分析構架方法。分析新的高優先級的場景，構架師解釋構架是怎麼知足各場景的。

第9步：結果表述。總結評估結果，評估負責人展現該結果。

5、軟件架構風險管理

一、如何識別軟件架構的風險

（1）需求的不斷變化

（2）架構師對於技術理解不足

（3）缺少對行業的研究

（4）經驗不足

（5）創造性的架構比重比較重

（6）沒有造成一套構架的規範

（7）架構可執行性差

二、如何規避軟件架構風險

固化需求

完善的業務原型

完整架構規範

驗證架構的可執行性

80%的經驗架構+20%的創新架構