關鍵字：面向對象 分布對象
公路局系統有 100 多個數據庫表，但數據的加工 (變換) 很單純，如果當初選擇結構化方法學，情況會怎么樣?
在問題抽象的最初階段不會有太大差異。由于數據變換少，可以把對象和對象的操作看成一一對應，即最初問題描述的對象模型與功能模型基本一致。以其中計劃管理處子系統為例，對象是計劃管理員、規劃管理員、概預算管理員、統計管理員，功能 (操作) 是計劃、規劃、概預算、統計。
問題存在于下層抽象里。
首先，許多公共超類對象設計與結構化方法相悖，因為它破壞了過程的連續性及系統結構的邏輯層次性，把一些下層模塊及在過程分析中沒有語義的對象，放在系統結構的上層。因此如果采用結構化方法，須將繼承關系改為下層模塊調用關系。但是事實上，祖先對象的一些狀態 (屬性值) 是從主控模塊直接得到指示而確定的;從控制角度說，它的確處于系統的上層地位。如果采用結構化方法，結果將是要么把系統結構變成網絡狀，失去結構化特征，要么放棄這種統一完成重復性勞動的設計方案。
其次，應用對象模型向數據庫概念模式的映射設計也是該系統采用面向對象方法的一個標志。如果使用結構化方法，數據庫模式可能映射客觀世界的數據結構。由于公路、養路單位、管理單位、路況、橋梁、隧道及道路上的綠化情況等各實體間客觀存在著復雜的多重關系，其結果可能定義出一個像蜘蛛網似的關系庫結構，因而大大加重了數據庫前端應用編程和數據庫維護的負擔。
總之，該系統若使用結構化方法，系統結構和數據庫結構都可能成為網狀結構，且互相無關。而目前采用的面向對象方法，系統結構和數據庫結構都是多重繼承結構，相互存在映射關系。顯然前者較后者復雜性高、可維護性差、內部重用難度大、重用率低。
其實，無論是用什么方法學開發軟件，交給用戶的都應該是滿足用戶當前需求的軟件。用戶在短期內不會發現開發者使用先進方法學給他們帶來的益處，倒是開發者本身由于大大減輕了開發負擔而最先受益。但是隨著時間的推移，獲得最大收益的還是用戶，因為軟件的長期質量(包括維護成本低和生存周期長)給用戶帶來的好處才是根本的。
三、方法學是思路不是定律
對于方法學，我們是這樣理解的：
(1)方法學的目的是：使后人分享前人的成功，避開前人的失敗，把注意力集中在尚未開拓領域的創造性勞動上。所以方法學與開發人員的創造性是絕不沖突的。它既不能像法律那樣靠權威來界定是非邊界，也不能像定律那樣通過證明和推理給出普遍結論。如果一定要做比喻的話，它好比人的世界觀。
(2)沒有放之四海而皆準的方法學，任何方法學都有其局限性，所以軟件開發人員大可不必拘泥于某種特定的方法學。
例如，面向對象方法的對象模型圖，這種形式化語言遠不如結構化方法的結構圖和數據流圖簡單明了，倘若把公路局系統全部用對象模型圖表述出來，至少也要幾十頁。由于最上層功能模型與對象模型是一致的，所以我們采用的是結構化方法的系統結構圖。
(3)事實表明，由 OOP 帶動的 OOSE 方法確實比結構化方法更能自然地抽象現實世界，而且一些 OOP 工具確實已相當成熟。相反，結構化方法及開放平臺下的結構化程序開發工具，雖然不能說止步不前，但其近年來的進步是有限的。
(4)根據我們的體會，對實踐 OOSE 有以下一些建議：
1 最好在選定方法學后，對全體開發人員進行一次關于面向對象方法學的培訓。
2 由于有超類對象的提前開發工作，OOSE 的上游設計工作量比結構化方法的上游工作負擔重，時間和人力應該更充足一些。否則到下游開發后再追加或多次修改變更超類對象，容易造成混亂和無效勞動。
3 由于系統越大對象類越多，為了便于內部重用和共享，應該建立電子化的對象數據辭典，以便對對象進行統一歸類管理。
4 應該有嚴格的命名規則，如果可能，應將命名規則集成到數據辭典中。
5 下層開發鋪開后，如果發現應該對某些實例對象泛化成新的超類對象，必須盡快進行新超類追加的設計，變更越快越好。
6 子對象繼承超類對象后，發現超類設計的缺陷是常有的事。開發隊伍內部應有很暢通的反饋渠道，使超類得到及時的修正。子對象切不可輕易將超類對象封殺掉，使系統失去統一控制。遵從系統設計中定義的繼承關系進行實例對象開發應該成為全體開發人員的理念。
7 面向對象設計的好處越到后來越顯
文章來源于領測軟件測試網 http://www.kjueaiud.com/
