寫這篇文章的起點出於一次系統設計討論會,A和B因爲意見不統一而爭執不下.非要讓我選擇一種方案而推翻另一種方案,記錄於此.權當對所謂架構的反思.
首先說一些軟件工程方面的理論和指導性的原則,和從我個人職業生涯對軟件工程和設計模式的一些實踐性的理解.雖然有些是理論性的東西,但是具有指導意義.
一: 架構的定義
IEEE標準將架構定義爲”系統的基本組織結構,包括它的組件,組件之間的相互關係,環境,以及設計和演進的指導原則”
紅色字體是我個人認爲的3個關鍵字,每一個關鍵字是一層意思,第一層就是系統是由邏輯上的組件和模塊組成的,是結構化的,靜態的描述.第二層意思就是架構要描述出這些組件和模塊之間的關係,是動態的.第三層就是架構是增量式的,是不斷演進和迭代的結果.
3者之間息息相關,缺一不可,缺少了組件,架構就是不完整的.而缺少了相互關係,架構就是混亂的,缺少了演進和指導原則,一上來就想到大而全,是沒有意義的,不切實際的,這樣的架構是紙上談兵.
二: 軟件工程的一般過程
從立項之後開始,一個完整的軟件工程的生命週期包括:
1: 需求
2: 分析與設計
3: 實現
4: 單元測試 集成測試
5: 部署
6: 項目管理 配置和変更管理
第一個生命週期就是需求,架構就是圍繞需求來設計的,一切不以需求爲目的的架構,都是空談.下面以我們的可信平臺爲例,對系統架構的一部分做一個簡要設計.下面這段話引自孫總郵件回覆
要考慮整體穩定性、性能、擴展性、可控性、可維護性等，也要考慮可信架構的建立，可信架構就是軟件基（動態度量是核心，動態度量包括了程序度量、訪問控制、沙箱等，軟件基還包括平臺支撐機制），是安全體系的基礎。
其實這段話應該把後面的部分放到前面來強調,
簡單來講,需求分爲功能性需求和非功能性需求,從上面的話中可以概括出下面的圖
2.1 功能性需求
從概念將系統分層,可以分爲以下幾個Package
拿程序度量Package來說,度量模型分爲靜態度量和動態度量,靜態度量包括身份認證檢測,代碼特徵檢測,用戶空間行爲檢測.而動態度量又包含內存完整性度量.等等.
注意:上面的圖對模塊的劃分粒度已經是很細了.需求分析應該到第二層就已經結束.
第三層已經涉及到系統設計.而對於系統設計來說,第三層的模塊劃分粒度又相對很粗.要在第三層將模塊更加細化,抽象出更加細小的組件,進而抽象出各個接口,對象,這就是關鍵字一:組件
然後就該進入了詳細設計.就是進行接口和對象一級的抽象設計.剩下就是編碼,測試等等.可以看出,系統就是在不斷的進化和演變當中.這就是關鍵字三之一:演化
2.2 非功能性需求
上面是A的文檔,定義框架既定目標,在這個目標中,我沒有看到任何和當前平臺剛性需求有關的字樣,框架就是主要解決功能性需求同時兼顧非功能性需求.我只能認爲這是一個非功能性需求.是框架的一部分,而不是一個完整的框架.從軟件工程的生命週期的角度來說,沒有從需求開始,出發點就已經錯了.
接下來就是講對象管理,組件管理等等,這樣的一個組件管理模型,我個人認爲應該叫做 類似於COM機制的對象組件管理器.而不是一個框架,這樣的依據是什麼呢?爲什麼要這樣劃分?有它存在的必要性嗎?個人認爲是可有可無的東西.沒有這個組件管理器,對我的系統也沒有影響,我完全可以用另一套很簡單的組件管理器來替代它.因爲它沒有解決任何功能性的剛性需求.這是可以沒有它的理由.沒錯吧?但是它又有他存在的合理性,這就是關鍵字三之二:設計的指導原則.從這個角度來推理,上面的功能性需求到最後詳細設計會產生一堆龐大的對象啊接口啊dll的組件,這麼多的組件對於後續的開發和擴展,都是一個挑戰,這時候就需要一個組件管理器來進行統一的調度管理,這就是這個組件管理器可以存在的合理性的抽象指導原則
從上面分析,直接跳過需求分析而產生的這個對象管理器,是沒有理論指導的.它不是一個框架,而是框架後期詳細設計中的一個組件而已.因爲這個組件可能很複雜,所以也可以稱爲一個框架,組件和框架,本身就是一個很虛的東西,看個人理解了.但是對於平臺來講,這就是一個組件.
後來才用一張圖簡單的帶過了系統的功能性的剛性需求,這樣子是本末倒置.
至於關鍵字二:相互關係,這就是B的設計所包含的東西了.將各個組件之間的相互作用封裝起來,同時提供了組件管理和其它一些的功能,但是裏面也有設計的缺陷.這在之前就已經討論過了.不再細說.
2種架構思想:A是典型的面向對象型的設計思想,一切以接口爲出發點,各個組件之間通過接口調用來實現.由組件管理器實現統一的調度.這種思想的好處是高度的可擴展性,單元測試的簡易性.不過這是面向對象本身就具有的特徵,而不是這個組件管理器所產生的特徵.而這個組件管理器存在的問題就是對象管理的複雜性,以及對象生命週期的管理,一旦組件管理器返回對象產生錯誤,所有的調用都會出問題.這是對A架構的一個考驗.
B是面向消息的設計思想,所有的組件通過消息調用來進行交互.這樣設計的好處是交互的簡易性.缺點是單元測試的繁瑣和不方便,相對於面向對象來講,缺少接口級調用的靈活性.
2種思想,對於一套系統來說,完全不衝突,沒有必須推翻哪一種思想.面向對象和麪向消息的優點和缺點正好對立和互補,完全可以取長補短,合理的存在於平臺中.
下面給出我個人的中立而不是中庸的建議:這在以前的郵件中已經說明過了.再重複一下吧
1: 將A的組件管理器替換掉B現有的組件管理,這樣可能有些難度,但是是可行的.或者B重新實現一套組件管理.
2: 去掉現有的XML文件傳輸載體.採用結構體+聯合體,進行消息傳輸.
3: 將第二步中的XML載體單獨提取出來一個模塊或者一個工程,將代碼膨脹從平臺中轉移到測試工具中,解除不必要的耦合,提高平臺穩定性,供測試人員進行可視化測試.
4: 其它的想起來再說.....
後話 軟件工程是一個龐大無比的東西,上面我們幾個人所做的工作都只是冰山一角,如何在保證產品剛性需求的前提下,設計出可複用的可擴展的架構,是需要依賴軟件工程的理論,結合軟件工程師的智慧和實踐,不斷的迭代出來的.
以上是我這個僞”磚家”根據個人工程實踐經驗和軟件工程理論得出的思想和建議,歡迎交流
推薦的關於軟件工程的讀物:
首先肯定是UML創始人Grady Booch的代表作之一 << Object-Oriented Analysis and Design with Applications >>
然後是4人幫的<< 設計模式：可複用面向對象軟件的基礎 >>
最後是國內的一本 << [大象Thinking.in.UML].ThinkingInUML>>