關於軟件體系架構的認識


    聽到構架,我最先想到的是一個軟件系統的輪廓,就像建房子時要先給房子畫一個設計圖,這個房子的外形是什么,同樣我認為軟件系統的構架就是要實現什么樣的功能,它的界面布局是什么,都有哪些功能模塊。在接觸了“軟件體系結構”這門課以后,我知道了構架是軟件系統的一個或多個結構。這些結構是由軟件元素、元素的外部可見屬性以及這些元素之間的關系組成。

    在閱讀了“架構漫談”這系列專欄以后,我知道了軟件構架不僅僅只是軟件系統的構架,它受很多方面的影響,同時也影響了很多方面。“架構漫談”提出架構就是對要解決的問題進行目標系統的界定,對目標系統按某個原則進行切分,並對切分出來的部分設立溝通機制,使得這些部分之間能夠進行有機的聯系成為一個整體,完成目標系統的所有工作。對於架構的解釋,有好幾種回答。每個人都以為自己已經理解了架構的概念,但其實都不是很確切的,只知道是那個意思,至於為什么是就沒有解釋了。

    對於抽象,我本身沒有很多的認識,感覺自己想像不出來的就是抽象,跟主觀看到的不一樣的就是抽象。“架構漫談”將抽象的含義解釋為把不同的概念的相似的部分合並在一起,形成一個新的概念。這使我對抽象有了一個新的理解。

    架構解決的是人的問題,知道了是解決人的問題,就很容易知道有什么問題要解決。這就需要架構師了,一直覺得架構師是一個技術水平很高的職位,他所做的就是設計系統的功能,設計系統的整體樣式。“架構漫談”提出一個只致力於完成自己的工作,已做好自己的工作為主要目標的人是無法成為一個架構師的。要成為架構師,就要超越一個恐懼,這個恐懼就是在按時解決別人的問題成為自己的問題的時候,就會有時間壓力,就會產生一種對時間的恐懼。因為有恐懼存在,我們會采取各種手段,來及時的完成工作,換取報酬。其還提出架構師必須是一個組織的領導人,這是我沒有想到的,我一直以為架構師就是將系統的架構報告給領導有領導來組織人員實施,架構師只要有技術就可以了,其他的不用管。看來架構師不僅有技術的要求,對業務領域也是有要求的。

    代碼也是需要架構的,“架構漫談”將代碼分成的部署單元所承擔的責任分為兩個:表達業務邏輯的代碼和對用戶提供訪問並保存業務邏輯運行結果的代碼。對於第二個責任我不是很明白,感覺是不是用戶界面之類的代碼。

    一直以為軟件架構只是技術的問題,跟業務沒有多大的關系,架構只是解決的軟件設計的問題,現在看來自己的理解有很大的問題,有很多不足的之處。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
  © 2014-2022 ITdaan.com 联系我们: