軟體架構設計的流程

綜上所述，我們就可以比較條理化的建立軟體架構設計的流程了。典型軟體架構設計的
流程如所示。
一、業務架構概念
在構建軟體架構之前，架構師需要仔細研究如下幾個問題：
系統是為什麼目的而構建的？
系統投運後服務於哪些利益相關者的利益？
什麼角色在什麼時候操作或者維護系統？
業務系統實現方法是怎樣的？
整個業務系統是如何依靠系統而運轉的？
為了回答這些問題，需要仔細閱讀需求分析文檔中的業務模型建立、問題域及其解決構
思、產品模型的構思等等前期文檔，站在系統架構的角度，全面清晰的建立業務模型，包括
組織圖關係、業務功能、商務程序、商務資訊互動方法、業務地理分布、商務規則和約束
條件。這個階段的主要活動如下：
建立產品範圍、目的、終端使用者、業務背景等重要的初始資訊。
建立完整的業務和系統的術語字典，確保項目相關人員理解上保持一致。
建立宏觀層面業務的總體概念，明確總體流程、業務功能的邊界、互動與協作方式，
建立系統的概念性模型。
匯總業務總的組織圖與協作職能關係。
分析業務的組成節點，以及節點間互動、協同與資訊的依賴關係。
分析業務節點的事件、訊息，以及由此引發的狀態轉換關係。
匯總業務啟動並執行基本資料模型，以便於跟蹤資訊的流動與格式轉換。分析業務資料
的關聯關係。
理解問題域以及系統需要解決的問題。
分析業務運作層面的基本商務規則與約束條件。
這個階段的活動非常重要，架構師只有具備了這些相互關聯的業務概念以後，才可能從
這些概念中抽取恰當的架構因素。
二、產品架構概念
在理解業務的基礎上，我們需要進一步思考產品架構的概念，這個階段從活動的層面看
實際上與建立業務架構概念是一樣的，但是思維的重心轉移到如下幾個方面：
新系統投入運行以後，最高層面的業務會怎樣運作？
新系統是如何解決原來工作系統的問題的？
新系統的投運，會對原來的組織圖劃分發生什麼樣的影響？
由於新系統取代了原來的一些業務職能，業務節點的分布會發生怎樣的變化？變化
後的節點間的資訊又是怎樣交換與依賴的？
變化後的業務事件傳遞又會發生怎樣的變化？
新的系統加入以後，哪些商務程序將會發生重大變化？哪些不會發生變化？
業務的狀態轉換關係將會如何隨著新系統地加入而改變？
業務的資料模型將會如何隨著商務程序的變化而變化的？
新系統地加入，將會如何影響新的商務規則和約束？
從這些角度出發，我們會重新構建未來新系統投運以後的商務規則，相應的新規則也需
要建立，這就實現了業務過程的重構。
三、建立穩定的架構基準
在對業務領域與問題域有深刻的理解以後，我們需要繼續研究如下一些問題：
這個複雜系統應該分成多少和哪些子系統？
子系統是如何分布在不同的業務節點或者物理節點上的？
這些分散的子系統將提供哪些介面？這些介面如何進行互動？
各個子系統需要互動哪些資料？
每個單獨的子系統，所需要實現的功能有哪些？
整個系統對各個子系統有哪些功能、效能和品質上的要求？
“基準”這個詞有兩個意義：
這個階段將會對整體架構策略做出重大的設計上的決策。一旦作出了這些決策，後
續開發沒有重大情況不允許變動。
這個階段完成的工作，本身就是架構階段的重要成果，需要廣泛認同、集體遵守以
及具備強制的約束力。
儘管在後期的演變中，這樣的基準實際上還會不斷的精化和最佳化，但最初下功夫構建穩
定的架構基準是十分必要的。這個階段的活動如下：
校正與確認前期所有的業務架構與產品架構的資訊，必要的時候補充相應的資訊。
修訂和增補術語字典，確保所有的相關人員對術語有相同的認知。
把整個系統功能進行拆分，並且分解到不同的運行節點上，構建不同的系統集和子
系統，在全域範圍內劃分介面與互動規則。
匯總系統/子系統介面資訊，便於檢索與瀏覽。
規劃整個系統的通訊鏈路、通訊路徑、通訊網路等傳輸媒介。
把產品架構概念中的業務職能與系統功能相對應，從而確保滿足業務要求。
分析系統/子系統在運行起動態協作需要互動的資訊。
構建和類比整個系統在業務環境下的動態特性，規劃全系統內部狀態變化過程、觸
發的事件及約束條件。
詳細匯總各個子系統間資訊傳遞的過程、內容以及其它輔助資訊。
根據初始的資料模型構建資料物理模型。
匯總品質上對系統的要求，並把這些品質要求細化分解，量化到各個子系統中去。
構建整個系統與子系統的構建和演化計劃，在迭代過程中構建整體專案規劃和初始
的迭代規劃。
按固定時段預測技術的演化，匯總整個系統的應用技術及其演化。
分辨與匯總整個系統在不同階段必須遵循的標準。
把業務約束映射到各個子系統，必要時附加 IT 業務約束。
四、子系統架構的設計與實現
通過上述各主要過程，我們已經實現了一個重要的總體架構基準。所有的子系統設計都
是在這個龐大的架構基準約束下展開，至此，首席架構師逐漸淡出，讓位於子系統架構設計
師。子系統架構設計師的任務是繼續分解、細化、設計各個子系統。在這個階段，將會考慮
更加細節的問題，為後來的構件設計與單元設計作準備，我們需要考慮的問題如下：
規劃給該子系統的功能是否可行？
在整個子系統的範圍內，又能分解成什麼子功能集？
在整個子系統的範圍內，又能把哪些子功能合并到某些構件中去？
這些構件與子功能集是如何通過介面與子系統銜接的？
事實上子系統架構設計本身就是一個完整的系統設計，所區別的是視野集中到子系統的
範圍內，這個階段的活動如下：
校正與確認前期與該子系統相關的業務架構與產品架構的資訊，必要的時候補充相
應的資訊。
增補與本子系統相關的術語字典，確保所有的相關人員對術語有相同的認知。
把整個子系統功能進行拆分，並且分解到不同的構件節點上，構建不同的子功能集，
在子系統範圍內劃分介面與互動規則。
匯總子系統/構件介面資訊，便於檢索與瀏覽。
規劃整個子系統的通訊鏈路、通訊路徑、通訊網路等傳輸媒介。
把產品架構概念中的子業務職能與構件功能相對應，從而確保滿足業務要求。
分析子系統/構件在運行起動態協作需要互動的資訊。
構建和類比整個子系統在業務環境下的動態特性，規划子系統內部狀態變化過程、
觸發的事件及約束條件。
詳細匯總各個構件間資訊傳遞的過程、內容以及其它輔助資訊。
根據初始的資料模型構建子系統相關的更詳細的資料物理模型。
根據品質上對子系統的要求，並把這些品質要求細化分解，量化到各個構件中去。
構建整子系統的構建和演化計劃，在迭代過程中構建子系統專案規劃和更詳細地的
迭代規劃。
按固定時段預測技術的演化，匯總子系統的應用技術及其演化。
分辨與匯總子系統在不同階段必須遵循的標準。
把業務約束映射到各個構件，必要時附加 IT 業務約束。
五、構件與實現單元的設計
進入構件設計階段也就是進入了詳細設計階段。這個階段主要的工作就是介面與功能設
計。在迭代模型下，這個階段很大程度上是在迭代過程中完成的，由某個設計人員帶領全體
Team Dev進行分析和設計。
在這個過程中，我們應該考慮在小粒度架構中如何使產品需求變更不至於對產品品質造
成影響，還需要考慮業務概念性模型與產品功能塊有相應的追溯和回溯關係。這些問題，我們
將會在後面用適當的篇幅進行討論。
小結：
大型複雜項目的成功依賴於合理的項目組織，這種組織概念包括人力資源的組織和產品
架構的組織兩個方面。敏捷專案管理為這兩種合理的組織提供了思維基礎，為項目的成功提
供了保證。一個典型的例子是 20 世紀 90 年代加拿大空中交通系統項目（首席架構師：Philippe
Kruchten）。150 個程式員被組織到 6 個月的長周期迭代中。但是，即使在 6 個月的迭代中，
10～20 人的子系統，仍然把任務分解成一連串 6 個為期一個月的小迭代。正是這個項目的
實踐成功，Philippe Kruchten 才成為 RUP 的首倡者。
敏捷過程的提出直接影響到架構設計的核心思維，正是因為敏捷過程的提出，才有了架
構驅動、彈性架構和骨架系統這些理念。也直接影響到需求分析方法、專案規劃和估計方法
等一系列領域的新思維。甚至推動了業務敏捷以及與之相適應的基於服務的架構的提出。這
些觀念的提出又更加推動了軟體工程學向更高的層次發展。
下面我們將討論幾個專題，但討論的時候希望研究一種思考問題的方法，從而為大家解
決更廣闊的問題提供一個思維的平台。這些專題並不是獨立存在，而是融合在本章所討論的
各個階段之中。再一次強調，方法和技術是會變化的，但優秀的思維方式是永恒的！