ch07-面向对象设计概述.ppt

* 例如，系统可能要跟踪客户的信息进行赊销结算，这样客户信息就应该作为对象处理；如果只将商品零售给客户，则作为一个销售商品信息的属性。 * * * * * * * * * * * * * * * * * 通常，分析模型中分析类之间的关系可以在设计模型中帮助细化出设计类之间的关系。 研究顺序图的消息有助于发现类之间的关联。 * * * * * * * * * * * * 职责是对象对其他对象的义务 * * 根据常识知识或经验就可以排除掉一些名词，有一些可以比较直观地识别出应该作为系统处理的对象，而有一些需要经过仔细的分析才能确定是否应该作为系统中的对象处理，另外并不是所有的对象都包含在这些名词中，这些名词只涉及到和业务过程紧密相关的对象。 * * * * * * * * * * * * * * * * * * * * 方法设计 对于复杂的操作，操作的具体实现，要通过方法设计来完成， 方法设计描述的是操作的具体实现，所以与选用的编程语言密切相关。 方法设计包括数据结构设计、算法设计和流程设计。 数据结构应选择程序设计语言可以提供的数据结构。 算法应根据操作拟实现的功能来定， 流程的设计则可用程序流程图或活动图来描述。 活动图描述算法 细化设计类的操作与属性 细化设计类的操作与属性，依靠顺序图是一个有效的方法。根据顺序图中的消息有助于确定类的操作。 设计类之间的关系 为了确定设计类之间的关系，首先应该跟踪对应的分析类之间的关系。 顺序图也描述了设计对象间的相互作用 设计类之间的关系时还要考虑以下细节： 确定关联的方向和多重性。 关系的构造型。 使用关联类。 设置限定。 根据顺序图或协作图确定关联关系 根据顺序图或协作图确定关联关系 描述设计类的状态 并不需要对每个设计类都描述其状态。 如果某个类比较复杂，有多种状态，当接收到一个消息时，要根据所处的状态来选择相应的操作行为，对于这样的类需要描述其状态。 由状态图获取更多属性 状态（属性） 相关属性与取值 现有的/新添的 未验证 status=0 现有的 已验证 status=1 现有的 已提交 status=2 现有的 已批准 status=3 approver不为空 现有的 新添的 已审核 status=4 reviewer不为空 现有的 新添的 已偿付 status=5 transactorID不为空 现有的 新添的 由状态图获取更多操作 转移（属性） 相关操作 现有的/新添的 验证 validate( ) 现有的 提交 change_claim_report_status( ) 现有的 批准 approve( ) 现有的 审核 review( ) 新添的 偿付 payback( ) 新添的 经理驳回 reject( ) 新添的 财务人员驳回 reject( ) 新添的 三、面向对象的关系数据库设计 1.类映射成表的策略 要将单个简单类映射为表，一般按下列步骤进行： 第一，类的名字映射成关系模型的名字； 第二，类的所有属性映射成关系模型的属性； 第三，类的关键词属性映射为关系模型的主键，同时指出关系模型中的外键、列的域以及能否为空值等选项； 第四，把类属性之间的函数依赖添加到F中(F为关系模型的函数依赖集)； 第五，类中任一个对象集映射成关系模型的一个实例(即关系)，对象集中每一个对象映射为此关系中一个元组。 三、面向对象的关系数据库设计 2.关系映射的策略 （1）关联关系的映射 ① 一对一关联映射 将一对一关联映射为关系模型有以下三种算法： 算法l：对于一般的一对一关联，将关联每一端的类映射为一张表，外键可放置在任意一边的表中，具体情况依赖于系统性能等因素。需要注意的是，对于一对一的情况，不需要在两个表中均放置对方的主键，因为这样增加了冗余，也并不会提高性能。 算法2：将两个类合并映射成一个表。如“部门”与“部门主任”构成一对二的关联关系，在实际应用中可将“部门”类与“部门主任”类合并映射到“部门”表中。 算法3：如果一对一关联是“可选的1”(O)对“强制的1”(M)，则外键放置在可选的一端，且该外键不能为空值。 ② 一对多关联映射 将外键放置在“多”的一方。如果“1”方是可选的，则外键可有空值，以表明“多”方的记录可以独立于“1”方存在；如果“1”方是强制性的，则外键一定要非空。如一个“客户”拥有多个“合同”，构成一对多的关联关系，映射成数据库表将外键置于“合同”表中。 ③ 多对多关联映射 实现多对多关系，通常需要建立一个关联表，并把它与关系两端的表建立联系。 三、面向对象的关系数据库设计 （2）聚合关系的映射 将类间的聚合关系映射为关系模型的算法为：整体类与各个部分类分别映射成关系模型，整体类映射的关系模型的属性包含原有的所有属性，但各个