发信人: hyenachenyao()
整理人: majorsun(2000-03-07 20:19:12), 站内信件
|
几年来我通过国内外一些实用系统的开发实践，对面向对象的软件工程方法进行
了较为深入的学习和探讨，特别是在大连电业局MIS继电管理系统的开发过程中，
借鉴国外软件设计经验，较系统地采用了面向对象软件工程方法，受益匪浅。
一、 是"设计主导"还是"程序主导"
在一个系统开发过程中是只采用 OOP 还是采用了OOSE（面向对象软件工程）方法
，
关键看整个开发过程是"设计主导"还是"程序主导"。
近年来，大量先进程序开发工具进入我国，这对提高软件开发效率无疑具有很大
的作用。然而，它们又往往使程序主导型软件开发人员在"以程序代系统"、"以算
法代设计"的误区里越陷越深。
一般的软件开发人员(包括那些只见程序不见系统的程序员)主观上都认为：软件
开发不应"系统设计主导"而应"程序算法主导"。但是用下面几个问题考察一下，
结果往往相反。
问题1 在进行软件设计和选择软件开发工具之前，是否进行开发模式的选择？
所谓开发模式是指组织软件生产过程的一系列方法、技术和规范。
在开发大连电业局MIS继电管理系统时,在经过大量的分析和讨论,认为采用面向对
像模式进行开发是最好的.
对停留在程序主导级开发的软件开发人员来说，他们选择 OOP 的原因也往往是被
动的。
问题2 对象抽象的出发点是现实世界的问题描述，还是可执行的实例对象？
在现实世界早期抽象阶段，面向对象方法与其他方法区别并不大，都要从现实世
界的问题描述出发，即从用户接口、问题领域的知识和经验出发，构筑现实世界
的问题模型，也就是确定目标系统是"做什么的"。
面向对象的问题分析模型从3个侧面进行描述，即对象模型 (对象的静态结构)、
动态模型(对象相互作用的顺序)和功能模型(数据变换及功能依存关系)。软件工
程的抽象原则、层次原则和分割原则同样适用于面向对象方法，即对象抽象与功
能抽象原则是一样的，也是从高级到低级、从逻辑到物理,逐级细分。每一级抽象
都重复对象建模 (对象识别)→动态建模(事件识别)→功能建模(操作识别)的过程
，直到每一个对象实例在物理(程序编码)上全部实现。
由于许多工具或语言(如PB、C＋＋、Motif) 都支持OOP，使一些程序级系统开发
人员可以很方便地不经过逻辑抽象就直接开发物理对象，在早期阶段意识不到从
物理层即实例对象出发进行系统开发的祸患，孰不知正是这种随心所欲的 OOP 不
仅无法发挥面向对象方法应有的优越性，而且还会给开发后期带来大量返工作业
。
和以往采用结构化方法一样，我们在系统设计阶段也引入了原型化方法(迭代式开
发)，以便用系统样品即原型与用户对话，求得对需求理解的勾通，避免或减少后
期返工。大多OOP工具都为开发原型提供便利，问题在于原型与最终产品间的关系
，即原型是逻辑对象还是物理对象的样品。若是后者，那就等同于最终产品。在
木已成舟时再让用户评审，若发现问题，要么推倒重来，要么强迫用户削足适履
。事实上，我们为设计评审而基于逻辑对象开发的原型，相当部分被用户否决。
但由于尚未进行对象实例即物理级开发，而是使用超类对象原型统一模拟对象事
件和操作，所以无论是对象模型、动态模型还是功能模型，修改起来都不困难。
问题3 设计阶段是否先设计超类，是否在实例对象设计开始之前完成超类对象的
实现？
面向对象方法开发出的软件具有较强的可重用性，这种重用包括开发项目内部的
重用和外部的重用。重用依存于超类设计，超类设计的好与不好，首先看其内部
重用率的高低，内部重用率高，必然外部重用率也高。
对超类的抽象即实例对象的开发设计原则，我们是从下面几个方面考虑的：
（1）寻找大多数实例对象的共同行为。
（2）超类的多态性设计要保证使用超类继承关系可以满足各子类的操作要求
。
例如，继承同一个"数据录入"祖先窗口，可以完成不同结构数据库表的数据录
入。
（3）利于信息的隐蔽性，不会破坏数据的完整性，利于将复杂问题简单化。
显然，超类的设计和实现必须在程序员普遍进行实例对象开发之前完成.如果设计
阶段不预先设计和开发出超类对象，在同一项目的多数开发者之间没有可以共同
继承的祖先对象，甚至在各个开发人员自己的作用范围内都不使用继承关系，那
么这不仅不是OOSE，就连称之为OOP都很勉强。
问题4 如何处理对象模型面向对象关系数据库模式的映射？
数据库设计也称数据库模式，基本上由3个层次的模式构成：从特定DB应用角度来
看待DB设计的外部模式；从组织或企业角度出发进行的DB设计即概念模式；处理
对应特定 DBMS 特征与局限性的DB设计即内部模式。具体而言，内部模式是数据
库的SQL定义，逻辑模式是表集合的逻辑定义，外部模式是从特定应用角度看的局
部DB。外部模式与逻辑模式之间的接口是视图、存储过程或其他驻在服务器端的
DB处理程序。
如果在抽象出的对象模型中，各个应用分别是一个或多个超类对象的子对象，那
么，选择适当细分层次的对象模型将其映射到概念模型，是数据库库表对象设计
的关键。外部模式与概念模式之间的接口越少、越简单越好，这样的程序设计简
单，数据库和程序都易于维护。也就是说，局部化是个重要的设计原则。
二、面向对象方法与结构化方法比较
在问题抽象阶段，结构化方法面向过程，按照数据变换的过程寻找问题的结点，
对问题进行分解。因此，与面向对象方法强调的对象模型不同，描述数据变换的
功能模型是结构化方法的重点。如果问题世界的功能比数据更复杂或者更重要，
那么结构化方法仍然应是首选的开发模式。
由于对过程的理解不同，面向过程的功能细分所分割出的功能模块有时会因人而
异。而面向对象的对象细分，从同一问题领域的对象出发，不同人得出相同结论
的比率较高。
在设计上，结构化开发模式产生自顶向下、结构清晰的系统结构。每个模块有可
能保持较强的独立性，但它往往与数据库结构相独立，功能模块与数据库逻辑模
式间没有映射关系，程序与数据结构很难封装在一起。如果数据结构复杂，模块
独立性很难保证。面向对象方法抽象的系统结构往往并不比结构化方法产生的系
统结构简单，但它能映射到数据库结构中，很容易实现程序与数据结构的封装。
在软件工程基本原则中有一条"形式化原则"，即对问题世界的抽象结论应该以形
式化语言 (图形语言、伪码语言等) 表述出来。结构化方法可以用数据流图、系
统结构图、数据辞典、状态转移图、实体关系图来进行系统逻辑模型的描述；而
面向对象方法可以使用对象模型图、数据辞典、动态模型图、功能模型图。其中
对象模型图近似系统结构图与实体关系图的结合，动态模型图类似状态迁移图，
功能模型图类似数据流图。
例如,在开发继电管理系统中采用结构化开发有以下几个问题:
首先，许多公共超类对象设计与结构化方法相悖，因为它破坏了过程的连续性及
系统结构的逻辑层次性。使得系统结构形成网状结构。
其次，如果使用结构化方法，数据库模式可能映射客观世界的数据结构。由于继
电保护设备与变电设备等多个对象间有着复杂的关联关系，其结果可能定义出一
个像蜘蛛网似的关系库结构，因而大大加重了数据库前端应用编程和数据库维护
的负担。
总之，该系统若使用结构化方法，系统结构和数据库结构都可能成为网状结构，
且互相无关。而目前采用的面向对象方法，系统结构和数据库结构都是多重继承
结构，相互存在映射关系。显然前者较后者复杂性高、可维护性差、内部重用难
度大、重用率低。
总之，实践 OOSE 有以下一些建议：
1 由于有超类对象的提前开发工作，OOSE 的上游设计工作量比结构化方
法的上游工作负担重，时间和人力应该更充足一些。否则到下游开发后再追加或
多次修改变更超类对象，容易造成混乱和无效劳动。
2 由于系统越大对象类越多，为了便于内部重用和共享，应该建立电子
化的对象数据辞典，以便对对象进行统一归类管理。
3 应该有严格的命名规则，如果可能，应将命名规则集成到数据辞典中
。
4 下层开发铺开后，如果发现应该对某些实例对象泛化成新的超类对象
，必须尽快进行新超类追加的设计，变更越快越好。
5 子对象继承超类对象后，发现超类设计的缺陷是常有的事。开发队伍
内部应有很畅通的反馈渠道，使超类得到及时的修正。子对象切不可轻易将超类
对象封杀掉，使系统失去统一控制。遵从系统设计中定义的继承关系进行实例对
象开发应该成为全体开发人员的理念。
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 210.72.252.22]
|
|