幾年前，我們（peter eeles和peter cripps）開始注意到grady booch首創的《軟體架構手冊》（《handbook of software architecture》，www.handbookofsoftwarearchitecture.com ）。grady起初的目的是：
整理許多有趣的軟體密集型系統的架構，以揭示它們的基本模式以及允許在域和架構風格之間進行比較的方式，並把它們呈現出來。
當grady正關注於最終架構的時候，我們感到理解成功架構師建立他們的架構時所遵循的流程同樣很有趣。當然，我們最終的目的是複製他們的成功。我們花了好幾年的時間才完成這個過程。我們做了許多專案，和許多架構師進行了交流，還對許多開發方法進行了梳理——所有這些都有助於我們理解當構建乙個軟體系統時起作用和不起作用的因素的本質。《架構實戰--軟體架構設計的過程》 是我們經歷的這個過程的總結。
應該指出的是，《架構實戰--軟體架構設計的過程》 沒有指定乙個專門的軟體開發方法。更確切地說，本書講述了人們在支援構建過程的任意現代開發方法中可能遇到的關鍵因素。
本書大致分為三個部分：
第1~5章為第一部分，概述了架構、架構師、架構設計、編寫軟體架構文件、可重用架構資源的核心概念。
第6~9章為第二部分，這部分包含了相關案例研究的章，通過乙個基於樣例應用程式的典型軟體開發專案，重點體現架構師這個角色，提供乙個指導性指南。這些章的編寫方式，使你很容易找到感興趣的特定主題。每個相關案例研究的章主要按照任務進行組織，另外，在這些章中我們使用了一些排版體例。特別是，對流程元素的所有引用，如任務、工件和角色，都用黑體加以強調，例如當我們描述軟體架構文件工件的時候。
第10章為第三部分，包含額外討論的話題和思考，尤其是，在前面的章中描述的概念如何應用於架構複雜的系統。
在本書中，你還會發現一些如下進行分類的有用的補充內容：
檢查清單補充內容： 包含當執行某一特定任務時，可以進行檢查的有用的專案。
最佳實踐補充內容： 介紹已經在實踐中證實為有效的方法。
缺陷補充內容： 介紹最好避免的方法，因為它們會導致負面效果。
我們在本書中大範圍地使用統一建模語言（uml）來描述架構的某些方面。所有的uml圖表都是通過ibm rational software architect建立的。
本書有乙個附屬的站點： processofsoftwarearchitecting.com ，讀者可以在這個站點上找到額外的資訊，也可以和作者進行交流。
軟體架構設計過程
一般軟體的設計過程分為以下幾步 1.概念化階段 2.分析階段 3.架構設計階段 4.並行開發和測試階段 5.驗收與交付階段 架構師的架構設計過程 1.需求分析 2.領域建模 3.確定關鍵需求 4.概念性架構設計 5.細化結構 6.驗證架構 需求分析 主要是對客戶提出的需求的均衡考慮以及隱藏需求的挖掘...
軟體架構設計 一 軟體架構設計過程
軟體架構設計尚沒有萬靈的方 支援，還是個非常新興的行業，給出個人理解的行業軟體架構設計過程，受個人水平有限，僅供參考 1.業務分析 針對目標行業的業務戰略 藍圖 業務功能及流程進行分析，提出其中部分功能可以使用資訊化進行處理，通過分析可以得出資訊化要解決的問題。2.解決方案設計 根據業務戰略，形成行...
架構實戰 軟體架構設計的過程讀後感（三）
本書第五張主要講述了 可重用架構資源 由於我參與開發實際專案並不多，所以對軟體重用體會和理解並不是很深，故查閱了相關資料，結合書上的敘述和例子，有了乙個巨集觀的了解。乙個可重用資源可以代表乙個可重用需求 在不同系統裡反覆出現的需求 可重用的解決方案元素 乙個架構模式或者可重用 可重用測試 可重用的方...