关键字：面向对象 分布对象
对象抽象是从逻辑级还是物理级出发，与开发前是否进行方法学选择一样，也是区分OOSE 与 OOP 的试金石。由于许多工具或语言(如PB、C++、Motif) 都支持OOP，使一些程序级系统开发人员可以很方便地不经过逻辑抽象就直接开发物理对象，在早期阶段意识不到从物理层即实例对象出发进行系统开发的祸患，孰不知正是这种随心所欲的 OOP 不仅无法发挥面向对象方法应有的优越性，而且还会给开发后期带来大量返工作业。
和以往采用结构化方法一样，我们在系统设计阶段也引入了原型化方法，以便用系统样品即原型与用户对话，求得对需求理解的勾通，避免或减少后期返工。大多OOP工具都为开发原型提供便利，问题在于原型与最终产品间的关系，即原型是逻辑对象还是物理对象的样品。若是后者，那就等同于最终产品。在木已成舟时再让用户评审，若发现问题，要么推倒重来，要么强迫用户削足适履。事实上，我们为设计评审而基于逻辑对象开发的原型，相当部分被用户否决。但由于尚未进行对象实例即物理级开发，而是使用超类对象原型统一模拟对象事件和操作，所以无论是对象模型、动态模型还是功能模型，修改起来都不困难。
问题3 设计阶段是否先设计超类，是否在实例对象设计开始之前完成超类对象的实现?
面向对象方法开发出的软件具有较强的可重用性，这种重用包括开发项目内部的重用和外部的重用。重用依存于超类设计，没有超类的对象系统好比“把洗衣机当米缸”，不能物尽其用。超类设计的好与不好，首先看其内部重用率的高低，内部重用率高，必然外部重用率也高。
由于系统开发工期紧、工作量大，而我们的开发队伍年轻，经验和人力都不足，内部重用率高的超类开发无疑是我们的救星。它可以减少重复劳动,易于统一规格,对复杂问题统一攻关、统一解决,便于统一维护。
对超类的抽象即实例对象的泛化原则，我们是从下面几个方面考虑的：
(1)寻找大多数实例对象的共同行为。
例如“打印报表”、“查询静态代码表”、“录入数据库表数据”等。
(2)超类的多态性设计要保证使用超类继承关系可以满足各子类的操作要求。
例如，继承同一个“数据录入”祖先窗口，可以完成不同结构数据库表的数据录入。
(3)利于信息的隐蔽性，不会破坏数据的完整性，利于将复杂问题简单化。
例如，对具有复杂关系、结构及相关存取操作的数据库表集的维护。如果不使用一个泛化类将数据结构及其相关操作封装起来，下层程序员要想操作有关库表就必须对库表设计有深入的了解，并且确保程序算法设计不得破坏数据的相关一致性，这将大大增加程序设计和测试的难度，要求程序员有较丰富的经验。而采用这种泛化类 (公用函数、公用存储过程) 后，程序员所要做的只是发“消息”和取“输出信息”了。
(4)有利于推行开发规范，统一界面风格。
我们在开发国外软件中受到的最大磨练是：国外对用户界面 (报表、屏幕) 一丝不荀的严格要求。所有屏幕按钮的高、宽、起始位置都用精确到小数点后 3 位的 X、Y 座标进行规定。这样出来的产品使人看上去就有赏心悦目之感。但是如果人人都做界面窗口、按钮的精细调整，工作量势必成倍增长。采用屏幕界面模版超类的继承关系，结合特化处理，问题便可迎刃而解。
显然，超类的设计和实现必须在程序员普遍进行实例对象开发之前完成。也就是说，OOSE 的上游系统设计人员必须文武 (设计与编程) 双全，能够担负起超类对象的程序实现与测试任务，这与结构化方法的上层系统设计人员基本可以不编程有所不同。同时，超类对象在下游开发过程中必须经常吸收特化过程中的反馈(包括来自用户的反馈)，进行相应的调整修改。所以OOSE担任超类对象设计与实现的设计人员很难像结构化方法那样进入编程阶段后就可以稍事轻松，他们往往始终离不开编程现场。
如果设计阶段不预先设计和开发出超类对象，在同一项目的多数开发者之间没有可以共同继承的祖先对象，甚至在各个开发人员自己的作用范围内都不使用继承关系，那么这不仅不是OOSE，就连称之为OOP都很勉强。
文章来源于领测软件测试网 https://www.ltesting.net/