點評：這篇文章說的很好，和大家分享一下，可能一些實戰的朋友并不喜歡這種理論的東西，可以不看，這篇文章把軟件體系結構和建筑學類比，形象化了體系結構設計。文章提到算法和數據結構有擴張和取代SA的可能，個人覺得有點欠妥，算法和數據結構畢竟是解決細粒度的問題，而體系結構最初從算法和數據結構脫離出來，形成一抽象的分析層次，就是因為軟件越來越復雜，單憑算法和數據是很難解決問題的。算法數據結構和體系結構應該是屬于不同的層次解決不同的問題罷了。文章也提到了黑盒復用和白盒復用的概念，強調了軟件體系結構設計的意義。不過個人并不同意“軟件體系結構是一個高層次上的抽象，它并不涉及具體的系統結構（比如B/S還是C/S），也不關心具體的實現。”筆者這句話，B/S和C/S 其實是一種設計風格，是軟件體系結構的設計模式，其實模式的目的就是重用。在實際的架構設計中你不僅要可慮體系結構設計風格、框架以及復用構件等等，你也要考慮實現的技術和關鍵點的決策，這些都是需要在開發前期確定的。所以軟件體系結構是高層抽象是不關心實現，但是他要涉及到具體的系統結構。
從建筑角度來看軟件體系結構
在業界，軟件體系結構和建筑學的設計框架可以類比。如果把軟件體系結構類比做建筑學的藍圖，那構件就可以比作一磚一瓦，或者更大概念如：庭院，花園等。
軟件體系結構之所以可以獨立于軟件的數據結構和軟件的算法，是因為業界把軟件的數據結構和算法看做了燒磚的方法，或設計庭院的思想。但沒有擴展到整個軟件系統。一個軟件系統是龐雜的。但是分治之后的東西仍然用到了最基本的軟件算法和數據結構思想。之所以也有些人說SA可以不用，是因為算法和數據結構的擴張有代替現在的SA的可能。
完美的構件是可以進行黑箱復用的。不太完美的復用構件就是白盒復用，要在原來代碼的基礎上做些必要的改動。軟件工程的思想正是體現在軟件流程、軟件模塊和軟件文檔的復用之上。否則也就沒有工程的說法。但是又有人提出軟件體系結構復用的思想。這應該被認為是迄今為止最大粒度的復用。
如果建筑師可以把自己以前的建筑藍圖拿來稍作修改就可以進行多次施工，那么軟件架構師們為什么不能拿過去的系統設計方案稍作修改并實施到新的項目中去？但是很可惜，沒有一個企業的業務流程和另一個企業是完全相同的。所以軟件體系結構的復用起來比建筑藍圖的復用要復雜的多。
軟件體系結構直接決定了軟件系統的運行框架,其優劣不但決定了軟件系統是否可以滿足針對此軟件的功能需求,而且還決定了這些功能需求是否能被合理、高效地實現,即也決定了軟件系統基本的非功能屬性。
[1]、每個用戶的非功能屬性多多少少的有所不同，也就決定著軟件體系結構的復用的復雜性。
軟件體系結構是描述軟件單元(element)、軟件單元的屬性(property)以及這些單元之間關系(relationship)的結構
[2]、這里的軟件單元應該就是構件。
軟件體系結構是構建計算機軟件實踐的基礎，與建筑師設定建筑項目的設計原則和目標，作為繪圖員畫圖的基礎一樣。沒有藍圖就不能構建出雄偉的大廈。沒有好的體系結構也就不能構造出龐大的系統。但是對于小型的系統，體系結構的思想似乎是一種多余。對于大廈，我們應該有建筑藍圖，但是對于建造小茅屋，似乎再畫草圖就是一種多余。軟件體系結構表示了一個軟件系統的高層結構，主要特點有：
◆ 軟件體系結構是一個高層次上的抽象，它并不涉及具體的系統結構（比如B/S還是C/S），也不關心具體的實現。
◆ 軟件體系結構必須支持系統所要求的功能，在設計軟件體系結構的時候，必須考慮系統的動態行為。
◆ 在設計軟件體系結構的時候，必須考慮有現有系統的兼容性、安全性和可靠性。同時還要考慮系統以后的擴展性和伸縮性。所以有時候必須在多個不同方向的目標中進行決策。
[3]、抽象的東西之所以對我們有指導的意義。是因為我們可以運用這個抽象的東西對具體問題做具體分析。法無定法，也就是這個道理。
本博客為學習交流用，凡未注明引用的均為本人作品，轉載請注明出處，如有版權問題請及時通知。由于博客時間倉促，錯誤之處敬請諒解，有任何意見可給我留言，愿共同學習進步。