关键字：面向对象 分布对象
公路局系统有 100 多个数据库表，但数据的加工 (变换) 很单纯，如果当初选择结构化方法学，情况会怎么样?
在问题抽象的最初阶段不会有太大差异。由于数据变换少，可以把对象和对象的操作看成一一对应，即最初问题描述的对象模型与功能模型基本一致。以其中计划管理处子系统为例，对象是计划管理员、规划管理员、概预算管理员、统计管理员，功能 (操作) 是计划、规划、概预算、统计。
问题存在于下层抽象里。
首先，许多公共超类对象设计与结构化方法相悖，因为它破坏了过程的连续性及系统结构的逻辑层次性，把一些下层模块及在过程分析中没有语义的对象，放在系统结构的上层。因此如果采用结构化方法，须将继承关系改为下层模块调用关系。但是事实上，祖先对象的一些状态 (属性值) 是从主控模块直接得到指示而确定的;从控制角度说，它的确处于系统的上层地位。如果采用结构化方法，结果将是要么把系统结构变成网络状，失去结构化特征，要么放弃这种统一完成重复性劳动的设计方案。
其次，应用对象模型向数据库概念模式的映射设计也是该系统采用面向对象方法的一个标志。如果使用结构化方法，数据库模式可能映射客观世界的数据结构。由于公路、养路单位、管理单位、路况、桥梁、隧道及道路上的绿化情况等各实体间客观存在着复杂的多重关系，其结果可能定义出一个像蜘蛛网似的关系库结构，因而大大加重了数据库前端应用编程和数据库维护的负担。
总之，该系统若使用结构化方法，系统结构和数据库结构都可能成为网状结构，且互相无关。而目前采用的面向对象方法，系统结构和数据库结构都是多重继承结构，相互存在映射关系。显然前者较后者复杂性高、可维护性差、内部重用难度大、重用率低。
其实，无论是用什么方法学开发软件，交给用户的都应该是满足用户当前需求的软件。用户在短期内不会发现开发者使用先进方法学给他们带来的益处，倒是开发者本身由于大大减轻了开发负担而最先受益。但是随着时间的推移，获得最大收益的还是用户，因为软件的长期质量(包括维护成本低和生存周期长)给用户带来的好处才是根本的。
三、方法学是思路不是定律
对于方法学，我们是这样理解的：
(1)方法学的目的是：使后人分享前人的成功，避开前人的失败，把注意力集中在尚未开拓领域的创造性劳动上。所以方法学与开发人员的创造性是绝不冲突的。它既不能像法律那样靠权威来界定是非边界，也不能像定律那样通过证明和推理给出普遍结论。如果一定要做比喻的话，它好比人的世界观。
(2)没有放之四海而皆准的方法学，任何方法学都有其局限性，所以软件开发人员大可不必拘泥于某种特定的方法学。
例如，面向对象方法的对象模型图，这种形式化语言远不如结构化方法的结构图和数据流图简单明了，倘若把公路局系统全部用对象模型图表述出来，至少也要几十页。由于最上层功能模型与对象模型是一致的，所以我们采用的是结构化方法的系统结构图。
(3)事实表明，由 OOP 带动的 OOSE 方法确实比结构化方法更能自然地抽象现实世界，而且一些 OOP 工具确实已相当成熟。相反，结构化方法及开放平台下的结构化程序开发工具，虽然不能说止步不前，但其近年来的进步是有限的。
(4)根据我们的体会，对实践 OOSE 有以下一些建议：
1 最好在选定方法学后，对全体开发人员进行一次关于面向对象方法学的培训。
2 由于有超类对象的提前开发工作，OOSE 的上游设计工作量比结构化方法的上游工作负担重，时间和人力应该更充足一些。否则到下游开发后再追加或多次修改变更超类对象，容易造成混乱和无效劳动。
3 由于系统越大对象类越多，为了便于内部重用和共享，应该建立电子化的对象数据辞典，以便对对象进行统一归类管理。
4 应该有严格的命名规则，如果可能，应将命名规则集成到数据辞典中。
5 下层开发铺开后，如果发现应该对某些实例对象泛化成新的超类对象，必须尽快进行新超类追加的设计，变更越快越好。
6 子对象继承超类对象后，发现超类设计的缺陷是常有的事。开发队伍内部应有很畅通的反馈渠道，使超类得到及时的修正。子对象切不可轻易将超类对象封杀掉，使系统失去统一控制。遵从系统设计中定义的继承关系进行实例对象开发应该成为全体开发人员的理念。
7 面向对象设计的好处越到后来越显
文章来源于领测软件测试网 https://www.ltesting.net/
