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