功能、質量和商業需求的某個集合塑造了架構，也就是說關鍵需求塑造了架構。
概念性架構設計可以分為以下3步：
1． 魯棒性分析
2． 引入架構模式
3． 質量屬性分析
很多人認為從需求分析到架構設計之間的過渡遇到很多問題，究其根源，可能是以下的原因造成的：
- 用例是面向問題領域的，而設計是面向機器域的，這兩個‘空間’存在對映。
- 用例技術本身不是物件導向的，而設計應該是物件導向的，這是兩種不同的思維方式。
- 用例規約採取自然語言描述，而設計採取形式化的模型描述，描述的方式不一樣。
魯棒圖可以很多的解決需求分析和架構設計之間的差別。
魯棒圖包含3中元素：邊界物件、控制物件和實體物件。
邊界物件是模擬外部環境和未來系統之間的互動進行建模，它負責接收外部輸入、處理內部內容的解釋，並表達或者傳遞相應的結果。
控制物件對行為進行封裝，描述用例中事件流的控制行為。
實體物件對需要儲存的資訊進行描述，它往往來自領域概念，和領域模型中的物件有良好的對應關係。
魯棒圖的三種物件很好的概括了實際系統 中物件的三種職責：互動、控制和資訊。這三種職責和組成架構的抽象元素之間有完美的對應關係：連線元素、處理元素、資料元素。
魯棒圖的本質：
- 參與者只能同邊界物件進行交談
- 邊界物件只能同控制體和參與者進行交談
- 實體物件也只能同控制物件進行交談
- 控制體既能與邊界物件交談，也能同控制物件進行交談，但不能與參與者進行交談。
可以將MVC結構和魯棒圖進行對應，View對應邊界物件，Model對應實體物件，Controller對應控制物件。當然，有時Model中也包含一部分控制物件。
要建立概念性架構，應明確實現預期功能所需的職責模型，研究用例執行的不同場景是一個可取的方法。
所謂軟體架構就是關於如何構建軟體的一些最重要的設計決策，這些決策往往圍繞著將系統分為哪些部分、各部分之間如何互動展開的。
軟體架構模式就是高度抽象的、適用於許多類似系統的、預先定義好的一種特殊的軟體架構。架構模式描述了軟體系統基本的結構化組織方案，具體而言，架構模式提供了一套預定義的子系統，並規定了子系統的職責，以及子系統或自薦關係的組織原則和組織指南。
目前有很多比較成熟的架構模式，我們需要根據專案的具體需求去確定應該採取哪種架構模式。
分層：很流行，最大的優點是將整體問題區域性化，把可能的變化分別封裝在不同的層中，最後，系統被規劃為一個單向依賴的分層體系，利於修改、擴充套件和替換。具體而言，各層之間的單向依賴關係可以分為兩種：嚴格的分層架構要求第n層只能被第n+1層呼叫，於此相對的是不嚴格的分層架構，第n層可以被位於其上層的任意一層呼叫。我們需要注意分層的原則：職責劃分和互動機制。
MVC：鋪天蓋地的一種模式。隨著smalltalk發展而來，有很多變種。包含三種元件：Model、View、Controller。
微核心：最大的優點是適應變化。微核心架構不僅將應用相關部分與通用部分分離，而且又將通用部分進一步分離成一個最小化的基本服務核心和眾多擴充套件服務。微核心不僅提供了一個基本服務的最小集合，這些基本服務遮蔽了其下層複雜環境的影響、並以規範的介面提供給上層的‘增值服務’使用，於是所有這些附加的增值服務都和複雜環境無關。微核心所提供的基本服務必須是完備的，從而實現了一個虛擬機器。這個虛擬機器不僅遮蔽了下層的複雜性，而且建立了更抽象、更易用的一個‘新機器’供其上層使用。
微核心的缺點：1.設計和實現的複雜性；2. 往往比同類情況下其他架構的效能低。
採取微核心架構的原因:1. 可擴充套件性；2. 可移植性；3. 延長軟體系統的生命週期。
元模型架構：一個以適應變化、支援長生命週期為主要目標的架構模式。包括兩個層：基本層和元層次。基本層定義應用，類似於我們要編寫的程式；元層次包含一組‘元物件’，這些元物件組成的模型叫做‘元模型’，元模型是對基本層中的‘一切’的抽象，提供了軟體本身的結構和行為的‘自描述’。
參考文獻：
《軟體架構設計》 溫昱