軟體架構師之特殊視角

　　我們知道，軟體架構的過程是一個抽象的過程。通常的開發人員只是從開發的角度對業務需求進行抽象建模，力求對每一個細節進行把握。由於大多數架構師來自於當初的程式員，因此經常出現對某些細節過分關注而忽視建立整體概念架構。大多數情況下出現這種情況是因為架構師沒有從開發視角轉換到架構視角。

 

　　在軟體開發過程中，軟體架構師處於非常特殊的地位。一方面，軟體架構師需要與使用者溝通，收集整理使用者的需求；另一方面需要從整體上對軟體項目進行架構設計；最後還要保證自己架構設計可行，並且能被開發人員所理解。雖然以上三點都是解決軟體項目這同一個問題，但顯然需要從不同角度出發。這就是對軟體架構師的一個很重要也是很基本的要求——要求架構師能能夠從不同的視角看待同一個問題。

 

　　通常情況下，軟體架構師需要從三個最基本的視角對項目進行抽象：概念視角，規範視角和實現視角。

　　首先是概念視角：這要求架構師能夠從使用者的角度來定義系統，分析需求，建立模型。在這個模型中，一般不會指出每個需求是如何?的，因為使用者不關心具體過程，而是向使用者闡明自己對需求的理解是否符合使用者的預期，是否有誤解，規避風險。

　　概念視角常用的方法是畫使用案例圖或資料流圖(DFD)；

 

　　其次是規範視角：這個視角也可以認為設計視角，這時架構師只關係系統間的介面定義而不關注實現細節。架構師通過該視角系統進行劃分，有整體系統劃分為子系統，模組等，同時定義它們之間介面，而不會去關注每個模組是如何?的，甚至不要關心項目開發使用的平台，如C#還是Java。通常情況下，通過對模組介面的定義和劃分，再附以其他輔助手段，如TDD，可以對系統有一個更深刻的認識，發現首次設計時存在的不合理設計，隱藏的耦合，潛在的需求等，因此這是一個反覆的過程。

　　規範視角實現的方法多種多樣，如用Excel列模組清單(包含模組名，輸入，輸入等)，但是均與平台無關；

 

　　最後是實現視角：我們知道，所有的設計最終都要付諸具體的代碼開發。設計成果往往是UML類圖，如同設計圖紙，這與現實的開發環境通常沒有關係。如果開發人員能力不足，看到設計時一定是一臉茫然，不知所措。並且，如規範視角中所說，在迭代設計過程中，僅有類圖通常很難發現潛在的風險。因此，撰寫能夠體現設計思想的代碼就顯得非常有意義了。這一方面不至於使設計脫離與具體的開發環境，另一方面也可以協助當前和未來的開發人員或維護人員更好的理解設計。

　　實現視角通常是指有用於驗證設計的範例程式碼。

 

　　小結：此篇隨筆是對今天的進階軟體架構師培訓的一點總結，歡迎大家留下寶貴的意見！