An Introduction to Software Architecture

在找軟體架構相關書籍的過程中找到這篇Paper。雖然年代久遠(1994)，不過內容頗值得一讀。尤其是相較於其他專書，雖然缺乏了針對Quality Metrics深入的說明，但是針對一個問題，逐一用不同的solution去探討使用各種架構的優缺點。當中的架構其實也的確是我們常用的架構(相較於我找的書籍中的範例)。篇幅不大，也算是優點之一。


(譯)
簡介

隨著軟體系統的大小及複雜度的增加，設計的問題逐漸超越演算法及資料結構的層次，設計及定義系統概略的架構成為一種新興問題。結構性的議題包含：組織概略及全域控制的結構、將功能分配給設計的基本元素、擴大應用的規模及效能問題、以及從不同的設計方案中做決定。

這就是在軟體架構此一層級的設計。在這一主題上有相當多的工作成果，包含模組連接的程式語言，針對不同領域系統的模板及架構，以及元件整合機制的正規模型等。除此之外，沒有被特別提出的工作成果，包函各種非正式用以描述系統架構的詞彙。雖然目前沒有定義玩良好的語彙或者標記法以描述建築結構的特性，但是好的軟體工程師使用常見的結構原則來設計複雜的軟體。許多原則代表隨著時間逐漸產生的經驗法則或者慣用模型。其他原則則是更加謹慎的被記錄於工業或者科學的標準。


有效率的軟體工程有賴於軟體架構設計的能力變得越來越清楚。首先，辨識常見的典範讓人能理解系統之間高階的關係，讓新系統可以以舊系統的變化來建構是很重要的。第二，使用正確的系統架構經常對軟體設計是否成功有重要的影響。第三，對軟體結構精確的了解允許工程師根據原則從不同的設計中選取適合的方案。第四，結構系統的呈現通常是分析及描述複雜系統的高階屬性不可或缺的一環。

這篇文章簡介軟體架構的範疇，目的是說明各種方法目前的狀態，並且檢視各種架構設計影響軟體設計的方式。這篇文章中呈現的素材來選自於作者在CMU所教授的Architectures for Software Systems這堂課。自然而然，這樣一篇短文只能簡略的彰顯此一領域的主要特徵。選取的素材強調非正式的描述，並且省略關於制訂規範格，評估，從不同的選擇方案中選擇等課程內容。我們希望藉以揭露這個新興領域的本質及重要性。



後續的章節我們提出幾種不同時下常見的的架構形式，並且示出混合的形式如何可以在單一的設計中合併。接著用六個案例來說明軟體結構的呈現如何加強我們對複雜系統的理解。最後我們調查這個領域中較顯著的問題，並且考慮幾個可能的研究的方向。

( ... 後省略 )



從程式語言到軟體架構

程式語言及工具的進展的特色，就是造成了抽象化的等級，或者說，軟體設計構築單位概念上的大小。為了要了解這個領域，讓我們先了解一下「抽象化」這個技巧在歷史上的發展。

2.1 高階程式語言
數位電腦在1950年出現之後，軟體一開始用機械語言撰寫。插入新指令需要用手算的方式檢查整個程式的更新，包含插入之後影響到的參考資料以及移動的指令。後來人們發現，記憶體分布以及參照資料的更新可以被自動化，而指令以及記憶體味指也可以用符號來表達。結果產生了可以使用符號的組譯器。緊接著是巨集處理器，用一個符號來代表一連串常用的指令。這種用符號來取代運算指令以及記憶體位址的方式也許是抽象化最早的形式。

1950後期，某些執行模式常見而有用越來越明顯。實際上，這些人們透徹的瞭解這些模式，並且能夠根據接近數學的表示方法自動產生機械碼。最初的模式包含了算數運算，程序呼叫，迴圈及選擇性敘述。一系列早期的高階語言時捕捉了這些精神，其中Fortran是目前主要的倖存者。

高階語言允許較複雜的程式得以開，緊接著資料使用的模式出現了。在Fortran中，資料型別是用來選擇正確機械指令的來源，Algo及其後繼者將資料用來陳述程式員的意圖。這些語言的編譯器可以建立於Fortran的經驗之下，並且處理複雜的編譯問題。此外，編譯器檢查這些意圖是否一致，讓程序員有使用者些型別的誘因。

2.2 抽象化資料類別
1960後期，好的程式設計師都知道： 如果你使用正確的資料結構，這些努力可以讓你開發其他的程式更加容易。抽象的資料型態開發可以示作這種想法的實現。將這種想法從理論化為實踐牽涉下面的理解：

* 軟體結構 ( 與基礎操作封裝的呈現方式 )
* 規格 ( 用抽象化模型或者代數公式表達 )
* 語言議題 ( 模組， scope ，使用者定義型別)
* 結果的一致性 ( 資料結構的恆定及保戶以避免其他操作)
* 合併型別的規則 ( 宣告 )
* 資訊封裝 ( 保護那些沒有明定於規範中的屬性 )

這些成果提升某些軟體系統的設計層級至抽象化的資料結構，超越程式語言中每一個敘述或者個別演算法的層級。這些抽象化導致對單一特定目標模組良好組織的理解。這牽涉到用一個方法合併表示方式，演算法，規範，及功能界面。某些程式語言的支援是必要的，但是抽象化資料型別的思維允許我們根據資料類別的語彙開發系統成分的功能，而非從程式語言所提供的建構單位出發做為語彙思考。

軟體架構
(呼~~ 還在講解歷史 ， 終於比較靠近正題了)
就像1960後期好程式員發現有域的資料結構，好的系統設計師也發現了有用的系統組織。其中之一是基於抽象化資料型態的理論。但是這並非組織系統唯一的方式。

許多組織的方法隨時非正式的發展。舉例來說，典型的軟體架構描述如下：

* Camlot 建構於 client-server 模型，並且在本地端及遠端皆使用remote procedure call的方式，進行server及client的溝通。

*抽象化分層級系統解構讓客戶端看到的統一的系統形式，讓Helix可以容納各種不同的裝置。這種架構鼓勵使用client-server模型建構應用程式。

*我們選擇一種分散是，物件導向的方法管理資訊。

* (blah blah blah)

其他軟體架構成為正式文件並且廣為宣傳。例如ISO OSI (分層網路架構)，NIST/ECMA (基於軟體分層的一種常見軟體工程環境架構)， X Window System (基於事件觸發即回呼的分散式視窗系統 )

3. 常見軟體架構型式