发信人: 3871()
整理人: leeyg(2001-06-05 22:50:06), 站内信件
|
前言：
本人一直想真正用面向对象的方法分析一个系统，并带着问题学习过几本面
向对象系统分析的书（大多为老外所写），可能是本人太笨，总是看到一半就看
不下去。
大部分的面向对象方法，给我的感觉就如老外的厨房用刀与中国人厨房用刀，
老外有很多种刀，剁肉有剁肉刀，砍骨有砍骨刀，可中国人只有一把刀，干什么
都用它。同样，在面向对象领域，很多方法为解决某一问题（或为精确描述某一
问题）而引进或创造了新的概念，这些新的概念令我很是困惑，总是与实际联系
不起来。我想找一把中国人用的刀，因为最简单的就是最好的。
有幸学习了邵维忠、杨芙清所著《面向对象的系统分析》，该书仅用最基本
的面向对象概念，解决了大部分的问题，因该书的可操作性极强，因此尝试应用
该书的理论编写一个系统。
刚巧父亲的橡胶厂因业务扩大，考虑采用计算机管理，于是，决定用该书的
理论尝试我的第一个面向对象系统分析。
在分析过程中，大多数的问题都可依据该书的理论得到解决，但也有该书中
没有描述到的问题，其中之一，就是怎样将数据库的优势应用在面向对象分析领
域。
在本版各位网友的热情帮助下，经过不断的实践，不断地在理论上提升，我
探索出了一种将数据库系统应用在面向对象分析设计领域的方法，并利用此方法
成功地实现了一个管理系统。
下面我将我的一些体会与想法写出来，请大家指正，由于我想将文章最终整
理成册，大家可以自由转载本文，但在转载时，请注明作者，也请注明出自本论
坛。
本文除本人自定义的概念外，其余概念均引出《面向对象的系统分析》。
一、 理解类与对象实体集合的关系
这一点，是必须在建模时首先要搞清楚的。
类的定义通常是这样的：类是具有相同属性的服务的一组对象的集合，它为
属于该类的全部对象提供了统一的抽象和描述，其内部包括属性和服务两个部分
可见，类仅是个对象属性的描述，它给出了属于该类的全部对象的抽象定义，而
对象则是符合这种定义的实体。
类描述了全部的对象，类不能用来枚举已经实体化的实体集合，这些实体仅
是全部对象的其中一部分，类不是一个系统中已有对象实体的集合。
这里提到已有对象实体，是指在一个系统中，从类实体化出来的有限的实体
集合。
少量的对象实体，可以在程序中实例化。当系统中已有对象实体的数量很多
（但永远不可能是全部）时，怎样管理（增加、修改、删除、查询）这些实体就
是系统必须解决的问题了。
所以，在系统建模时，必须为管理这些已有对象实体而建模。这个模型是用
于增加、修改、删除、查询已有对象实体的，我们且把这个模型叫做实体管理模
型。实体管理模型在面向对象的分析设计中，也是一个类。
而数据的增加、修改、删除、查询功能正是数据库的强项，因此，实体管理
模型对应着数据库。
举例来说，系统中有一“联系人”类，其模型为：
属性：姓名、性别、电话
服务：报价
当系统中需管理的联系人的数量较少时，可实例化出这些数量的对象，分别
对它们赋值，形成有意义的对象。
当系统运行到某一时刻（或预计到某一时刻），系统中将出现大量的联系人
实体时，在系统初始化时，对每个实体实例化并赋值，这样的实现方法显然是不
切实际的。
而“联系人”类并不能描述这些已经实例化的实体，必须为管理这些实体另
行建模。
在日常生活中，我们会将这些联系人记在本子上以实现保存、增加、修改、
查找等功能。同样，在面向对象的系统中，我们也应该建立“联系人通讯录”这
样的一个模型（类），这个类应该是这样的：
属性：联系人
服务：增加、删除、修改、查找、取出。
“联系人通讯录”类与“联系人”类是整体－部份关系，我们可以充分利用
数据库系统提供的各种便利来实现“联系人通讯录”的服务。这个类，往往在建
模时是容易忽略的。
值得指出的是，“联系人通讯录”类中的“取出”服务，是从通讯录中取出
某联系人。在设计上，它应该是一个返回联系人实体的函数。这个函数，是连接
数据库概念与面向对象设计的关键函数之一。
待续....
--
※ 修改:．3871 于 Sep 22 08:33:56 修改本文．[FROM: 202.96.190.124]
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.96.190.124]
|
|