面向对象的系统分析设计 | ||||||
| ||||||
关于作者对面向对象的理解,请参见《也谈面向对象》和《再谈面向对象》两文。本文是以上两篇文章的延伸。 图书管理系统 这是作者曾经参与的一个项目。该思想在后来的项目中都得到充分的体现。为了便于说明,例子在原来的基础上作了简化。 1.问题描述 图书管理系统由两大部分组成,即数据存储和操作管理两大部分。数据库包括书籍数据库、读者数据库。管理方面包括借书/还书/查询管理、读者/书籍管理。 2.任务与规则 图书管理系统处理读者的注册与注销,新书入库/旧书出库,书籍的借阅与归还,以及读者信息/书籍信息查询等。 规则是系统在运行过程中,管理各种操作应当遵守的约定。如某读者A,读者类型为教师,该类型对应的规则是:最大借书数目为a,最长借书期限为b等。 3.面向对象的系统分析 经过初步分析,系统的E—R图如下。方框图表示实体,直线表示关系。每个实体都可以看作是系统属性。所谓系统属性,是指系统中可以直观表示出来的组成部分,它是系统的一个划分,跟后面介绍的对象划分有关系又有区别。 如你所见,为了降低对象间的耦合度,“借书”和“还书”只与“书籍管理”进行通信。同时对读者信息的更新操作由“书籍管理”通知“读者管理”进行。
4.对象划分:分而治之 既然是一个复杂对象,我们就不可能直接实现它,而是采取分而治之的思想将大规模问题划分成相对独立的小规模问题,逐个击破,来解决大问题。分治思想在很多领域都有广泛的应用,它是实现问题由复杂向简单转化的一个有效方法。在我们的软件设计领域,很多项目都要涉及都众多方面,而且其间关系也异常复杂。建立适当的模型,使我们的问题更易于理解,易于实现,易于维护,是每个分析设计人员的目标。分治思想是很好的思想,特别是在与面向对象思想结合情况下。在本例中,图书管理系统被划分成以下几个子系统: (1) 借书管理系统; (2) 还书管理系统; (3) 查询系统; (4) 读者管理系统; (5) 书籍管理系统。
(1) 采用消息机制。即一个对象向其协作对象发送消息,通知该对象进行某种操作。例如,它们的一种使用格式可能是这样的: PostMessage(FROM SRC, TO TARGET, MSG CODE, PARAM1,PARAM2...) 在这种情况下,就要求我们定义各种消息,以及对应不同的消息时,各个参数的意义。如,一个借书消息格式可能如下: PostMessage((FROM)借书系统,(TO)书籍管理系统,(MSG CODE)“借书”,(参数1)读者代码(借书证号),(参数2)书籍馆藏号,(参数3)错误信息,RESERVED1,RESERVED2,…) 书籍管理系统在接收到这条消息后,分别向读者管理系统和书籍管理系统发送相应消息。两者都成功,则再向借书系统返回成功信息,否则返回出错信息。 (2) 采用接口。既通过公布对象的接口来向外界提供相应的功能。如,假设书籍管理系统向外界提供了IBookMS接口,那么在借书系统中借书操作的实现看起来应该像这样: IBookMS bms; Result rs=bms.Borrow(读者代码,书籍馆藏号); 当然,在进行借书操作前应先注册借书系统实体,如,可能是这样的形式: RegisterBookMS(IBookMS ibms){ this.bms = ibms; } 接口可有多种类型:单接口,多借口。单接口是指一个对象为向外界发布自己的功能而作的描述;而多接口是指多个协作对象系统同时都需要实现接口,但并不常用。 两种方法各有各的优点。对于前者,源系统可以向目标系统发送任何消息,而不管它能否识别;目标系统只要处理自己感兴趣的消息。这就使得进行增加系统功能等修改时,只需要增加新消息,而不必修改原有消息集。而对于后者,使用简单直观方便,不用去记住不同消息对应的参数含义,不会出现消息丢失使得操作无法完成等的情况。但是在进行系统维护时,可能要修改接口或增加接口,很有可能导致版本控制异常。所以采用哪种方法需要视情况而定,可能选其一,也可能二者兼用。
6.逐步求精 你参与了图书管理系统的分析。现在,主管将其中的一个子系统交给你完成,假设就是书籍管理系统。你清楚地知道这个系统应该向其他系统提供什么功能,也知道除此之外其自己还要实现什么功能。那么,从现在开始,你和你的小组成员开始对分配下来的子系统进行分析设计。 其实对这个系统来说,到这个程度已经非常简单了。我们可以通过几个类实现相应的功能了。如果你的系统还是比较复杂,那么对该系统继续进行3、4、5、6的步骤,直到所有的子系统都比较简单易于实现为止。 7.分布式处理 现在的系统,恐怕很少有针对单机的。在设计计算机通信模块时(假如需要自己实现),要高度封装底层细节。具体我也就不多说什么了。 [总结] 面向对象的系统分析设计,看起来其实也很简单,步骤大概如下: (1) 从项目开始,进行步骤(2)。 (2) 对系统进行分析,如果它在一定的要求下可解决,则停止分析,进行设计;如果它在一定的要求下不可解决,则对它进行划分。 (3) 步骤(2)如果有分析结果,则对其中每一个子对象,进行步骤(2)。 边界条件(也即上面提到的“一定要求”,对象划分的原则): 子对象之间独立性要高,即耦合度尽量达到最低,(理想的情况是达到组件化的程度); 子对象相对其他划分方法,更易于处理(如实现,维护等)。 说得这么简单,在实际的工作中可就没这么简单了。你可能会碰到方方面面的问题;甚至可能会被好多细节问题淹没。有时候看上去一马平川,出现问题时可能山重水复,不能前行半步。说到底,面向对象思想(或是任何其他思想)只能指导我们工作,让我门不至在繁难复杂的问题中迷失方向;它不是万能的,不会因为采用了面向对象的思想进行分析设计,项目就一定会成功(尽管它确实能在一定程度上使问题简化)。 写到这里,作者还想多说几句。任何思想,都是为了解决某一类问题而出现的,本身并无多大的一般性。所以,面对如潮水般涌来的新思想、新技术,不要被吓着,也不要盲目去追求。选择合适的,与你原有的思想、技术进行比较,扬弃,整合,变成自己的思想。好了,你现在了解面向对象思想了吧?可以去看看其他东西了,CMM,UML算老的了,现在比较热的,AGILE,XP,MDA,AOP,都不知道是些什么。 |
posted on
2005-11-04 23:05
nothingnothingnothingnothingnothingnothingnothingnothing
阅读(587)
评论(0)
编辑
收藏
举报