關鍵字：面向對象 分布對象
對象抽象是從邏輯級還是物理級出發，與開發前是否進行方法學選擇一樣，也是區分OOSE 與 OOP 的試金石。由于許多工具或語言(如PB、C++、Motif) 都支持OOP，使一些程序級系統開發人員可以很方便地不經過邏輯抽象就直接開發物理對象，在早期階段意識不到從物理層即實例對象出發進行系統開發的禍患，孰不知正是這種隨心所欲的 OOP 不僅無法發揮面向對象方法應有的優越性，而且還會給開發后期帶來大量返工作業。
和以往采用結構化方法一樣，我們在系統設計階段也引入了原型化方法，以便用系統樣品即原型與用戶對話，求得對需求理解的勾通，避免或減少后期返工。大多OOP工具都為開發原型提供便利，問題在于原型與最終產品間的關系，即原型是邏輯對象還是物理對象的樣品。若是后者，那就等同于最終產品。在木已成舟時再讓用戶評審，若發現問題，要么推倒重來，要么強迫用戶削足適履。事實上，我們為設計評審而基于邏輯對象開發的原型，相當部分被用戶否決。但由于尚未進行對象實例即物理級開發，而是使用超類對象原型統一模擬對象事件和操作，所以無論是對象模型、動態模型還是功能模型，修改起來都不困難。
問題3 設計階段是否先設計超類，是否在實例對象設計開始之前完成超類對象的實現?
面向對象方法開發出的軟件具有較強的可重用性，這種重用包括開發項目內部的重用和外部的重用。重用依存于超類設計，沒有超類的對象系統好比“把洗衣機當米缸”，不能物盡其用。超類設計的好與不好，首先看其內部重用率的高低，內部重用率高，必然外部重用率也高。
由于系統開發工期緊、工作量大，而我們的開發隊伍年輕，經驗和人力都不足，內部重用率高的超類開發無疑是我們的救星。它可以減少重復勞動,易于統一規格,對復雜問題統一攻關、統一解決,便于統一維護。
對超類的抽象即實例對象的泛化原則，我們是從下面幾個方面考慮的：
(1)尋找大多數實例對象的共同行為。
例如“打印報表”、“查詢靜態代碼表”、“錄入數據庫表數據”等。
(2)超類的多態性設計要保證使用超類繼承關系可以滿足各子類的操作要求。
例如，繼承同一個“數據錄入”祖先窗口，可以完成不同結構數據庫表的數據錄入。
(3)利于信息的隱蔽性，不會破壞數據的完整性，利于將復雜問題簡單化。
例如，對具有復雜關系、結構及相關存取操作的數據庫表集的維護。如果不使用一個泛化類將數據結構及其相關操作封裝起來，下層程序員要想操作有關庫表就必須對庫表設計有深入的了解，并且確保程序算法設計不得破壞數據的相關一致性，這將大大增加程序設計和測試的難度，要求程序員有較豐富的經驗。而采用這種泛化類 (公用函數、公用存儲過程) 后，程序員所要做的只是發“消息”和取“輸出信息”了。
(4)有利于推行開發規范，統一界面風格。
我們在開發國外軟件中受到的最大磨練是：國外對用戶界面 (報表、屏幕) 一絲不荀的嚴格要求。所有屏幕按鈕的高、寬、起始位置都用精確到小數點后 3 位的 X、Y 座標進行規定。這樣出來的產品使人看上去就有賞心悅目之感。但是如果人人都做界面窗口、按鈕的精細調整，工作量勢必成倍增長。采用屏幕界面模版超類的繼承關系，結合特化處理，問題便可迎刃而解。
顯然，超類的設計和實現必須在程序員普遍進行實例對象開發之前完成。也就是說，OOSE 的上游系統設計人員必須文武 (設計與編程) 雙全，能夠擔負起超類對象的程序實現與測試任務，這與結構化方法的上層系統設計人員基本可以不編程有所不同。同時，超類對象在下游開發過程中必須經常吸收特化過程中的反饋(包括來自用戶的反饋)，進行相應的調整修改。所以OOSE擔任超類對象設計與實現的設計人員很難像結構化方法那樣進入編程階段后就可以稍事輕松，他們往往始終離不開編程現場。
如果設計階段不預先設計和開發出超類對象，在同一項目的多數開發者之間沒有可以共同繼承的祖先對象，甚至在各個開發人員自己的作用范圍內都不使用繼承關系，那么這不僅不是OOSE，就連稱之為OOP都很勉強。
文章來源于領測軟件測試網 http://www.kjueaiud.com/