一．為什么要用軟件體系結構的思想來(lái)開(kāi)發(fā)軟件產(chǎn)品？
?
??軟件從最初的程序到今天的程序加文檔，看起來(lái)并沒(méi)有什么變化。然而今天的軟件要實(shí)現的功能已與昨天不可同日而語(yǔ)，對軟件各方面功能和性能的要求決定了軟件空前的復雜。軟件的開(kāi)發(fā)已不是簡(jiǎn)單的寫(xiě)程序，在軟件開(kāi)發(fā)的整個(gè)生命周期里，從需求分析到設計到編碼到測試到維護，編碼僅占一小部分。軟件開(kāi)發(fā)的側重點(diǎn)從編碼已經(jīng)轉移到需求分析和軟件總體架構設計許多項目都是在回顧時(shí),才發(fā)現問(wèn)題在結構上.因結構的局限性,付出太多的代價(jià).?在體系設計上付出一天努力解決的問(wèn)題,在以后階段可能要多付出幾天到十幾天也不一定能解決。由于當今的軟件產(chǎn)品需求復雜、內容豐富、變更頻繁。很難想像在一個(gè)沒(méi)有規范，沒(méi)有構造思想指導下軟件開(kāi)發(fā)會(huì )取得什么樣的“成果”。
?
二．軟件體系結構在軟件開(kāi)發(fā)過(guò)程中的作用
???????
1.規范軟件開(kāi)發(fā)的基本架構。
????體系結構一般說(shuō)來(lái)與需求是密切相關(guān)的.明確的需求可以制定明確的軟件規格,越明確的規格設計出來(lái)的軟件架構越清晰.需求的變更也是必須要考慮,有明確的變更趨勢也可以更早的在設計中體現出來(lái)。在定制軟件規格的階段,要考慮一個(gè)問(wèn)題,就是一些核心的技術(shù),指的是這個(gè)項目中比較重要的關(guān)鍵的技術(shù),應驗證這些技術(shù)是否可行,如果穩定可靠才能采用,否則只能另尋它路.一些難關(guān)也是要考慮的.這樣制定的規格才能符合實(shí)際.這些工作應作為結構設計上的重要參考.
????今天幾乎所有的軟件開(kāi)發(fā)都不可能從頭做起，需要借鑒前人或組織中其他項目所擁有的經(jīng)驗。一個(gè)良好的軟件體系結構可以給我們很多的幫助和參考。良好的體系結構可以規范軟件開(kāi)發(fā)過(guò)程，少走彎路，事半功倍。
??????
???????2.便于開(kāi)發(fā)人員與用戶(hù)的溝通。
????軟件的高度復雜也決定了軟件開(kāi)發(fā)需要充分的設計，需要研究開(kāi)發(fā)模式，研究體系結構，從宏觀(guān)和更抽象的層次把握軟件的開(kāi)發(fā)，并把這整個(gè)過(guò)程付諸于文檔的形式記錄下來(lái)，在軟件開(kāi)發(fā)人員與系統設計人員、用戶(hù)以及其他有關(guān)人員之間進(jìn)行溝通交流，以達成共同的理解。
????如果有明確的需求和規格,那應該進(jìn)行詳細的結構設計,從用例,到類(lèi)圖,到關(guān)鍵部分的序列圖,活動(dòng)圖等,越細越好.多多的交流,盡量讓更多的人了解項目的需求與現實(shí)環(huán)境,為設計提出建議.結構設計注重體系的靈活性.較多的考慮各種變更的可能性.這是最關(guān)鍵的階段.?但這通常是理想狀態(tài),一般來(lái)說(shuō)客戶(hù)不會(huì )給出太明確的需求。應用軟件體系結構的思想和方法可以比較好的劃分范圍、確定時(shí)間、規劃成本、保證質(zhì)量。
?
?
????3.?模塊化、層次化設計，有利于減少返工，提高效率。
?????整個(gè)項目一般受到多種限制,尤其明顯的是計劃，面對這些問(wèn)題.在設計架構上要注意模塊的劃分,模塊越獨立越好.盡量把有明確需求的應用劃分為獨立的模塊，模塊與模塊之間減少交集，一旦某個(gè)模塊出現問(wèn)題也不至于牽一發(fā)而動(dòng)全身。
?????層次化設計就是一層一層分割，一目了然的處理方式。層次體系結構利用分層的處理方式來(lái)處理復雜的的功能，層次系統由于是上層子系統使用下層子系統的功能，而下層子系統不能夠使用上層子系統的功能，下層每個(gè)程序接口執行當前的一個(gè)簡(jiǎn)單的功能，而上層通過(guò)調用不同的下層子程序，并按不同的順序來(lái)執行這些下層程序，有效的杜絕了不同層次之間不該有的交集，減少了錯誤的發(fā)生，也便于檢錯。
?
????4.?便于系統開(kāi)發(fā)前、后期的籌備與服務(wù)。
?????現在的軟件產(chǎn)品已經(jīng)擺脫了小規模、作坊式的生產(chǎn)方式。對于軟件公司來(lái)說(shuō)，利用體系結構的思想開(kāi)發(fā)產(chǎn)品不僅可以規范流程、節省時(shí)間而且還能留下大量的開(kāi)發(fā)文檔、產(chǎn)品類(lèi)型框架、軟件開(kāi)發(fā)標準流程等資料。為今后的售前咨詢(xún)和售后服務(wù)提供參考和依據。
?
????說(shuō)到軟件體系結構就不能不提及非功能性需求。非功能性需求集中了各種約束，其中“人”的因素至關(guān)重要?？梢哉f(shuō)人是整個(gè)軟件產(chǎn)品計劃中的重中之重。一個(gè)IT項目的成敗固然與良好的體系結構有密接的關(guān)系，但作為體系結構中的一環(huán)，應該投入大量的時(shí)間和精力去了解客戶(hù)真正想要什么樣的產(chǎn)品，開(kāi)發(fā)人員是否充分與客戶(hù)進(jìn)行了有效的溝通，特別是一些隱性需求，其中會(huì )包含許多利益的成份。并非看上去最合理的IT架構就是最符要求的設計。人是一切項目成功的推手也是一切項目失敗的導演，更是一切項目得以為繼的絆腳石。
?
?????作為一個(gè)有著(zhù)17年工作經(jīng)驗的在職人員從來(lái)沒(méi)有參加過(guò)任何項目，實(shí)在是一種莫大的遺憾或者說(shuō)是“悲哀”。但我親眼見(jiàn)識過(guò)我單位的IT項目，并且也在某種程度上是一個(gè)使用者。就我的發(fā)現來(lái)說(shuō)我單位的IT項目完全處于一種“人治”的階段。沒(méi)有從IT項目管理的角度去思考過(guò)問(wèn)題，更談不上用體系結構的思想去構建項目，基本上處于想到哪兒做到哪兒的地步。前期方案的制定、技術(shù)流派的選擇、后期服務(wù)等相關(guān)方面均沒(méi)有考慮。致使不同的功能模塊使用不同的方式去開(kāi)發(fā)，開(kāi)發(fā)小組之間少有交流，導致后期集成困難、錯誤率極高、出錯之后難于排查、開(kāi)發(fā)人員和用戶(hù)相互推諉。人的因素在其中也扮演著(zhù)很重要的作用。就我國目前的軟件開(kāi)發(fā)環(huán)境而言，或許只有摒棄了那些沉積了2000多年的垃圾文化之時(shí)才是軟件行業(yè)雄起之日。
