軟體架構(software archiecture)也稱之為軟體體繫結構,它是一組有關如下要素的重要
決策:軟體系統的組織,構成系統的結構化元素,介面和它們相互協作的行為的選擇,結構
化元素和行為元素組合成粒度更大的子系統的方式的選擇,以及指導這一組織(元素及其接
口、協作和組合方式)的架構風格的選擇。
軟體架構是對系統整體結構設計的刻劃,一直以來,對於架構的理解有兩個基本概念,
一個稱之為組成,另一個稱之為決策。
組成:架構的組成概念強調“電腦及組件之間的互動”。例如在的初步設計中,“表
示層”和“業務層”是兩個粗粒度的黑盒,當內部也表達了一些粒度比較細的組件
的時候,這兩個黑盒變成了“灰盒”。互動的概念表現在架構描述了它們之間的關
系,例如資料如何讀取、功能如何調用等。
決策:架構決策不但表現了系統組織、元素、子系統的組織風格決策,還包括了非
功能性需求的決策,例如對於可擴充性的決策,對於表示邏輯與商務邏輯變化的隔
離,第三方工具包變化的隔離等,這就使架構有了彈性。
架構的組成 與決策是架構設計的兩個基本概念,這兩個概念並不矛盾,在架構設計中,
往往是同時體現這兩個概念,確保架構滿足產品要求。由這兩個概念出發,我們自然會提出:
軟體架構的核心思維到底是什麼呢?
首先,任何軟體系統都是以滿足需求作為目的,所以,好的架構設計必須以全面深入的
需求分析作為基礎,根據需求來組織合理的產品架構。事實上架構設計是沒有統一的模式的,
任何模式只有針對問題才有意義。作為架構設計來說,必須對需求分析有足夠的理解,這樣
才能有針對性地解決問題,才可能設計出真正優秀的產品來。
其次,一個軟體系統的品質,很大程度上是由架構設計的品質決定的,所以架構師的眼
光一般都專註於品質屬性上,應該根據產品品質屬性的要求提出合理的架構決策。但是很長
時間以來,人們大都把目光關注在流程、方法、結構原理甚至編碼的本身,而不太注意架構
設計最本質的東西,思考的深度也欠深入,結果,很多產品即使設計出來,後期運行中也是
問題百出,特別是發生變更的時候帶來了很大的困難。這就給我們提出了一個問題,架構設
計的思維到底是什嗎?
另一方面,任何架構思想的實現,必須與具體的項目組織相匹配才能發揮作用。因此,
系統架構師應該仔細研究現代專案管理的思想和方法,吃透其中的精髓,根據自己的設計思
想,提出合適的軟體工程策略。反之,一個軟體工程策略,也不可避免的也會影響到架構設
計的特點。因此,軟體架構設計是一個系統工程,它需要系統構架師有很寬的知識面,從需
求分析、架構設計到類設計甚至代碼實現一直到專案管理都需要有透徹的理解,這之間的關
系是你中有我我中有你,是不可能截然分開的。必須說明,軟體系統設計的方法不是一個僵
化的規則,關鍵是在實踐中實事求是的摸索規律,從而找出符合實際達到要求的設計來。