面向對象軟件工程方法學實踐

領測軟件測試網 兩位研究面向對象軟件工程的美國學者 (Stave Halladay和Michael Wiebel) 曾這樣說：“一般的面向對象編程(OOP)思路不過是一批烏合之眾，把靈機一動、隨機應變的技巧用于他們絞盡腦汁抽象出來的‘對象’而已。即使是最優秀的 OOP 程序員，他們所能對付的極限也莫過于中等規模的開發項目。倘若程序員經驗不足，系統規模又很大，那么采用 OOP 只能把你引入漫無邊際的泥沼之中。”

　　一方面是幾乎沒有一位軟件工程學者認為 OOP 是完美無缺的，另一方面是 OOP 勢如破竹，近乎每一種最新推出的程序開發工具或語言都采用了 OOP 思路；一方面是越來越多的“烏合之眾”在毫無章法、隨心所欲地處理著“對象”，另一方面是經過近 30 年的積累已經擁有了最大多數用戶的結構化軟件方法的日漸萎縮……面對這一現實，研究軟件工程方法學的專家們紛紛指出：“當前擺在軟件開發方法學面前的一個重要課題是：從理論上理解 OOP 具有強大生命力的天然合理性，并完善面向對象軟件工程方法學體系。”

　　一年來我們通過國內外一些實用系統的開發實踐，對面向對象的軟件工程方法進行了較為深入的學習和探討，特別是在北京市公路局計算機系統的一期工程實踐中，借鑒國外軟件設計經驗，較系統地采用了面向對象軟件工程方法，受益匪淺。

一、 是“設計主導”還是“程序主導”
　　在一個系統開發過程中是只采用 OOP 還是采用了OOSE（面向對象軟件工程）方法，關鍵看整個開發過程是“設計主導”還是“程序主導”。

　　近年來，大量先進程序開發工具進入我國，這對提高軟件開發效率無疑具有很大的作用。然而，它們又往往使程序主導型軟件開發人員在“以程序代系統”、“以算法代設計”的誤區里越陷越深。

　　一般的軟件開發人員(包括那些只見程序不見系統的程序員)主觀上都認為：軟件開發不應“系統設計主導”而應“程序算法主導”。但是用下面幾個問題考察一下，結果往往相反。

問題1 在進行軟件設計和選擇軟件開發工具之前，是否進行開發方法學的選擇？

　　所謂方法學是指組織軟件生產過程的一系列方法、技術和規范。方法學是軟件開發者長年失敗和成功經驗的理論性總結，從軟件重用的思路來說，方法學重用的價值遠非某些程序組件重用可比。

　　以北京市公路局系統為例。首先，在系統調查階段我們了解到：這個系統要分期 (遞增式) 開發。由于處于機構改革時期，系統生存期內的用戶需求和系統結構變因很多。這表明目標系統應該具有較強的可維護性，即每期開發成果應在后續工程中具有較高的可重用率。其次，一期工程的工作量相當大(最后成果包括 124 個模塊、72 類報表、119個數據庫表、439 個窗口、912 個數據窗口)，而開發者對公路局業務不了解，多為經驗不足的大學生，理解需求的能力較低。這表明采用的開發方法學必須能最大限度地減少重復勞動，實現開發過程中的成果共享和重用；必須能支持消除需求理解誤差的調整工序，使下游成品階段的設計變更比較容易進行。

　　在開發此系統之前，我們承接了一個國外軟件的下游開發任務。由于它采用了面向對象的軟件設計，使我們深刻認識到國內外軟件開發方法學和技術上的差距，頗受啟發。

　　參照我們承接的國外軟件開發工作量計算方法，即僅下游120個模塊 (含報表) 的編碼和測試為41人月，那么公路局系統從上游設計開始近200個模塊和報表、100多個數據庫表的開發工作量至少也應在120人月以上。由于采用了面向對象的軟件工程方法，盡管開發人員大多經驗不足，但是第一期工程總工時最終仍控制在 80 人月以內，降低成本1/3左右。同時在系統可維護性、重用度及其他功能和性能指標上，均超過了我們以往采用結構化方法開發的系統。

　　對停留在程序主導級開發的軟件開發人員來說，他們選擇 OOP 的原因也往往是被動的。其實，在程序主導開發者的辭典中是找不到“方法學”這一詞的，或者把“方法學”與“程序算法”混為一談。至于把 OOP 看成是 OOSE 的全部就更不足為怪了。

問題2 對象抽象的出發點是現實世界的問題描述，還是可執行的實例對象？

　　在現實世界早期抽象階段，面向對象方法與其他方法區別并不大，都要從現實世界的問題描述出發，即從用戶接口、問題領域的知識和經驗出發，構筑現實世界的問題模型，也就是確定目標系統是“做什么的”。面向對象的問題分析模型從3個側面進行描述，即對象模型 (對象的靜態結構)、動態模型(對象相互作用的順序)和功能模型(數據變換及功能依存關系)。軟件工程的抽象原則、層次原則和分割原則同樣適用于面向對象方法，即對象抽象與功能抽象原則是一樣的，也是從高級到低級、從邏輯到物理，逐級細分。每一級抽象都重復對象建模 (對象識別)→動態建模(事件識別)→功能建模(操作識別)的過程，直到每一個對象實例在物理(程序編碼)上全部實現。

　　對象抽象是從邏輯級還是物理級出發，與開發前是否進行方法學選擇一樣，也是區分OOSE 與 OOP 的試金石。由于許多工具或語言(如PB、C＋＋、Motif) 都支持OOP，使一些程序級系統開發人員可以很方便地不經過邏輯抽象就直接開發物理對象，在早期階段意識不到從物理層即實例對象出發進行系統開發的禍患，孰不知正是這種隨心所欲的 OOP 不僅無法發揮面向對象方法應有的優越性，而且還會給開發后期帶來大量返工作業。

　　和以往采用結構化方法一樣，我們在系統設計階段也引入了原型化方法，以便用系統樣品即原型與用戶對話，求得對需求理解的勾通，避免或減少后期返工。大多OOP工具都為開發原型提供便利，問題在于原型與最終產品間的關系，即原型是邏輯對象還是物理對象的樣品。若是后者，那就等同于最終產品。在木已成舟時再讓用戶評審，若發現問題，要么推倒重來，要么強迫用戶削足適履。事實上，我們為設計評審而基于邏輯對象開發的原型，相當部分被用戶否決。但由于尚未進行對象實例即物理級開發，而是使用超類對象原型統一模擬對象事件和操作，所以無論是對象模型、動態模型還是功能模型，修改起來都不困難。

問題3 設計階段是否先設計超類，是否在實例對象設計開始之前完成超類對象的實現？

　　面向對象方法開發出的軟件具有較強的可重用性，這種重用包括開發項目內部的重用和外部的重用。重用依存于超類設計，沒有超類的對象系統好比“把洗衣機當米缸”，不能物盡其用。超類設計的好與不好，首先看其內部重用率的高低，內部重用率高，必然外部重用率也高。

　　由于系統開發工期緊、工作量大，而我們的開發隊伍年輕，經驗和人力都不足，內部重用率高的超類開發無疑是我們的救星。它可以減少重復勞動,易于統一規格,對復雜問題統一攻關、統一解決,便于統一維護。

　　對超類的抽象即實例對象的泛化原則，我們是從下面幾個方面考慮的：

　�。�1）尋找大多數實例對象的共同行為。

　　　　例如“打印報表”、“查詢靜態代碼表”、“錄入數據庫表數據”等。

　�。�2）超類的多態性設計要保證使用超類繼承關系可以滿足各子類的操作要求。

　　　　例如，繼承同一個“數據錄入”祖先窗口，可以完成不同結構數據庫表的數據錄入。

　�。�3）利于信息的隱蔽性，不會破壞數據的完整性，利于將復雜問題簡單化。

　　　　例如，對具有復雜關系、結構及相關存取操作的數據庫表集的維護。如果不使用一個泛化類將數據結構及其相關操作封裝起來，下層程序員要想操作有關庫表就必須對庫表設計有深入的了解，并且確保程序算法設計不得破壞數據的相關一致性，這將大大增加程序設計和測試的難度，要求程序員有較豐富的經驗。而采用這種泛化類 (公用函數、公用存儲過程) 后，程序員所要做的只是發“消息”和取“輸出信息”了。

　�。�4）有利于推行開發規范，統一界面風格。

　　　　我們在開發國外軟件中受到的最大磨練是：國外對用戶界面 (報表、屏幕) 一絲不荀的嚴格要求。所有屏幕按鈕的高、寬、起始位置都用精確到小數點后 3 位的 X、Y 座標進行規定。這樣出來的產品使人看上去就有賞心悅目之感。但是如果人人都做界面窗口、按鈕的精細調整，工作量勢必成倍增長。采用屏幕界面模版超類的繼承關系，結合特化處理，問題便可迎刃而解。

　　顯然，超類的設計和實現必須在程序員普遍進行實例對象開發之前完成。也就是說，OOSE 的上游系統設計人員必須文武 (設計與編程) 雙全，能夠擔負起超類對象的程序實現與測試任務，這與結構化方法的上層系統設計人員基本可以不編程有所不同。同時，超類對象在下游開發過程中必須經常吸收特化過程中的反饋(包括來自用戶的反饋)，進行相應的調整修改。所以OOSE擔任超類對象設計與實現的設計人員很難像結構化方法那樣進入編程階段后就可以稍事輕松，他們往往始終離不開編程現場。

　　如果設計階段不預先設計和開發出超類對象，在同一項目的多數開發者之間沒有可以共同繼承的祖先對象，甚至在各個開發人員自己的作用范圍內都不使用繼承關系，那么這不僅不是OOSE，就連稱之為OOP都很勉強。

問題4 如何處理對象模型面向對象關系數據庫模式的映射？

　　面向對象的數據庫設計方法可以用于各種數據庫，如層次型、網絡型、關系型，當然也包括面向對象型。OOSE 中的數據庫設計無疑必須采用面向對象的數據庫設計方法。

　　數據庫設計也稱數據庫模式，基本上由3個層次的模式構成：從特定DB應用角度來看待DB設計的外部模式；從組織或企業角度出發進行的DB設計即概念模式；處理對應特定 DBMS 特征與局限性的DB設計即內部模式。具體而言，內部模式是數據庫的SQL定義，邏輯模式是表集合的邏輯定義，外部模式是從特定應用角度看的局部DB。外部模式與邏輯模式之間的接口是視圖、存儲過程或其他駐在服務器端的DB處理程序。

　　如果在抽象出的對象模型中，各個應用分別是一個或多個超類對象的子對象，那么，選擇適當細分層次的對象模型將其映射到概念模型，是數據庫庫表對象設計的關鍵。外部模式與概念模式之間的接口越少、越簡單越好，這樣的程序設計簡單，數據庫和程序都易于維護。也就是說，局部化是個重要的設計原則。

　　OOP多是數據庫的后端處理，是基于既存數據庫的。因此無論是否進行過問題世界的對象建模，以及是否將對象模型合理地映射到數據庫邏輯模式 (面向對象數據庫設計)，OOP 都可以工作。

問題5 編程時是否先調查有無可重用 (繼承) 對象，是否參與下層對象對上層對象、超類對象的反饋？

　　埋頭于自己分擔的程序對結構化方法或許是必須的，但在面向對象方法中擔任程序設計的開發人員，應該先去調查對象數據辭典中有無其他開發人員已經完成、自己稍加特化就可重用的對象。從總體上說，對象的共享、重用應該由上層設計人員統一管理，以便保證對象風格的一致性，避免沖突。但是，對象的獨立性、封裝性和多態性都很便于重用，這是結構化系統所不能比擬的，而重用是軟件開發方法學的最重要思想之一。上層設計人員往往不可能面面俱到，懂得軟件設計理論的開發人員，即使只開發下層程序也應采用最省力、最有效率的編程方法，即大量使用重用對象。

　　在繼承超類對象和重用他人對象時，若發現有設計不合理的地方，應該及時反映給對象開發的承擔者。

　　對上層設計人員來說，一方面應該鼓勵程序實現人員重用既存對象，另一方面應通過開發人員共享對象數據辭典，使個別的對象重用能夠立即反映到整體對象模型中，以保證設計變更時的一致性。

二、面向對象方法與結構化方法比較
　　分析是問題抽象 (做什么)，設計是問題求解 (怎么做)，實現是問題的解 (結果)。任何方法學對客觀世界的抽象和求解過程都是如此。在問題抽象階段，結構化方法面向過程，按照數據變換的過程尋找問題的結點，對問題進行分解。因此，與面向對象方法強調的對象模型不同，描述數據變換的功能模型是結構化方法的重點。如果問題世界的功能比數據更復雜或者更重要，那么結構化方法仍然應是首選的方法學。如果數據結構復雜且變換并不多，那么如以過程主導分析和設計，一旦有系統變更就會給下游開發帶來極大混亂。

　　由于對過程的理解不同，面向過程的功能細分所分割出的功能模塊有時會因人而異。而面向對象的對象細分，從同一問題領域的對象出發，不同人得出相同結論的比率較高。

　　在設計上，結構化方法學產生自頂向下、結構清晰的系統結構。每個模塊有可能保持較強的獨立性，但它往往與數據庫結構相獨立，功能模塊與數據庫邏輯模式間沒有映射關系，程序與數據結構很難封裝在一起。如果數據結構復雜，模塊獨立性很難保證。面向對象方法抽象的系統結構往往并不比結構化方法產生的系統結構簡單，但它能映射到數據庫結構中，很容易實現程序與數據結構的封裝。

　　在軟件工程基本原則中有一條“形式化原則”，即對問題世界的抽象結論應該以形式化語言 (圖形語言、偽碼語言等) 表述出來。結構化方法可以用數據流圖、系統結構圖、數據辭典、狀態轉移圖、實體關系圖來進行系統邏輯模型的描述；而面向對象方法可以使用對象模型圖、數據辭典、動態模型圖、功能模型圖。其中對象模型圖近似系統結構圖與實體關系圖的結合，動態模型圖類似狀態遷移圖，功能模型圖類似數據流圖。

　　公路局系統有 100 多個數據庫表，但數據的加工 (變換) 很單純，如果當初選擇結構化方法學，情況會怎么樣？

　　在問題抽象的最初階段不會有太大差異。由于數據變換少，可以把對象和對象的操作看成一一對應，即最初問題描述的對象模型與功能模型基本一致。以其中計劃管理處子系統為例，對象是計劃管理員、規劃管理員、概預算管理員、統計管理員，功能 (操作) 是計劃、規劃、概預算、統計。

　　問題存在于下層抽象里。

　　首先，許多公共超類對象設計與結構化方法相悖，因為它破壞了過程的連續性及系統結構的邏輯層次性，把一些下層模塊及在過程分析中沒有語義的對象，放在系統結構的上層。因此如果采用結構化方法，須將繼承關系改為下層模塊調用關系。但是事實上，祖先對象的一些狀態 (屬性值) 是從主控模塊直接得到指示而確定的；從控制角度說，它的確處于系統的上層地位。如果采用結構化方法，結果將是要么把系統結構變成網絡狀，失去結構化特征，要么放棄這種統一完成重復性勞動的設計方案。

　　其次，應用對象模型向數據庫概念模式的映射設計也是該系統采用面向對象方法的一個標志。如果使用結構化方法，數據庫模式可能映射客觀世界的數據結構。由于公路、養路單位、管理單位、路況、橋梁、隧道及道路上的綠化情況等各實體間客觀存在著復雜的多重關系，其結果可能定義出一個像蜘蛛網似的關系庫結構，因而大大加重了數據庫前端應用編程和數據庫維護的負擔。

　　總之，該系統若使用結構化方法，系統結構和數據庫結構都可能成為網狀結構，且互相無關。而目前采用的面向對象方法，系統結構和數據庫結構都是多重繼承結構，相互存在映射關系。顯然前者較后者復雜性高、可維護性差、內部重用難度大、重用率低。

　　其實，無論是用什么方法學開發軟件，交給用戶的都應該是滿足用戶當前需求的軟件。用戶在短期內不會發現開發者使用先進方法學給他們帶來的益處，倒是開發者本身由于大大減輕了開發負擔而最先受益。但是隨著時間的推移，獲得最大收益的還是用戶，因為軟件的長期質量（包括維護成本低和生存周期長）給用戶帶來的好處才是根本的。

三、方法學是思路不是定律
　　對于方法學，我們是這樣理解的：

　�。�1）方法學的目的是：使后人分享前人的成功，避開前人的失敗，把注意力集中在尚未開拓領域的創造性勞動上。所以方法學與開發人員的創造性是絕不沖突的。它既不能像法律那樣靠權威來界定是非邊界，也不能像定律那樣通過證明和推理給出普遍結論。如果一定要做比喻的話，它好比人的世界觀。

　�。�2）沒有放之四海而皆準的方法學，任何方法學都有其局限性，所以軟件開發人員大可不必拘泥于某種特定的方法學。

　　例如，面向對象方法的對象模型圖，這種形式化語言遠不如結構化方法的結構圖和數據流圖簡單明了，倘若把公路局系統全部用對象模型圖表述出來，至少也要幾十頁。由于最上層功能模型與對象模型是一致的，所以我們采用的是結構化方法的系統結構圖。

　�。�3）事實表明，由 OOP 帶動的 OOSE 方法確實比結構化方法更能自然地抽象現實世界，而且一些 OOP 工具確實已相當成熟。相反，結構化方法及開放平臺下的結構化程序開發工具，雖然不能說止步不前，但其近年來的進步是有限的。

　�。�4）根據我們的體會，對實踐 OOSE 有以下一些建議：

　　　　1 最好在選定方法學后，對全體開發人員進行一次關于面向對象方法學的培訓。
　　　　2 由于有超類對象的提前開發工作，OOSE 的上游設計工作量比結構化方法的上游工作負擔重，時間和人力應該更充足一些。否則到下游開發后再追加或多次修改變更超類對象，容易造成混亂和無效勞動。
　　　　3 由于系統越大對象類越多，為了便于內部重用和共享，應該建立電子化的對象數據辭典，以便對對象進行統一歸類管理。
　　　　4 應該有嚴格的命名規則，如果可能，應將命名規則集成到數據辭典中。
　　　　5 下層開發鋪開后，如果發現應該對某些實例對象泛化成新的超類對象，必須盡快進行新超類追加的設計，變更越快越好。
　　　　6 子對象繼承超類對象后，發現超類設計的缺陷是常有的事。開發隊伍內部應有很暢通的反饋渠道，使超類得到及時的修正。子對象切不可輕易將超類對象封殺掉，使系統失去統一控制。遵從系統設計中定義的繼承關系進行實例對象開發應該成為全體開發人員的理念。
　　　　7 面向對象設計的好處越到后來越顯著，特別是在系統維護和擴充方面。

延伸閱讀

文章來源于領測軟件測試網 http://www.kjueaiud.com/