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