《實用軟體架構：從系統環境到軟體部署 》——2.2 軟體架構是什麼

本節書摘來自華章出版社《實用軟體架構：從系統環境到軟體部署》一書中的第2章，第2.2節，作者：[印]蒂拉克·米特拉（tilak mitra）著，愛飛翔　譯，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。<b></b>

<b></b>

<b>2.2　軟體架構是什麼</b>

系統工程領域中的很多研究團體和個人，都對軟體架構給出了自己的解讀，他們從不同的視角闡述了怎樣才能把軟體系統的架構較好地表示出來。這些解讀方式或視角，都有其合理的地方，它們本身并沒有問題。筆者認為，bass、clements和kazman (2012)給出的解釋抓住了軟體架構的本質：

程式或計算機系統的軟體架構，指的就是系統的結構，該結構由軟體元件、外部可見的元件屬性，以及它們之間的關系而構成。

那麼，這個定義意味着什麼呢？

這個定義想要強調的意思，是說軟體架構由粗粒度的構件（也就是軟體元件）組成，這些構件，可以視為架構的建構塊（building block，也稱為組成單元或構造塊）。我們把這種架構的建構塊（architecture building block）簡稱為abb。每一個軟體元件，或者說每一個abb（以後筆者會交替地使用這兩個詞），都具備一些外部可見的屬性，它會把這些屬性展示給架構中的其他abb。至于元件的内部細節究竟應該如何來設計和實作，則與系統的其餘部分沒有關系。軟體元件是作為黑盒而存在的，也就是說，它的内部細節不會暴露給外界，它所暴露的隻是一些屬性，系統中的其他元件，可以協同利用這些屬性，把系統想要展示給使用者的能力實作出來。軟體架構不僅要在最佳的粒度上确定系統中的abb，而且還要根據其展示出來的屬性以及所要支援的能力，來描述每一個abb的特征。軟體架構師必須很好地确定出系統中的abb及其屬性與能力，這樣才能把握住軟體架構的要義。為此，我們要把确定abb及其屬性與能力所用的那套辦法，用一種簡潔、清晰，而又易于了解和交流的形式，正式地描述出來。

軟體工程中的架構工作，指的是把系統分解或劃分為一系列部件，使我們能夠對每個部件都進行子產品式的、疊代式的、漸進式的和獨立式的開發。正如早前所說，這些部件之間可能會具備某些關系，當我們把這些部件交織起來或彙集起來時，應用程式的軟體架構（也就是系統）就搭建出來了。

很對人對架構與設計之間的差別有着一些困惑。按照bass、clements和kazman (2012)的說法，所有的架構都是設計，但設計卻不一定是架構。某些設計模式确實可以令系統更加靈活、更加易于擴充，同時也可以使系統所要滿足的邊界條件得以明确，把這些模式說成架構模式，是沒有問題的。但更具體地來說，架構所要強調的意思是把abb當成黑盒，而設計所注重的則是軟體元件的配置、定制以及内部的工作機理等方面。就軟體元件來說，架構所關注的問題，僅僅是該元件的外部屬性，而設計所關心的問題則更加寬泛，它不一定隻會談論該元件外部的那些屬性，同時還有可能提到元件内部的實作細節。

值得注意的是，軟體架構的原則是可以反複運用的，如圖2-1所示。

我們可以把圖2-1中代表classroom（教室）的軟體元件c1，當成系統架構的一部分。除了c1之外，架構中還有其他一些元件，架構師可以把元件c1連同其屬性、功能方面與非功能方面的能力，以及該元件與其他軟體元件之間的關系，一并分享給系統設計者。像這種由各abb之間的互相關系及其外部可見屬性所構成的集合，就叫作架構藍圖（architecture blueprint）。設計者在分析了c1這個軟體元件之後，感覺它還可以細分為三個更小的元件，也就是代表table（桌子）對象的c11，代表chair（椅子）對象的c12，以及代表blackboard（黑闆）對象的c13，每一個小的元件，都具備一些可供複用的功能，可以用來實作c1所要具備的屬性。設計者會對c11、c12、c13這三個元件及其接口進行細化，并把這三個元件及其接口與關系，當成c1這個軟體元件的架構單元。然後，又可運用同一種思路，分别針對c11、c12及c13繼續進行細化設計，以解決其内部的實作問題。是以，我們可以把一個龐大而複雜的系統，分解為多個小的組成部分，然後對每一個部分繼續進行細化，這種做法，就是對軟體架構原則的遞歸式運用。

正如早前所說的那樣，之是以要給系統制定架構，是為了厘清系統的範圍，使其能夠用适當的abb來滿足行為和品質方面的目标。無論什麼樣的系統，其架構都要能夠較好地為利益相關者所了解，此處所說的利益相關者，既包括使用本架構來進行下遊設計和實作的人，也包括給本架構的定義、維護及增強工作提供資金的人。本章稍後就會更加詳細地讨論這些方面，不過筆者先要在這裡強調一點，那就是溝通的重要性：架構是一種溝通媒介，通過它，我們可以和利益相關者就it系統進行讨論。