設計意圖的傳達是架構可視化關註的重要維度,在技術方案評審過程中不可避免的會出現各種各樣的架構圖或設計圖,這些圖形化表述在設計意圖傳達效果層面表現不一,本文從圖形化的視角為軟體架構圖的評審關註點提供了參考。 ...
作者:京東科技 倪新明
設計意圖的傳達是架構可視化關註的重要維度,在技術方案評審過程中不可避免的會出現各種各樣的架構圖或設計圖,這些圖形化表述在設計意圖傳達效果層面表現不一,本文從圖形化的視角為軟體架構圖的評審關註點提供了參考。
註:關於架構及架構可視化參考文章 《 探尋軟體架構的本質,到底什麼是架構? 》 《 軟體架構可視化及C4模型:架構設計不僅僅是UML 》
1 原則
•明確的主題:架構圖要表達的意圖明確,比如是容器圖、組件圖還是部署圖 •一致的抽象層級:保持一致的抽象層級,不應超過2個以上的層次變化 •粒度合適的範圍:不應試圖在一張圖表達“所有的東西”,每張架構圖聚焦於自身職責邊界的範圍 •清晰的圖例說明:對架構圖顏色、形狀等有明確的圖例,以方便閱讀導航 •圖形顏色不宜太多:過多顏色增加認知成本,建議不超過 4 種 •圖形元素不宜太多:過多圖形元素增加認知成本 •明確的連線關係描述2 評審檢查單
如同上線檢查單和開發檢查單,針對於軟體架構圖的評審制定一套檢查單同樣具有價值。不論架構設計者,還是參與設計評審的開發人員,對於形式各異的 “架構圖” 是提供通用的參考關註點,以便干係人更多、更深入、更高效、更有針對性的獲取架構圖的更多信息。
2.1 通用檢查項
架構圖是否具有標題? 是否能夠理解架構圖的類型是什麼? 是否能夠理解架構圖的範圍是什麼? 架構圖是否有圖例?2.2 元素
架構圖中每一個元素是否有名字? 是否能夠理解架構圖中每個元素的類型? (比如,抽象級別,軟體系統?容器?組件?等等) 是否能夠理解架構圖中的每個元素是做什麼的?簡要描述信息? 是否能夠理解與該元素相關的技術選型(適合標明技術選型的元素) 是否能夠理解架構圖中使用的所有縮寫/簡稱的含義? 是否能夠理解架構圖中元素使用的所有顏色的含義 是否能夠理解架構圖中元素使用的所有形狀的含義 是否能夠理解架構圖中元素使用的所有圖標的含義? 是否能夠理解架構圖中元素使用的所有邊框樣式的含義? (比如,實線 vs 虛線) 是否能夠理解架構圖中使用的所有元素大小的含義? (比如, 小框 vs 大框 )2.3 關聯關係
架構圖中的每條線是否有描述關係含義的信息? 是否能夠理解架構圖中的每個關聯關係(適合標明技術選型的場景)的技術選型是什麼? (比如,進程間的交互的協議) 是否能夠理解架構圖中的關聯關係的簡稱或縮寫? 是否能夠理解架構圖中的連線顏色的含義? 是否能夠理解架構圖中的連線箭頭的含義? 是否能夠理解架構圖中的連線樣式的含義? (比如,實線 vs 虛線)3 結語
本文描述了軟體架構圖的一些評審關註點,其實不只是評審的視角,對於任何一個圖形化的軟體系統架構或設計表訴,如何能夠快速的瞭解其要表達的意圖至關重要,對於設計者而言如何快速傳遞架構設計信息並於干係人達成一致也至關重要。