Refined Architecture階段——細化架構

Refined Architecture階段就是相對於Conceptual Architecture而言，分別對應於「概念級」解決方案和「規約級」解決方案。

Refined Architecture（細化架構）屬於架構設計，不能與Detailed Design（詳細設計）相混淆。架構領域最喜歡將建築設計的多視圖方法與軟件架構設計的多視圖方法作類比。

《方案書》意味着架構師在一個項目中須要進行對已經「明確」的架構進行更進一步的細節架構，即RA階段。前邊說明的「明確」的架構就是《方案書》中所說的方案，這裏引用書中原文的幾句話「方案=項目+需求+架構的總覽，而方案≠架構的所有」，小張沒有將「架構」進行細化，因此他的任務不算完成。

那麼什麼是軟件架構呢？架構對應英文單詞「Architecture」，在英文裏Architecture是個名詞，表示結構。但實際上結構只是架構的產物，如何獲得這個結構呢？是經過架構師的一個個決策獲得的。因此，架構包含了過程和結果，其過程就是項目全部人員共同完成的一部分，而後架構師根據全部的成員完成的任務，以及項目、需求綜合起來造成的一個結果。這就是我所理解的軟件架構。它是一個有機的結合，靠着一個項目的全部人員共同完成的一項結果。

從那本書中，我截下了這個圖

這是RA階段中的細化架構與概念架構的分層及比例，明顯的能夠看出細化架構處於概念架構和開發實現之間，因此項目的實現以前必須進行細化架構，細化架構就是項目的實現階段，讓項目的全部人員將概念轉換成實現的一個重要的步驟。

邏輯架構在書中解釋爲劃分子系統，定義接口等等屬於邏輯架構的工做。

劃分子系統的方法有三個：①分層的細化；②分區的引入；③機制的提取；

這三點老師都在課堂上講到過，詳細的示例在網絡上均可以找到，這裏我找到了一篇關於劃分子系統的博客，貼在了帖子內

https://www.cnblogs.com/riasky/p/3476592.html

 

在使用這種方法後，很想找到一種新的名詞來代替「子系統」，由於不少人提到子系統的時候極可能想的都是前臺界面和後臺邏輯的劃分，而最大尺度上的非功能分割。

關於物理架構、運行架構以及開發架構（轉載於原文連接：https://blog.csdn.net/cui841923894/article/details/84677805）

物理架構
爲何須要物理結構設計
有時候增長硬件未必能解決問題；
軟件實際服務能力不只受到「硬件資源」的制約，也受到「數據短缺」和「數據爭用」的制約。
增長硬件 = 增長計算能力 不等於 軟件的實際服務能力加強
物理結構關注如何能夠知足軟件系統的可靠性、可伸縮性、持續可用性、性能、安全性等方面的要求。

物理架構設計的工做內容
物理架構設計主要的3項任務：
硬件選擇和物理拓撲。
軟件到硬件的映射關係。
方案的優化。

物理架構的設計思惟
從設計結果層面，決策無非圍繞物理節點、網絡、軟件單元、數據單元等內容展開。

運行架構
爲何須要運行架構設計
當系統並不引入任何並行或併發處理，而且也沒有給予SDK、API等基礎軟件進行定製開發，那就不須要設計運行架構設計。
若是系統爲了應對複雜的業務邏輯或者複雜的互操做邏輯（含硬件交互），或者爲了優化關鍵資源使用效率，而必須藉助多條控制流並行或者併發執行時，就須要設計運行架構。

運行架構設計工做內容
運行架構設計可能根據具體狀況不一樣包括下列工做內容:
肯定引入哪些控制流。
肯定每條控制流的任務。
處理相關問題：控制流的建立、銷燬、通訊機制等。
進一步考慮：控制流之間的同步關係，如有資源爭用還要引入加鎖機制。

控制流圖是關鍵。運行架構設計的工做看似多而雜，單其實只要把握「控制流圖」，就可以提綱挈領地開展其餘相關設計。

實現控制流的3種常見手段
最經常使用於實現控制流的3種手段：
進程、線程、中斷服務程序。

開發架構
爲何開發架構是必須的
並行開發所需的「程序單元」、「源碼目錄結構」等概念，是不一樣程序團隊開展具體工做的基礎。
能支持並行的詳細設計。
讓程序經理參與到架構實踐的工做，免去大量的「單純架構交流」的工做量，更讓程序人員有「成就感」。

開發架構設計的工做內容
通常完成：
1.將「邏輯職責」映射爲「程序單元」：
要自主編寫的源程序
可重用的庫、框架
其餘方式（如shell腳本、平臺支持下的配置文件）

2.開發技術選型
開發語言
開發工具

3.「程序單元」間的關係
Project劃分
Project目錄結構
編譯依賴關係

重用測試是關鍵
解決年復一年修復相似問題的問題
從根本上下降維護成本