2.2 軟件架構是什么

系統工程領域中的很多研究團體和個人，都對軟件架構給出了自己的解讀，他們從不同的視角闡述了怎樣才能把軟件系統的架構較好地表示出來。這些解讀方式或視角，都有其合理的地方，它們本身并沒有問題。筆者認為，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 反復運用軟件架構原則來描述組件依賴關系

我們可以把圖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系統進行討論。