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