问题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 面向对象设计的好处越到后来越显著，特别是在系统维护和扩充方面。