架構的定義

軟體架構仍在不斷髮展中，還沒有形成一個統一的、公認的定義，這裡僅舉出幾個較為權威的定義。

1. 軟體或計算機系統的軟體架構是該系統的一個（或多個）結構，而結構由軟體元素、元素的外部可見屬性及它們之間的關係組成。

2. 軟體架構為軟體系統提供了一個結構、行為和屬性的高階抽象，由構成系統的元素的描述、這些元素的相互作用、指導元素整合的模式的約束組成。

3. 軟體架構是指一個系統的基礎知識，它具體體現在：系統的構件，構件之間、構件與環境之間的關係，以及指導其設計和演化的原則上。（IEEE1471-2000）
   
   
   從技術角度看，軟體架構的重要性：

   1. 專案關係人之間交流的平臺

   2. 早期設計決策。從軟體生命週期來看，軟體架構是所開發系統的最早設計決策的體現。
      

      表現為： （1）架構明確了對系統實現的約束條件；（2）架構影響著系統的質量屬性；（3）架構可以用來預測系統的質量；（4）架構為維護的決策提供依據；（5）架構有助於原型開發。

   3. 在較高層面上實現軟體複用

   4. 架構對開發的指導與規範意義不容忽略

基於架構的軟體開發模型則明確地把整個軟體過程劃分為：架構需求、設計、文件化、評審（評估）、實現、演化等 6 個子過程。

架構的模型

最常用的是結構模型和動態模型。

1. 結構模型。這是一個最直觀、最普遍的建模方法。這種方法以架構的構件、連線件和其他概念來刻畫結構，併力圖通過結構來反應系統的重要語義內容，包括系統的配置、約束、隱含的假設條件、風格、性質。研究結構模型的核心是架構描述語言
   。
2. 框架模型。框架模型於結構模型類似，但它不太側重描述結構的細節而更側重於整體的結構。框架模型主要以一些特殊的問題為目標建立只針對和適應問題的機構。
3. 動態模型。動態模型是對結構或框架模型的補充，研究系統“大顆粒”的行為性質。例如，描述系統的重新配置和演化。動態可能指系統總體結構的配置、建立或查出通訊通道或計算的過程。
4. 過程模型。過程模型研究構造系統的步驟和過程。因而結構是遵循某些過程指令碼的結果。
5. 功能模型。該模型認為架構由一組功能構件按層次組成，且下層向上層提供服務。它可以看做是一種特殊的框架模型。

“4+1”檢視模型從 5 個不同的視角包括邏輯檢視、程序檢視、物理檢視、開發檢視、場景檢視來描述軟體架構。每一個檢視只關心繫統的一個側面，5 個檢視結合在一起才能反應系統的軟體架構的全部內容。如下圖所示：

軟體質量屬性

軟體架構風格

這部分內容比較多，我又總結了另一篇文章
軟考-系統架構設計師（軟體架構風格）

層次系統架構風格

二層C/S架構

提出的原因：C/S架構是基於資源不對等，且為實現共享而提出來的

結構：C/S結構將應用一分為二，伺服器（後臺）負責資料管理，客戶機（前臺）完成與客戶的互動任務。

優點：C/S軟體架構具有強大的資料操作和事物處理能力，模型思想簡單，易與人們理解和接受。

侷限： （1）二層C/S結構為單一伺服器且以區域網為中心，所以難以擴充套件至大型企業廣域網或Internet；
（2）軟、硬體的組合及整合能力有限；
（3）伺服器的負荷太重，難以管理大量的客戶機，系統的效能容易變壞；
（4）資料安全性不好。

三層C/S架構

結構：將應用功能分成表示層、功能層和資料層三個部分

• 表示層：是應用的使用者介面部分，它負擔著使用者與應用間的對話功能。它用於檢查使用者 從鍵盤等輸入的資料，並顯示應用輸出的資料。在變更使用者介面時，只需修改顯示控制和資料檢查程式，而不影響其他兩層。檢查的內容也只限於資料的形式和取值的範圍，不包括有關業務本身的處理邏輯。
• 功能層：相當於應用的本體，它是將具體的業務處理邏輯編入程式中。而處理所需的資料則要從表示層或資料層取得。表示層和功能層之間的資料互動要儘可能簡潔。
• 資料層：就是資料庫管理系統，負責管理對資料庫資料的讀寫。資料庫管理系統必須能迅速執行大量資料的更新和檢索。因此，一般從功能層傳送到資料層的要求大都使用 SQL 語言。

解決方案：對這三層進行明確分割，並在邏輯上使其獨立。原來的資料層作為資料庫管理系統已經獨立出來，所以，關鍵是要將表示層和功能層分離成各自獨立的程式，並且還要使這兩層間的介面簡潔明瞭。一般情況下是隻將表示層配置在客戶機中，如果將功能層也放在客戶機中，與二層 C/S 結構相比，其程式的可維護性要好得多，但是其他問題並未得到解決。客戶機的負荷太重，其業務處理所需的資料要從伺服器傳給客戶機，所以系統的效能容易變差。如果將功能層和資料層分別放在不同的伺服器中，則伺服器和伺服器之間也要進行資料傳送。但是，由於在這種形態中三層是分別放在各自不同的硬體系統上，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。

B/S 架構風格

使用技術：B/S 結構主要是利用不斷成熟的 WWW 瀏覽器技術，結合瀏覽器的多種指令碼語言，用通用瀏覽器就實現了原本需要複雜的專用軟體才能實現的強大功能，並節約了開發成本。

優點：基於 B/S 架構的軟體，系統安裝、修改和維護全在伺服器端解決（零客戶端），很容易在執行時自動升級。也可以更加充分利用網路上的各種資源，同時應用程式維護的工作量也大大減少。

不足：（1）B/S 架構缺乏對動態頁面的支援能力，沒有整合有效的資料庫處理功能；
（2）採用 B/S 架構的應用架構，在資料查詢等響應速度上，要遠遠地低於 C/S 架構；
（3）B/S 架構的資料提交一般以頁面為單位，資料的動態互動性不搶，不利於線上事務處理（OnLine Transaction Processing，簡稱 OLTP ）應用。

MVC架構風格

定義：全名是 Model ViewController，是模型（model）- 檢視（view）- 控制器（controller）的縮寫，分層架構的一種。

分工協作：

• Model 是對應用狀態和業務功能的封裝。Model 接受 Controller 的請求並完成響應的業務處理，在狀態改變的時候向 View 發出相應的通知。
• View 實現視覺化介面的呈現並捕捉終端使用者的互動操作（例如滑鼠和鍵盤的操作）。
• Controller 會根據需要控制原 View 或者建立新的 View 對使用者互動操作予以響應。View 捕獲到使用者互動操作後直接轉發給 Controller，後者完成相應的 UI 邏輯。如果需要涉及業務功能的呼叫，Controller 會直接呼叫 Model。

MVP架構風格

定義：全稱為 Model-View-Presenter。MVP 是從MVC 演變而來。

與MVC的相同點：基本思想有相通的地方：Model 提供資料，View 負責顯示，Controller/Presenter 負責邏輯的處理。

與MVC的不同點：MVC模式中元素之間“混亂”的互動主要體現在允許 View 和 Model 直接進行“交流”，這在MVP 中是不允許的。在 MVP 中 View 並不直接使用 Model，它們之間的通訊是通過 Presenter （MVC中的Controller）來進行的，所有的互動都發生在Presenter 內部，而在 MVC 中 View 會直接從 Model 中讀取資料而不是通過 Controller。

缺點：由於對檢視的渲染放在了 Presenter 中，所以檢視和 Presenter 的互動會過於頻繁。還有一點需要明白，如果 Presenter 過多的渲染了檢視，往往會使得它與特定的檢視的聯絡過於緊密。一旦檢視需要變更，那麼 Presenter 也需要變更了。

優點：（1）模型與檢視完全分離，我們可以修改檢視而不影響模型；
（2）可以更高效的使用模型，因為所有的互動都發生在一個地方——Presenter 內部。
（3）我們可以將一個 Presenter 用於多個檢視，而不需要改變 Presenter 的邏輯。這個特性非常的有用，因為檢視的變化總是比模型的變化頻繁；
（4）如果我們把邏輯放在 Presenter 中，那麼我們就可以脫離使用者介面來測試這些邏輯（單元測試）。