軟考架構師（8）——軟件架構設計

全文連接：http://www.javashuo.com/article/p-ofmsztfa-gz.html

一：架構模型

　　軟件架構可概括爲

（1）結構模型：這是一個最直觀、最廣泛的建模方法。這種方法以架構的構件、鏈接件（connector）和其餘概念來刻畫結構，併力圖經過結構來反映系統的重要語義內容，包括系統的配置、約束、隱含的假設條件、風格、性質等。研究結構模型的核心是架構描述語言。

（2）框架模型：框架模型與結構模型相似，但它不太側重描述結構的細節而更側重於總體的結構。框架模型主要以一些特殊的問題爲目標創建只針對和適應該問題的結構。

（3）動態模型：動態模型是對結構或框架模型的補充，研究系統的「大顆粒」的行爲性質。例如，描述系統的從新配置或演化。動態能夠指系統整體結構的配置、創建或拆除通訊通道或計算的過程。這類系統常是激勵型的。

（4）過程模型：過程模型研究構造系統的步驟和過程。於是結構是遵循某些過程腳本的結果。

（5）功能模型：該模型認爲架構是由一組功能構件按層次組成，下層向上層提供服務。它能夠看做是一種特殊的框架模型。

5種，但各有所長，將它們有機統一塊兒來也許更合適，因此有人提出了「4+1」視圖模型： 

邏輯視圖：邏輯視圖關注功能，不只包括用戶可見的功能，還包括爲實現用戶功能而必須提供的"輔助功能模塊"；它們多是邏輯層、功能模塊等。

開發視圖：開發視圖關注程序包，不只包括要編寫的源程序，還包括能夠直接使用的第三方SDK和現成框架、類庫，以及開發的系統將運行於其上的系統軟件或中間件。開發視圖和邏輯視圖之間可能存在必定的映射關係：好比邏輯層通常會映射到多個程序包等。

處理視圖：處理視圖關注進程、線程、對象等運行時概念，以及相關的併發、同步、通訊等問題。處理視圖和開發視圖的關係：開發視圖通常偏重程序包在編譯時期的靜態依賴關係，而這些程序運行起來以後會表現爲對象、線程、進程，處理視圖比較關注的正是這些運行時單元的交互問題。
物理視圖：物理視圖關注"目標程序及其依賴的運行庫和系統軟件"最終如何安裝或部署到物理機器，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性等要求。物理視圖和處理視圖的關係：處理視圖特別關注目標程序的動態執行狀況，而物理視圖重視目標程序的靜態位置問題；物理視圖是綜合考慮軟件系統和整個IT系統相互影響的架構視圖。

場景（scenarios）：能夠看做是那些重要系統活動的抽象，它使四個視圖有機聯繫起來，從某種意義上說場景是最重要的需求抽象。在開發架構時，它能夠幫助設計者找到架構的構件和它們之間的做用關係。同時，也能夠用場景來分析一個特定的視圖，或描述不一樣視圖構件間是如何相互做用的。場景能夠用文本表示，也能夠用圖形表示。

二：架構需求與軟件質量屬性

1：軟件質量屬性

一是可在運行時肯定的系統系統質量屬性，如性能，安全性，可用性和使用性

二是沒法經過觀察系統運行肯定的：可更改性，可移植性，可重用性，可集成性，可測試性

三是架構直接相關的：概念完整性，正確性，完整性，可構建性。

一、可用性及其實現
故障處置。
1）錯誤檢測
日誌 心跳 異常捕捉
2）錯誤恢復
冗餘，備件，回滾，事務，降級
3）錯誤預防
事務等

二、可修改性及其實現
1）將修改限制在局部
高內聚低耦合，下降對其餘模塊的依賴；提升模塊的通用性；限制變動範圍等；
2）防止連鎖反應
對擴展開放， 對更改關閉。
3）推遲綁定時間
配置文件，多態，註冊

三、性能及其實現
1）減小及控制資源使用
2）資源管理
引入併發，緩存，增長資源
3）資源仲裁
資源調度

四、安全性及其實現
1）防護攻擊
2）檢測攻擊
3）恢復

五、可測試性及其實現
1）輸入輸出
記錄，接口與實現分離，用實現替代用於測試
2）內部監控

六、易用性及其實現
1）運用時
記錄用戶習慣，收集用戶反饋
2）設計時
用戶接口獨立
3）支持用戶主動操做

2：軟件架構評估

名詞解釋

敏感點：敏感點是一個或多個構件（和/或構件之間的關係）的特性。研究敏感點可以使構設計師或系統分析師明確在搞清楚如何實現質量目標時應注意什麼。

權衡點：權衡點是影響多個質量屬性的特性，是多個質量屬性的敏感點。

風險點

非風險點

質量屬性效應樹：

軟件評估方式：

基於調查問卷（檢查表）的方式

基於度量的方式

基於場景的方式：

架構權衡分析法（ATAM）

軟件架構分析法（SAAM）

成本效益分析法（CBAM）

 

三：軟件架構風格

架構設計的一個核心問題是能可否達到架構級的軟件服用

架構風格反映了領域中衆多系統所共有的結構和語義特性，並指導如何將各個構件有效地組織成一個完成的系統

軟件架構風格是描述某一特定應用領域中系統組織方式的慣用模式（idiomatic paradigm）。

1：數據流風格

　　在管道/過濾器風格中，每一個構件都有一組輸入和輸出，構件讀輸入的數據流，通過內部處理，
而後產生輸出數據流。傳統的編譯器一直被認爲是一種管道系統，在該系統中，一個階段（包括詞法分析、語法分析、語義分析和代碼生成）的輸出是另外一個階段的輸入。

2：面向對象風格

面向對象風格創建在數據抽象和麪向對象的基礎上，數據的表示方法和它們的相應操做封裝在一個抽象數據類型或對象中。這種風格的構件是對象，或者說是抽象數據類型的實例。

2：調用返回風格

3：獨立構件風格

4：虛擬機風格

5：倉庫風格

黑板風格：語音識別的應用

6：基於事件的隱式調用

基於事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件。系統中的其它構件中的過程在一個或多個事件中註冊，當一個事件被觸發，系統自動調用在這個事件中註冊的全部過程，這樣，一個事件的觸發就致使了另外一模塊中的過程的調用。

6．C2風格

C2（Component-Connector）架構風格能夠歸納爲：

經過鏈接件綁定在一塊兒的按照一組規則運做的並行構件網絡。C2風格中的系統組織規則以下：

（1）系統中的構件和鏈接件都有一個頂部和一個底部。

（2）構件的頂部應鏈接到某鏈接件的底部，構件的底部則應鏈接到某鏈接件的頂部，而構件與構件之間的直接鏈接是不容許的。

（3）一個鏈接件能夠和任意數目的其它構件和鏈接件鏈接。

（4）當兩個鏈接件進行直接鏈接時，必須由其中一個的底部到另外一個的頂部。從C2風格的組織規則和結構圖中，咱們能夠得出C2風格具備如下特色：

（1）系統中的構件可實現應用需求，並能將任意複雜度的功能封裝在一塊兒。

（2）全部構件之間的通信是經過以鏈接件爲中介的異步消息交換機制來實現的。

（3）構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制線程之類的相關性假設。

 

6：兩層 C/S 架構

C/S架構的優勢主要在於系統的客戶應用程序和服務器構件分別運行在不一樣的計算機上，系統中每臺服務器均可以適合各構件的要求，這對於硬件和軟件的變化顯示出極大的適應性和靈活性，並且易於對系統進行擴充和縮小

7：三層C/S架構

8：三層 B/S 架構

不足：

B/S 架構缺少對動態頁面的支持能力，沒有集成有效地數據庫處理功能

B/S架構的安全性難以控制

採用B/S架構的應用系統，在數據查詢等響應速度上，要遠低於C/S架構

B/S架構的數據提交通常以頁面爲單位，數據的動態交互性不強，不利於OLTP應用

9：混合架構風格

 

10：富換聯網應用（RIA）

 

RIA-AJAX

11：基於服務的架構（SOA）

服務是一種爲了知足某項業務需求的操做，規則等的邏輯組合，它包含一系列有序活動的交互，爲實現用戶目標提供支持。

基於服務的架構（SOA）到實現方式：

1：WebService

2：ESB

12：特定領域軟件架構（Domain Specific Software Architecture，DSSA）

DSSA是在一個特定應用領域中爲一組應用提供組織結構參考的標準軟件架構，是一個特定的問題領域中支持一組應用的領域模型、參考需求、參考架構等組成的開發基礎，其目標是支持在一個特定領域中多個應用的生成。

從功能覆蓋的範圍角度能夠有兩種理解方式：

（1）垂直域：定義了一個特定的系統族，包含整個系統族內的多個系統，結果是在該領域中可做爲系統的可行解決方案的一個通用軟件架構。

（2）水平域：定義了在多個系統和多個系統族中功能區域的共有部分，在子系統級上涵蓋多個系統族的特定部分功能，沒法爲系統提供完整的通用架構。

DSSA的基本活動包括：領域分析，領域設計，和領域實現。

其中：

領域分析的主要目的是獲取領域模型，領域模型描述領域中系統之間共同的需求，即領域需求，

領域設計的主要目的是獲取DSSA，DSSA描述領域模型中表示需求的解決方案，

領域實現的主要目的是依據領域模型和DSSA開發和組織可重用信息，並對基礎軟件架構進行實現。

DSSA的參與者：主要包括領域工程人員和應用工程人員

領域工程人員：

領域專家：有經驗的用戶，提供關於領域中的系統需求規約和實現知識以及複審領域模型

領域分析人員：控制領域分析過程，獲取領域知識，並將領域知識組織到領域模型中

領域設計人員：設計DSSA，驗證DSSA的準確性與一致性

領域實現人員：根據領域模型和DSSA，開發可服用的軟件架構，利用在工程技術從現有系統中提取可複用的軟件構件

應用工程人員

系統分析人員：以領域模型爲基礎2，結合系統的個性差別，獲取其應用需求

系統設計人員：以領域設計框架爲基礎，給出應用系統的總體架構

系統實現人員：按照真題設計框架，將構件鏈接起來，已建立應用系統

 

 

 四：軟件產品線

軟件產品線主要由兩部分組成，分別是核心資源和產品集合。核心資源是領域工程的全部結果的集合，是產品線中產品構造的基礎。

軟件產品線開發有4個基本技術特色，即過程驅動、特定領域、技術支持和架構爲中心。與其餘軟件開發方法相比，組織選擇軟件產品線的宏觀上的緣由有：對產品線及其實現所需的專家知識領域的清楚界定；對產品線的長期遠景進行了戰略性規劃。