【軟體工程學習筆記】軟體體系結構

4 人贊了文章

體系結構的應用場景

首先需要承認的是，在軟體設計的不同階段需要不同的設計方法。面對不同粒度，不同複雜度的系統，你需要使用不同的思考框架。

體系結構設計與演算法設計就需要不同的思考框架。

在演算法設計中，動態規劃、貪心演算法等這些演算法思想是非常重要的思考方式/思考框架，他們在一定程度上能夠保證快速得到計算的結果。它們面臨的場景更多類似於「快速在某個字元串中快速尋找某個子串」，這樣一些小問題。

演算法雖然能夠攻克粒度較小的問題，但是在構建系統的時候，往往面臨的問題是：軟體系統規模大且複雜性高。這時對系統的全局結構設計和規劃更加重要。比如說，給你一個需求，設計一個圖書管理系統，這時候動態規劃這些思考框架就顯得有些力不從心了。這時候，體系結構設計就應運而生了，體系結構設計是一種構建複雜系統時的思考框架，注意它服務的對象是粗粒度的複雜系統，所以你也不要奢望它能對你的演算法設計有太大的幫助。（正如你不要期待國家的高層，用它的思考方式去解決 如何耕地的細節問題）

理解軟體體系結構

軟體體系結構（Software Architecture）包括構成系統的設計元素的描述、 設計元素

之間的交互、 設計元素的組合模式以及在這些模式中的約束。

理解上述抽象概念並不是一件容易的事情，需要一定的工程經驗。這裡簡單談談自己的理解。

理解的角度1：（集合角度）

在計算機中，集合是我們一個有利的工具，我們定義事物，理解事物都可以從中獲得啟發。在集合中，你需要規定基本的元素（這裡指構件這些要素），同時還需要制定這些元素的聯繫方式（這裡是指元素的組合模式，及模式中的約束），適當的時候你還需要對具有某些特殊性質的元素進行分類（這裡根據元素的作用，將元素分為了兩大類：構件 & 連接件）

接下來，你可以從利用常規的集合理論理解該思考框架了。

理解的角度2：（實際意義）

我們人類解決複雜問題的方式，基本都是採用分解的方式，即分而治之。所以給定一個系統的時候，我們嘗試將其分解成不同的部分，按照一定的劃分標準（比如，功能作用），我們可將其分出實際進行處理的模塊（構件、連接件），以及負責連接（負責通信）的要素（分布，約束）等。

舉個簡單的例子，以 「人體」這個系統為例，根據人體各部分的功能，我們可將人體分為不同的構件：頭、手、中間部位身體、腿。但是只具備這些要素還是不夠的，他們必須連起來，相互配合才能形成真正的人體。

簡而言之，軟體體系結構 = 構件 + 連接件 + 約束 。

接下來，進一步說明其他概念。

構件

構件是具有某種功能的可復用的軟體結構單元，表示系統中主要的計算元素 和 數據存儲。

構件是一個抽象的概念，在程序中可以指程序函數、模塊、對象、類等。

連接件

連接是構件間建立和維護行為關聯與信息傳遞的途徑。連接包含下面兩種要素：

其中，機制指的實際中的消息傳遞方式。

而協議則決定了 消息的語義理解。

連接件表示構件之間的交互並實現構件之間的連接。

軟體體系結構目標

為了更好理解後面的軟體體系結構涉及的原則和體系結構風格，請牢記這些目標，時不時的對照後面的內容回顧這些目標。

所有的設計原則等理論基本上都可以映射到下面一個或幾個目標上。

體系結構的發展

現在軟體的複雜性及多變性，導致了軟體粒度越來越粗，越來越開放。

軟體設計的原則

設計原則是系統分解和模塊設計的基本標準，應用這些原則可以使代碼更加靈活、 易於維護和擴展。這裡提到的設計原則包括以下幾點：

需要指出的是，這些原則有一些交叉的部分，並非完全獨立沒有交集的，理解這一點，你將能更清楚細微的區別。比如：

• 通過封裝來實現模塊化
• 通過將抽象程度相同的模塊放在同一層次，形成層次化的結構。
• 另外，層次化可以理解為模塊化的特例

接下來分別介紹上述原則：

抽象

抽象是關注事物中與問題相關部分而忽略其他無關部分的一種思考方法。

待抽像的例子：

抽象後：

封裝

封裝和信息隱藏是指每個軟體單元對其他所有單元都隱藏自己的設計決策，各個單元的特性通過其外部可見的介面來描述。

【要求】：應將單元介面設計得儘可能簡單，並將單元對於環境的假設和要求降至最低。

舉例：

模塊化

模塊化是在邏輯和物理上將整個系統分解成多個更小的部分，其實質是「分而治之」 ，即將一個複雜問題分解成若干個簡單問題，然後逐個解決。

（一般是先進行邏輯模塊化，隨後進行物理分配）

舉例：

下面的模塊化，主要是指邏輯上的模塊化，並為涉及到如何將這些模塊如何部署到物理機上的過程。

（在物理模塊化的時候，可能將模塊1和模塊3放在同一台機器上，而模塊2放在另一台機器上）

系統分解

模塊化，不可避免的一個問題是，對於系統如何進行分解。在大量實踐中，人們總結出了兩個衡量的原則：高內聚、 低耦合。

舉個簡單的例子：

在一個軟體系統中，有三個子系統A、 B、 C都要訪問一個關係資料庫。

設計方案1：（高耦合方案）

設計方案2：（增加隔離層）

說說這種方案的好處。

設計1中，如果資料庫結構發生變化，那麼你需要分別在A，B，C中分別進行更改，這樣分散的修改，特別容易造成錯誤。而在設計2中，只需要修改Storage層就可以了。

另外，在A，B，C系統中可能有一些共同的讀資料庫操作，比如三個系統中都有ReadAnimal（）這個操作，設計1中需要分別在A,B，C中進行修改，而設計2中將該共用方法提到Storage模塊中，從而修改時，只需要進行一次修改。

PS:

這裡加入Storage，是因為假設3個系統中有一些共同的部分。但是如果子系統沒有任何共享的資料庫數據（每個表被一個系統所獨佔），那麼去掉Storage層也沒有關係，因為資料庫某個表的變化只會影響到一個子系統。

層次化

先給出層次化的表現形式：

個人感覺，層次化是模塊化的一種特例。在模塊化的基礎上，加入了一些限制。在層次化結構中，layer可以作為一種特殊的模塊（包含特定的子系統集合），在這類模塊（layer）的聯繫中，規定了layer模塊只能被設計成類似於雙向鏈表的順序結構，而不能出現樹狀結構或者圖狀結構。

層次化的一些說明：

舉例：Android操作系統

復用

復用（Reuse）是利用某些已開發的、 對建立新系統有用的軟體元素來生成新的軟體系統，其好處在於提高生產效率，提高軟體質量。

• 源代碼復用：對構件庫中的源代碼構件進行復用

? 軟體體系結構復用：對已有的軟體體系結構進行復用

? 框架復用：對特定領域中存在的一個公共體系結構及其構件進行復用

? 設計模式：通過為對象協作提供思想和範例來強調方法的復用

（稍後文章中會對常見的體系結構進行介紹...）

參考：

【學堂在線】軟體工程

推薦閱讀：