架構模型
對於軟件架構這個術語來說，沒有一個標準的、被普遍
接受的定義，因爲它還是一門年幼的學科，……雖然沒
有標準的定義，卻也不乏定義……
卡內基·梅隆大學軟件工程學院
本章提出了一個用於構建容錯系統的軟件架構。雖然每個人對於架構一詞都有一個模糊的概念，但是這個詞卻幾乎沒有一個廣爲接受的定義，這就導致了很多誤解。我認爲如下定義對軟件架構進行了比較全面的總結：
架構是一組有關軟件系統組織方式的重要決策；是對系統構成元素、元素接口以及這些元素間協作行爲方式的選擇；是一種把這些結構和行爲元素逐步組合爲更大子系統的合成方式；也是一種構建風格，在其指導下把這些元素、元素接口、元素間的協作和合成組織起來。
Booch，Rumbaugh 和 Jaclbson[19]
2.1 架構的定義
從最高的抽象層次上看，架構就是“一種思考世界的方式”。然而，從實用性的層次上看，我們就必需得把我們看待世界的方式轉化爲一本實用的手冊和一組規程，它們可以告訴我們如何使用我們看待世界的特定方式來構造一個特定的系統。
我們的軟件架構通過如下一些方面來刻畫：
1．問題領域——我們的架構是爲解決什麼類型的問題而設計的？軟件架構一定不是通用的，而是爲解決某一類特定問題而設計的。缺少了關於用來解決哪類問題的描述的架構是不完整的。
2．哲學—— 軟件構造方法背後的原理是什麼？架構的核心思想是什麼？
9
3．軟件構造指南——我們如何來規劃一個系統？我們需要一個明確的軟件構造指南集。我們的系統將由一個程序員團隊來編寫和維護——所以對所有的程序員和系統設計者來說，理解系統的架構和它的潛在哲學是很重要的。從實用性的角度來講，這些知識以軟件構造指南的方式表現出來更便於維持。一個完整的軟件構造指南集包括編程規則集、例子程序和培訓資料等等。
4．預先定義好的部件——以“從一組預先定義好的部件中選擇”的方式進行設計遠比“從頭設計”的方式要來得容易。Erlang的OTP庫包含了一個完整的現成部件集（稱之behaviour庫），一些常用的系統都可以使用這些部件構建起來。例如gen_server這種behaviour就可以用來構建client-server系統，gen_event這種behaviour可以用來構建基於事件（event-based）的程序。關於預定義部件的更完整的討論見6.1節。6.2.2節將給出一個關於如何使用gen_server這種behaviour來編寫一個服務器軟件的簡單例子。
5．描述方式——我們如何描述某一部件的接口？我們如何描述系統中兩個部件之間的通信協議？我們如何來描述系統中的靜態和動態結構？爲了回答這些問題，我們將介紹一些專門的符號。其中一些用來描述程序的API，而其他的則用來描述協議和系統結構。
6．配置方式——我們如何來啓動、停止和配置我們的系統？我們可以在系統工作過程中進行重配置嗎？
2.2 問題領域
我們的系統最初是爲開發電信交換系統而設計的。電信交換系統對可靠性和容錯性有着苛刻的需求。電信系統需要“永久地”運行，必須有軟實時的響應能力，當發生軟件和硬件故障的時候要有合理的反應。Däcker[30]給出了電信系統需要具有的十條屬性要求。
1．系統必須能夠應對超大量的併發活動。
2．必須在規定的時刻或規定的時間內完成任務。
10
3．系統應該可以跨計算機分佈運行。
4．系統要能夠控制硬件。
5．軟件系統往往很龐大。
6．系統要具有複雜的功能，例如：特性衝突。
7．系統應該能不間斷運行許多年。
8．軟件維護（例如重配置等）應該能在不停止系統的情況下進行。
9．滿足苛刻的質量和可靠性需求。
10．必須提供容錯功能，包括硬件失靈和軟件錯誤。
我們可以對上述需求作出如下分析：