架構設計過程簡單總結：架構設計的驅動力=功能+質量+約束.功能即系統要滿足的業務需求。質量包括運行期質量和開發期質量. 常見的運行期質量屬性包括軟件系統的易用性、性能、可伸縮性、持續可用性、魯棒性、安全性等。開發期質量屬性是開發人員最為關心的，要達到怎樣的目標應根據項目的具體情況而定。約束可能是商業預算，運行環境，使用人員水平，開發團隊水平等。架構設計過程如下:
一，需求收集，分析。
此處省略2000字。。。 見前篇 《需求收集、分析小結》http://m.tkk7.com/fool/archive/2017/04/28/432489.html
二，概念架構/概念模型
從需求中找出關健、重大需求，進行概念建模.下面三個圖稱之魯棒圖。其中控制對象理解為mvc模式中的控制器和model。使用魯棒圖可以建立概念模型，約等于初步設計。初步設計并不關心細節。
魯棒圖建立概念模型語法:
概念設計舉例：
上次談到超市小票如何分析實體對象,本次接著舉例如何對收銀進行概念建模
如上圖：具備基本收銀功能的概念模型。概念模型建模可以是增量的。比如商品折扣或其它促銷活動等。
概念架構的用途：
1） 可以幫助我們找出領域模型中的實體對象。
2） 檢查需求用例是否正確和完善。
3）初步設計,魯棒圖是一種初步設計技術。
4）根據用例和概念設計劃分系統、子系統、模塊或者包。借助魯棒圖,初步識別功能背后的職責，規劃切分系統的方式。
三，關注非功能性需求，包括運行期質量和開發期質量。
運用目標—場景—決策表對非功能性需求作出決策.小舉例：
| 目標 | 場景 | 決策 |
| 易用性 | 銷售員需要輸入條碼檢索商品,繁瑣且速度慢 | 根據條碼，品名模糊匹配檢索商品,提供輔助錄入。 |
| 性能 | 長時間穩定運行 | 數據庫集群，服務應用集群 |
技術選型 需要管理錢箱、打印機、響應速 pos系統使用c/s
度快
四，細化架構。RUP 4+1視圖法則將架構需要關注的不同的點使用不同的視圖表示.從不同的維度對系統進行解讀,從而形成統一軟件過程架構描述。
運行架構：
關心進程、線程、同步的相關設計，捕捉并發和同步特征
邏輯架構：
關心邏輯層(layer)的劃分，系統/子系統的劃分，劃分模塊及其接口的定義。功能組劃分也屬于邏輯架構.功能:不僅包括用戶可見的功能，還包括為實現用戶功能而必須提供的"輔助功能模塊"；它們可能是邏輯層、功能模塊等。
物理架構：
關心服務器選型，物理層劃分(tier)。 描述如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性等要求.layer就運行在tier上。Tier反映系統伸縮能力。
開發架構：
描述了在開發環境中軟件的靜態組織結構。即開發工具下的開發視圖，描述文件編譯及其依賴關系。而使用maven管理開發的項目編譯及依賴關系結構更加分明。
數據架構：
關心數據的存儲、分布和文件的存放及數據的復制，傳遞，同步。數據的存放包括sql,內存數據庫，nosql數據庫等.
邏輯架構設計舉例：
還是用收銀系統簡單舉例，收銀系統邏輯架構圖如下：
整個系統劃系統為系統，切為兩個系統，一個收銀員角色處理的業務，收銀系統。
一個后臺管理系統。后臺管理系統包括用戶管理模塊，基礎資料模塊（產品資料等）
銷售模塊（本例對銷售單）。另外，因為收銀系統需要和后臺系統交互，把收銀系統需要使用到的相關的各模塊封裝成一個接口模塊，專門處理和收銀系統交互的模塊。系統、模塊之間的通訊方式應當盡量避免雙向。相互依賴可能會引發很多問題。
物理架構設計舉例：
物理架構和邏輯架構可以相互印證。描述軟件系統的物理布署。
如果考慮運行期質量比如長時間運行布署圖可能應用做集群。數據庫做集群等。邏輯層layer運行在物理層tier之上
運行架構和數據架構視圖根據實際情況可選設計