1. 程式人生 > >軟體架構-什麼是軟體架構

軟體架構-什麼是軟體架構

什麼是軟體架構

軟體應用架構是定義結構化解決方案的過程,它滿足所有技術和操作需求,也滿足通用的質量屬性,如效能\安全\可管理。它包含一系列的決定,涉及廣泛的方面,每個決定對質量、效能、可維護性和應用程式的成功都有重要的影響。

程式或者計算系統的軟體架構是系統的結構,它由軟體元素、元素的可見屬性和它們之間的關係組成。架構關心公開的介面部分,元素的具體實現細節不是架構,至少不是架構主要關心的內容。

架構為什麼重要

和其它許多複雜的結構一樣,軟體必須建立在堅實的基礎上。沒有考慮到關鍵場景,沒有設計好對共性問題的處理,或者沒有考慮到關鍵決定的長期影響,會使你的應用程式處於風險中。現代工具和平臺會幫助你簡化構建應用程式,但是不能代替你來設計某個具體場景和需求的應用程式。爛的架構會使應用不穩定、不能滿足現在和將來的商業需求,也很難部署到生產環境中。

系統應該考慮到使用者、IT基礎設施、商業目標。對於這些方面,你應該列出關鍵場景、標識重要的質量屬性以及關鍵的滿意點和不滿意點。如果可能的話,對這些方面設計度量指標。

使用者,業務和系統目標

必須在使用者,業務和系統上做權衡。總的使用者體驗通常也是業務和系統(IT基礎設施)的功能,改變其中任何一個也會影響使用者體驗。改變使用者體驗需求,也會影響業務和系統需求。

架構關注程式內部的主要元素和元件。資料結構、演算法、元素的實現細節是設計需要考慮的。架構和設計也經常會有重疊。

當考慮軟體架構時考慮如下抽象問題:

l  使用者如何使用應用程式?

l  應用如何被部署到生產環境並被管理?

l  應用的重要屬性需求是什麼,如安全、效能、併發、國際化、配置?

l  應用程式是如何被設計得更加靈活和可維護?

l  現在或者部署之後影響到應用程式的架構趨勢?

架構的目標

架構通過use cases尋求構建商業需求和技術需求之間的橋樑,然後找到方法來實現這些use cases。架構的目標是標識影響程式架構的需求。架構必須考慮設計決定的總體影響,必須權衡使用者、商業、系統。

Keep in mind that the architecture should:

l  展示系統的結構,隱藏實現細節

l  領悟所有的用例和場景

l  努力實現不同利益相關者的需求

l  處理功能和質量需求

架構藍圖

理解那些影響架構決定的關鍵力量非常重要,這些力量將影響架構如何做出決定。

考慮如下關鍵趨勢:

l  User empowerment支援user empowerment的設計是靈活的、可配置的,關注於使用者體驗的。設計程式時,考慮一定程度的使用者個性化和選項。允許使用者定義如何與你的程式互動,但是也不要過度使用一些不必要的選項和設定。理解關鍵場景,越簡單越好。使得很容易找到資訊並且使用你的程式。

l  Market maturity充分利用市場成熟產品,如已經存在的平臺和技術。使用模式來解決共性問題。

l  Flexible design靈活設計利用鬆散耦合來提高重用性和可維護性。外掛設計及soa、restful等。

l  Future trends構建架構時,考慮到將來可能影響你設計的趨勢。例如,考慮未來富UI和多媒體,增加網路頻寬等。

架構設計準則

一般來說,設計是會延續的,因為你無法一次性瞭解到所有東西及未來的趨勢。當你瞭解得越多,以及外面需求的變化,你的架構會不斷的演化。在頭腦中樹立這種意識,架構不是一次完成的。

當你建立架構設計時,考慮如下問題:

l  架構的最基本部分是什麼,當系統出現問題時,它們是最大的風險

l  最容易改變的部分是什麼,哪些設計你可以延遲

l  最關鍵的假設是什麼,如何測試它們

l  什麼情況下需要重構你的設計

不要設計過頭了,也不要做你不能確認的假設,保持開放的態度,接受改變。

關鍵架構準則

l  Build to change instead of building to last.考慮到程式是要隨著需求而改變的,設計靈活性以支援這些變化

l  Model to analyze and reduce risk使用設計工具,uml或者其它工具來幫助你捕獲需求並作出架構決定,並且分析它們的影響。但是,不要把model擴充套件為正式的程式,它會壓制你迭代和調整設計的能力。

l  Use models and visualizations as a communication and collaborationtool高效的設計互動,對你做決定,即將對設計做出的變化,對好的架構來說非常重要。使用模型、檢視等與所有利益相關方進行溝通,分享你的設計,能夠對架構帶來很大改善。

l  Identity key engineering decisions標識錯誤最可能發生的區域。如果在第一次就把這些標識清楚,設計將會更加靈活,也會很少因為變化而崩潰。

考慮使用增量和迭代來改善你的架構。測試你的架構時考慮如下方面:

l  當前架構你做出了哪些假設

l  架構滿足的顯式及隱性的需求

l  關鍵風險點

l  如何減輕關鍵風險

l  在基線或者最新架構方案的基礎上,架構如何演進