架構設計中各個步驟的位置架構
如下是對架構設計的每一個步驟，進行總括的描述測試
1 需求分析
需求分析，是不少活動的統稱，它是「架構設計過程」中第1個大的工做步驟。
需求分析活動輸出的「需求」，必須涵蓋功能、質量、約束這三個方面，這些是後續設計活動所須要的。需求分析工做涉及的「技能項」較多，整體而言可總結爲「兩縱三橫」，如圖所示：
架構設計
· 【一縱】需求溝通。持續伴隨需求分析過程的，是需求溝通、需求啓發、需求驗證等活動，這些活動都要求需方和開發方緊密協同、精誠合做。「閉門造需」危險大了。
· 【二縱】非功能需求的肯定。真實的實踐中，肯定非功能需求是一個持續的過程，是持久戰。究其緣由，這是非功能需求的範圍廣形成的，不管是技術仍是業務、不管是甲方仍是乙方，均可能有這樣那樣的非功能需求。想「一蹴而就」地定義非功能需求是不現實的。
· 【三橫】需求分析主線。從肯定系統目標開始，後續憑藉「範圍+Feature+上下文圖」三劍客研究高層需求，再後續創建開發人員較熟悉的用例模型。
作不到「追根溯源」的需求分析，每每會失敗。所以，咱們補充圖4-6來強調需求分析工做的主線是「肯定系統目標→研究高層需求→創建用例模型」，需求從「高飄」到「落地」，成果項從「目標列表」到「範圍框圖 + Feature樹 + 上下文圖」到「用例圖 + 用例規約」，需求跟蹤脈絡清晰可辨。
設計
需求分析的主線體現「追根溯源」blog
2 領域建模
領域建模，是以提煉領域概念，創建領域模型爲目的的活動。領域建模實踐的精髓是「業務決定功能，功能決定模型」，理解了這個理念，評審領域模型也變得再天然不過了。
領域建模活動的輸入：一是「功能」，二是「可擴展性」具體要求。接口
功能指目前所須要的，可擴展性指之後須要的說到底，都是「功能」，由於領域模型必須能支持在《軟件需求規格說明書》中規定的「如今的功能」，還應該支持隨着業務發展而出現的「將來的功能」。這兩種功能，就是驅動領域建模的因素，以及評審領域模型的依據。開發
3.肯定關鍵需求原型
架構面前全部需求一概平等？不可能。關鍵需求決定了架構的大方向。class
具體而言，爲了肯定「關鍵功能」，一要關注「功能需求」，二要研究「約束需求」；爲了肯定「關鍵質量」，一要關注「質量需求」，二要研究「約束需求」。擴展
4.概念架構設計
概念架構是高層架構成果的核心，框定了架構大方向，是甲方規劃、乙方投標的評定關鍵。
概念性架構界定系統的高層組件，以及它們之間的關係。概念性架構意在對系統進行適當分解，而不陷入細節。藉此，能夠與管理人員、市場人員、用戶等非技術人員交流架構。概念性架構規定了每一個組件的非正式規約及架構圖，但不涉及接口細節。
概念架構設計要「直指」的、以之爲輸入的，是「關鍵需求」。
針對不一樣需求（功能或者質量），須要運用不一樣「技能項」，魯棒圖建模、目標-場景-決策表，很是實用。
概念架構設計的「輸出」是「1個決定、4個選擇」：
1）決定如何劃分頂級子系統；
2）架構風格選型；
3）開發技術選型；
4）二次開發技術選型；
5）集成技術選型。
5 細化架構設計
細化架構和概念架構的關鍵區別之一是：概念架構沒有設計到「模塊 + 接口」一級，而細化架構必須關注「模塊 + 接口」。
下圖列出了細化架構設計的5個設計視圖、15個設計任務。
· 細化架構要爲「需求」而設計。關鍵對比：概念架構設計的輸入是「關鍵需求」、而不是泛泛的全部「需求」。
· 細化架構要在「概念架構」的設計思想下進行。
· 「領域模型」，一方面影響着「邏輯架構視圖」的「領域模型設計」，另外一方面影響着「數據架構視圖」的「存儲格式設計」。
4.2.6 架構驗證
若有必要，須要進行架構驗證。
架構驗證的輸出成果是「架構原型」。和通常的開發不一樣，架構原型的開發不是要完美地、無Bug地實現功能，而是在「細化架構」的整體指導下，僅把存在「風險」的那些設計儘早開發出來，而後經過執行測試等手段判斷「風險」是否解決，以下圖所示。
參考：溫昱《軟件架構設計》