面向对象分析及设计Part 8.ppt

* * CH 27 中级主题 下一个个开发周期的需求 在多个开发周期中,后续开发周期中往往是在前面开发周期中模型的细化和精化。逐渐实现业务的完善。 POS系统的第三个叠代周期的主要任务： 远程访问的问题 POS设备的支持 信用卡支付 持久化对象 预期结果 针对新的ProcessSale ，进一步完善Start Up用况。 持久化对象。 CH28 UML的活动图 不讲 CH 29 状态图和行为建模 状态和状态图 状态 事件 状态转移 其他表示法 状态的嵌套 行为建模 什么时候使用状态建模 状态有关的 行为受到复杂状态的约束的 行为有着复杂的操作顺序要求的 POS系统的状态模型 前一阶段的状态图 引入了信用卡和支票后的状态图 CH 30 用况的关联 POS系统的第二个叠代周期中需要考虑多种支付方式 在第一个周期中Proscess Sale用况中直接描述了支付的过程 在考虑到重用型和模块化的时候，我们可能需要将一个用况分离为多个用况。 例如： 处理销售中的支付过程我们将其分离出来，因为出租也可能用到它。 处理销售包含有支付过程 支付过程有区分为使用不同的货币介质支付 用况的包含关系—实例 处理销售的场景 1.顾客携带商品到POS终端前为购买的商品或服务付费. … 7.顾客支付,系统处理支付. 扩展: 7b.用信用卡支付.包含”处理信用卡支付”用例 7c.用支票支付.包含处理支票支付用例. 用况的包含关系 Process Sale包含3种支付用况的UML表示方式 Handle Check Payment用况是由Process Sale发起的（initiate） 扩展用况 扩展（Extends)是指第2个用况是前一个用况的继续。 例如：会员客户、代金卷的处理 用例的术语 具体用例 由参与者发起的,完成参与者所期待的完整行为 通常来自基本业务过程. 抽象用例 不能被独立实例化的,做为子功能. 基础用例 包含其它用例,或被其它用例扩展的. 附加用例 被包含的,用于扩展的 泛化建模 概念建模的过程 概念模型---作为软件模型的源泉 泛化： 寻求具有普遍意义的概念 形成超类和子类的层次关系 软件模型利用继承实现泛化和特化关系 有效提高代码的可重用 概念模型（发掘新的概念） 新的概念（概念列表）: 物理的或者实在的对象 CreditCard, Check 规格说明、设计或者事物的描述 地点 事务 CashPayment, CreditPayrnent,CheckPayment 事务项目 人的角色 事物的容器 容器中的事物 其他的计算机或者机电设备 CreditAuthorizationService，CheckAuthorizationService 抽象的名词概念 组织 CreditAuthorizationService,CheckAuthorizationService 事件 规则和策略 目录 。。。 概念模型（发掘新的概念） 新的概念（名词短语）: 参见＜UML和模式应用＞P300 信用卡支付请求 信用卡批准应答 这两个概念实际上是信用卡授权服务中的一部分，它作为授权事务处理的的一部分出现，并不是一个独立的概念． 泛化－特化层次 generalization-specialization class hierarchy 超类型：描述更普通的概念 子类型：描述特殊的概念 泛化：在定义的超类和子类的关系中提取共同的活动（属性、方法）。 定义超类和子类 超类中应该包含各个子类中普遍的的内容， amount 支付货币的数量 超类应该是子类的抽象 UML 的斜体表示抽象类 泛化和类型集合 所有子类集合的成员都是它们超类集合的成员 子类型定义的符合 （Conceptual Subclass Definition Conformance） Payment有一个属性amount并且有一个和Sale的关联 意味着所有的子类型都有属性amount并且有一个和Sale的关联． １００%规则：超类定义应该１００％被应用于子类，子类必须１００％符合超类的属性和关联． Is a规则：所有子类集合成员都必须是它的超类集合的成员．即：子类Is a 超类． 定义超类 下述情况下需要定义超类： 可能的子类描述了相似的概念的变体 子类遵循１００％规则和Is a规则 所有子类中具有相同的可被分解并在超类中表示的属性 所有子类中具有相同的可被分解并可涉及到超类的关联 定义子类 下述情况下需要定义子类： 子类有额外的重要的属性 子类有额外的重要的关联 子类概念一不同于超类及其他子类的重要的方式被操作或处理 子类所描述的事物不同于超类和其他子类的行为方式 POS系统的类型层次 支付类型 POS系统的类