03模型與驅動


13

其中的關鍵核心點是,不同涉眾的關注點的分割。我有我自己的關注點,你有你的關注點,不同的關注點匯聚到一起,而關注點背后代表的是一種人的觀點,這些人就構成了不同的涉眾,然后在不同的涉眾里面,他們之間會有一些各種各樣的關系,這些關系之間是如何交互的,這就構成了一個模型。

其實,模型是用來表示,各個涉眾,各個關注點,以及他們代表的事物之間的關系的。

對一個觀察者來說,他觀察了一個主題,或者一個物體,一個subject,而這個觀察者他觀察這個主題的時候,肯定是想了解清楚這個主題,搞清楚他要觀察的對象是什么,他要解決的問題是什么。作為觀察者,他之所以去觀察,一定會有一個問題來引導他去觀察,或者說,對觀察者來說,他想回答這個問題,所以他才關注這個問題,他的目的就是想得到的答案。

我們可以使用一個模型,來描述這個觀察者的一系列過程,而標識它的這個過程肯定不僅僅只有一個模型,但我們使用的模型,是抽象了主題里面的所有東西的一個模型,這也就是該模型是一個主題的模型,這個時候,才盡可能的表達出真實的意圖,從而能夠把誤差控制在可以接受的范圍之內。

14

然后,這個Model,這個M就是這個模型的觀察者。

我一再強調,所有的模型不可能完全代表事實本身,它一定是和事實有偏差的,甚至是有些誤差的,在這個模型內,描摹真實世界是不可能的,這個數值內任何數據都有誤差,模型的好壞,不在于消除誤差,而在于是否可以滿足在可接受的誤差范圍之內。

其實對于大部分工程過程來說,尤其是對于整個軟件的開發來說,大多數下,都可以歸屬于是模型驅動的軟件開發過程

通過模型驅動的軟件開發過程,然后我們最終獲得設定的戰略設想,然后把這種設想,做成了一個模型。所以說,架構它的思想的表達方式,就是去設計模型,設計出能夠表達我們戰略設想的模型。

然后讓我們通過模型,表達出了人、事、物、規則之間的關系,我們的架構最終導向到模型驅動的架構,然后我們能通過使用模型驅動的架構,來驅動我們的軟件開發過程。

15

當然,就概念上來講,軟件架構,并不僅僅只有模型驅動的架構。

模型驅動的架構,也只是一種架構的風格,風格有多種多樣,選擇不同的架構風格也是要看不同的企業環境,我們之所以選擇模型驅動的架構來描述,這也只是為了更好的表達架構思想而已。

架構的風格是為系統的架構信息提供戰略設想的。

這個設想的第一步就是,先想清楚一下我們的風格是什么,再去選擇哪些架構的風格,甚至是需要你去創造架構的風格,而我們最終選擇了模型驅動的架構風格。我又融入了很多的概念,你可以把它當成一種世界觀一種方法論,我們另外選擇的是,面向對象的一種架構的風格。比如,CS(客戶服務器結構),這都是我們架構的一種風格,你一旦了解清楚了需求(requirements),要做的一件事情就是,來選擇一種風格,來有效的設計你的需求。

怎么選的架構模式,當然不是憑空設想,而是腳踏實在,也不是隨機胡亂的組合,而是政治、經濟和斗爭的結果中間尋求的一種平衡,然后根據這個平衡,再選擇這樣一種架構的風格。

16

高度決定我們的視野,你只能站在這樣的高度上,在充分理解了你的環境以及上下文之間的關系上,然后再去發現,分析,與解決問題。

用我們的話說,我們不同的人,因為層次不同,所看到的世界也是不一樣的,這是因為他的關注點不同造成的。

而架構,在一個軟件項目中,是在最高級別在思考與設計,考慮這一系列問題的。它一定要關注一些很多很多互相關聯的事情,一定要對不同涉眾者的關注點的分割,也就是說,一個總裁的關注點肯定和一個員工的關注點是不一樣的,這里并不是歧視不同的員工,當然總裁也是員工,而是說,人在企業中的身份與分工,必定會導致他們看待問題的角度是不一樣的。

換句話說,我們要通過不同涉眾的角度的不同,來區分與分隔這些關注點。

架構師,在一個項目組里,他是一個team的成員,當然有些項目比較簡單的話,也不需要架構師。當你們項目中有架構師的時候,祝賀你,這說明你們的系統比較先進了。因此,架構師是一個系統的設置。

17

關于系統的質量問題,我們分成兩部分,一個是開發時的質量,一個是運行時的質量,設計模式這個可以解決一個重要的quality,那就是軟件開發的質量。質量本身就包括可擴展性,這可以通過設計模式的方式來很好的表達。

我們簡單的介紹幾個設計模式的原理。

(1)、開閉原則(Open Close Principle)

OCP就是說對擴展開放,對修改關閉。在程序需要進行拓展的時候,不能去修改原有的代碼,實現一個熱插拔的效果。為了使程序的擴展性好,易于維護和升級。想要達到這樣的效果,我們需要使用接口和抽象類,后面的具體設計中我們會提到這點。

(2)、里氏代換原則(Liskov Substitution Principle)

這是面向對象設計的基本原則之一。任何基類可以出現的地方,子類一定可以出現。

LSP是繼承復用的基石,只有當衍生類可以替換掉基類,軟件單位的功能不受到影響時,基類才能真正被復用,而衍生類也能夠在基類的基礎上增加新的行為。LSP是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實現,所以LSP是對實現抽象化的具體步驟的規范。

(3)、依賴倒轉原則(Dependence Inversion Principle)

DIP是開閉原則的基礎,具體內容:針對接口編程,依賴于抽象而不依賴于具體。

(4)、接口隔離原則(Interface Segregation Principle)

ISP使用多個隔離的接口,比使用單個接口要好。還是一個降低類之間的耦合度的意思,從這兒可以看出,設計模式就是一個軟件的設計思想,從大型軟件架構出發,為了升級和維護方便。目標是:降低依賴,降低耦合。

(5)、迪米特法則(最少知道原則)(Demeter Principle)

DP是,一個實體應當盡量少的與其他實體之間發生相互作用,使得系統功能模塊相對獨立。

(6)、合成復用原則(Composite Reuse Principle)

CRP是盡量使用合成/聚合的方式,而不是使用繼承。

這些原理,都是概念的載體,就是怎么樣才能達到我們的可擴展性,例如可以通過某個具體的設計模式來提供一種做法,但前提是,要了解這些設計模式適用的情景,也就是你要搞清楚你想要干什么。

18

我們的架構框架,要解決一個首要的問題,就是誰來使用你的軟件。

你要找出來系統的涉眾。每一個涉眾都有很多,所以要進行分割。分割出來的結果就一個關注點。

一個涉眾,通過不同關注點構成一個集合,不同的集合根據匯總與綜合,根據業務的特點,我們把它做成一個模塊,然后這些不同模塊互相配合,構成了這樣的一個軟件系統。

我們的系統,有不同的涉眾,有不同的關注點,不同的集合,不同的模塊,就相當于每個人都有自己的事業,而涉眾就是一個人對應的關注點。因為每個人的關注點是不一樣的,而不同的涉眾都有他的利益點,或者說都有他自己的看法,因此不同的涉眾,他擁有的關注點就會不同。

我們架構師,就是通過抽象來分析這些關注點,然后給它取了一個名字就叫涉眾。不同的人就需要有不同的涉眾,然后又對應不同的視點,這些不同視點又組成了一個完整的整體。

所以我們必須要定義不同視點,以及視點之間的對應關系,也就是要確定不同的規則、議事,各種人事物,責權利的規則,這都要理解清楚,這我們前進的目標,不然,你也沒法進行工作了。

很多軟件相關專業的學生,在他們的大學課程里,項目管理、需求分析等等都學了,但去公司里工作時發現沒用,這是因為全是書本上的,沒有實踐經驗,完全是理論,這基本等于沒學。因為,在真實的企業里,不但有技術因素,還有經濟因素,當然還有政治斗爭因素,我會告訴你這就是現實,我們不需要解釋為什么這樣。

企業里面,對剛畢業的學生來說,就是個初級新手,你就得接受這樣的環境,要不你就離開,廟小裝不下大神,走人吧。因此,為了模擬出現實的真實性,我們必須弄一個真實的商業系統,把理論和實踐融入到系統的架構過程中,這可以很好的體現出我們的思想路徑。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容