《软件需求分析与设计-活动图、状态图和需求细化课件.ppt》由会员分享，可在线阅读，更多相关《软件需求分析与设计-活动图、状态图和需求细化课件.ppt（81页珍藏版）》请在三一办公上搜索。
1、软件需求分析与设计 活动图、状态图和需求细化,2023/3/27,2,软件分析与设计活动图、状态图和需求细化,UML活动图及其建模UML状态机图和建模更多的SSD和契约,2023/3/27,3,UML活动图及其建模,目标通过实例和各种建模应用对UML活动图表示法进行介绍,2023/3/27,4,如何应用活动图,UML活动图提供了丰富的表示法来表示一系列活动，其中包括并行的活动业务建模过程数据流建模 数据流图DFD并发编程和并行算法建模 统一过程的规程之一是业务建模（business Modeling）,其用途是理解和勾通“将要部署系统的组织结构和动态特征”,2023/3/27,5,基本的UML
2、活动图表示法,2023/3/27,6,使用Game-Sarson表示法的经典DFD,2023/3/27,7,使用活动图表示法来表示数据流模型,2023/3/27,8,在另外一个图中展开活动,2023/3/27,9,活动的扩展,2023/3/27,10,信号,2023/3/27,11,活动图建模准则,活动图通常对于涉及众多参与者的非常复杂的业务过程建模具有价值对于简单的业务过程用例文本就够用了在进行业务过程建模时，可以利用靶子（rake）符号和子活动图尽量保持同一张图中所有动作节点的抽象水平,2023/3/27,12,使用活动图对处理销售用例建模,2023/3/27,13,UML状态机图和建模,
3、目标通过例子和各种建模应用，介绍UML状态机图表示法,2023/3/27,14,软件分析与设计-UML状态图和建模,UML状态图（state machine diagram）描述了某个对象的状态和感兴趣的事件以及对象响应该事件的行为状态图显示了对象的生命周期事件，是指一件值得注意的事情的发生状态，是指对象在事件发生之间某种时刻所处的情形转换，是两个状态之间的关系，它表明当某事件发生时，对象从先前的状态转换到后来的状态,2023/3/27,15,电话的状态机图,2023/3/27,16,状态无关和状态依赖对象,如果一个对象对某事件的响应事件相同，则认为此对象对于该事件状态无关对于所有事件，对象的
4、相应总是相同的，则该对象是一个状态无关对象状态依赖对象对事件的响应根据对象的状态或模式而不同准则为具有复杂行为的状态依赖对象建立状态图一般业务系统通常只有少数几个复杂的状态依赖类，因此状态机建模意义不大在过程控制、设备控制、协议处理和通讯等领域有更多的状态依赖对象,2023/3/27,17,对状态依赖对象建模,建模的两者方式对复杂的事件交互对象建模对操作协议和语言规范的合法序列建模复杂的反应式对象软件控制的物理设备事务处理以及相关的业务对象角色转换器协议和合法序列通讯协议UI页面/窗口流和导航UI控制器和会话用例系统操作单个UI窗口的事件处理,2023/3/27,18,转换动作和监护表示法,2
5、023/3/27,19,嵌套状态,2023/3/27,20,使用状态机进行Web页面导航建模,2023/3/27,21,用例操作合法序列的状态机样例,2023/3/27,22,用例关联,目标以文本和图形两种形式，使用包含（include）和扩展（extend）关联将用例联系在一起,2023/3/27,23,用例关联,用例关联具有一些价值，但更重要的工作是编写用例文本用例关联包含关系扩展关系泛化关系,2023/3/27,24,用例类型,具体用例是由发起者发起，完成了参与者所期望的完整行为，它们通常是基本业务过程用例抽象用例永远不能被实例化；它是其他用例的子功能用例基础用例包含其他用例的用例，或者
6、是被其他用例扩展或者泛化的用例附加用例被其他用例包含的用例、或者扩展、泛化其他用例的用例,2023/3/27,25,包含关系,当在两个或多个独立用例中存在重复，而您想避免这种冗余时，可以使用包含关系包含关系的另外一个用途是描述异步事件的处理用户可以在任何时候选择或分之到特定窗口、功能、Web页面或一组步骤用例非常复杂并冗长，将其分解为子单元便于理解,2023/3/27,26,UC1:处理销售,主成功场景：1.顾客到某个POS终端为购买的产品或服务付费7、顾客支付，系统付款扩展：7b.用信用卡支付：包含“处理信用卡支付”用例7c.用支票支付：包含“处理支票支付”用例,2023/3/27,27,U
7、C2:处理租金,扩展：6b.用信用卡支付：包含“处理信用卡支付”用例,2023/3/27,28,UC12:处理信用卡支付,级别：子功能主成功场景：1.客户输入信息卡帐户信息2.系统向外部的支付授权服务系统发送支付授权请求3.系统接收到同意支付的信息，并通知收银员4.扩展：2a.系统与外部系统交互时检测到错误1.系统通知收银员发生错误2.收银员要求客户选择其他支付手段,2023/3/27,29,UC1:FooBars,主成功场景：1.扩展：a*.任何时候，客户都可以选择编辑个人信息：编辑个人信息b*.任何时候，客户都可以选择打印帮助：展现打印帮助2-11.客户取消：取消交易确认,2023/3/2
8、7,30,用例模型中的用例包含关系,2023/3/27,31,扩展关系,扩展当用例文本不好修改时可以通过扩展用例解决再创建扩展或附加用例，并且在其中描述在何处和何种条件下该用例扩展某基础用例的行为,2023/3/27,32,UC1:处理销售,扩展点：2a.VIP客户，步骤1。支付，步骤7主成功场景：1.顾客到某个POS收费口为购买的产品或服务付费。7.顾客付费，系统处理支付,2023/3/27,33,UC1:处理增券支付,触发：客户想使用赠券支付扩展点：处理销售中的支付级别：子功能主成功场景：1.客户将赠券交给收银员2.收银员输入赠券ID,2023/3/27,34,扩展关系,2023/3/27
9、,35,领域模型的精化,目标使用泛化、特化、关联类、时间间隔、组合和包等概念精化领域模型确定在何时表示子类才具有价值,2023/3/27,36,领域模型的精化新概念分类列表,2023/3/27,37,UC1:处理销售,扩展：7b.信用卡支付：1.客户输入信用卡帐户信息2.系统向外部的支付授权系统发送支付授权请求，请求支付批准2a.系统侦测到与外部系统协作失败1.系统向收银员发送错误信号2.收银员要求客户使用其他支付手段3.系统接收到支付批准应答，并通知收银员3a.系统接收到拒绝支付应答：1.系统向收银员通知拒绝应答2.收银员要求客户使用其他支付手段4.系统记录此次信用卡支付的信息，其中包括支付
10、批准信息5.系统显示信用卡支付签名输入机制6.收银员要求客户签名。客户签名。7c.支票支付1.客户填写支票，并且同驾驶证一起交给收银员2.出纳员将驾驶证号码写在支票上，输入这些信息，请求支票支付授权3.产生一个支票支付请求并且将她发送到外部的支票授权服务系统4.接收到支票支付批准应答并通知收银员5.系统记录此次支票支付的信息，包括支付批准信息,2023/3/27,38,泛化特化层次体系,泛化（Generaliza）是在多个概念中识别共性和定义超类（普遍概念）与子类（具体概念）关系的活动,2023/3/27,39,使用独立箭头和共享箭头表示法的类层关系,2023/3/27,40,概念超类和子类定
11、义：Payment类的层次结构,2023/3/27,41,集合关系的Venn图,2023/3/27,42,子类的一致性,100原则：概念超类的定义必须100适用于子类。子类必须100与超类一致，包括属性和关联Is-a规则：子类是一种超类,2023/3/27,43,合法的概念类划分，但在我们的领域有用吗,2023/3/27,44,划分概念子类的动机,子类有额外的有意义的属性子类有额外的有意义的关联子类概念的操作、处理、反映或使用的方式不同于其超类或其他子类，而这些方法是我们所关注的子类概念表示了一个活动体，其行为与超类或者其他子类不同，而这些行为是我们所关注的,2023/3/27,45,子类划分
12、的实例,2023/3/27,46,何时定义概念超类,潜在的概念子类表示的是相似概念的不同变体子类满足100和Is-a规则所有子类都具有相同的属性，可以将其解析出来并在超类中表达所有子类都具有相同的关联，可以将其解析出来并与超类关联,2023/3/27,47,证明Payment子类的合理性,2023/3/27,48,证明AuthorizationService层次结构的合理性,2023/3/27,49,外部服务事务的一个可能的类层次结构,2023/3/27,50,事务类层次结构的另一方案,2023/3/27,51,抽象类概念,如果类C的每个成员也必须是某个子类的成员，则C类被成为抽象概念类在领域
13、模型中使用斜体字表示抽象类的名称，或用abstrator,2023/3/27,52,抽象类表示法,在领域模型中使用斜体字表示抽象类的名称，或用abstrator,2023/3/27,53,对变化的状态建模,不要将概念X的状态建模为X的子类定义状态类层次结构，并将其与类X关联在领域模型中忽略概念的状态，而在状态图中加以反映,2023/3/27,54,关联类：属性的不当使用,在领域模型中，如果C可能同时有多个相同的属性A，则不要将属性A置于C之中，应该将属性A放在另一个类中然后将其与类C关联起来,2023/3/27,55,对merchantID问题建模的首次使用,2023/3/27,56,一个关联
14、类,在领域模型中增加关联类的可能线索有：有某个属性与关联相关关联类的实例具有依赖于关联的生命期两个概念之间有多对多关联，并且存在于关联自身相关的信息,2023/3/27,57,多个关联类,2023/3/27,58,聚合关系和组合关系,在下列情形下，可以考虑组合关系部分的生命期在组成的生命期限之内，部分的创建和删除依赖于整体在物理或者逻辑组装上，整体部分关系很明确组成的某些属性会传递给部分对组成的操作可能传递给部分识别和显示组合关系的好处有利于澄清部分对整体依赖的领域约束有助于使用GRASP创建者模式时识别创建者对整体的复制、拷贝这些操作可能传递给部分,2023/3/27,59,POS应用中的聚
15、合,2023/3/27,60,ProductPrices和时间间隔,需要区别销售发生时的历史价格和当前价格,2023/3/27,61,角色名称,显示的角色名称并不是必需的当对象的角色并不清楚时，使用显示的角色名称是有效的,2023/3/27,62,对人类角色建模的两种方式,2023/3/27,63,导出属性,在UML中，在元素名称的前面加”/”来表示导出元素要避免在图中显示导出元素，因为这些导出元素在没有增加新信息的情况下还会增加复杂性,2023/3/27,64,与多重性相关的导出属性,2023/3/27,65,受限关联,在关联中可能会用到限定词（qualifier）；基于限定词的值可以区分位
16、于关联另一端的对象集合。具有限定词的关联是受限关联,2023/3/27,66,自反关联,概念到自身的关联成为自反关联（reflexive association）,2023/3/27,67,使用包来组织领域模型：一个UML包,2023/3/27,68,在包内被引用的类,2023/3/27,69,包的依赖关系,如果一个包引用了由其他包所拥有的某元素，则存在一个依赖关系,2023/3/27,70,如何划分领域模型,将领域模型划分为包结构时，将满足下属条件的元素放在一起在同一个主题领域，概念或目标密切相关的元素在同一个类层次结构中的关系参与同一个用例的元素由很强的关联性的元素,2023/3/27,71,POS领域概念包,2023/3/27,72,Core包,2023/3/27,73,Payment包,2023/3/27,74,Products包,2023/3/27,75,Sale包,2023/3/27,76,Authorization Transaction包,2023/3/27,77,SSD的公共开始部分,2023/3/27,78,信用卡支付SSD,2023/3/27,79,支票支付SSD,2023/3/27,80,契约CO5:makeCreditPayment,2023/3/27,81,契约CO5:makeCreditPayment,
