1绘制用例图.ppt

系统分析师UML用例实战》介绍如何通过用例掌握UML。《系统分析师UML用例实战》的案例基于Wesley和Richard两个角色叙述，从两人开始接到一个书店系统的项目，到动手建立用例模型，并且应用用例技术来估算工时，系统记述了UML用例的应用方法。 第1章 绘制用例图 理解需求 什么是需求？ 系统必须提供的能力和必须遵从的条件 需求工作的最根本挑战在于：如何去发现、交流并记住（即记录）什么是真正需要的，并能够清楚地向用户和开发团队的成员讲解 ——这个过程的最大难题是如何使得需求的定义没有二义性 理解需求（续） 需求管理推崇用“一种条理化的方法寻找、记录、组织和跟踪系统不断变化的需求” 影响软件项目的因素 用例到底用在哪？ “用例”先睹为快——用例图 “用例”先睹为快——用例描述 用例建模 基本概念 用例视图是UML中起着支配作用的视图，描述的系统外部可见的行为 基于系统需求的用例视图驱动和约束着后续的开发 用例视图展示的是系统功能的结构化视图，视图定义了参与者和参与者可以参与的用例 用例图 以图解的形式概括了系统中不同参与者和用例，并显示了哪些参与者能够参与哪些用例 参与者用一个像人一样的图标表示 用例用包含有用例名字的椭圆表示 UML允许在用例图中包含更多的结构，来定义用例之间以及参与者之间的各种关系 在实践中不值得花费很多时间细化用例图，额外的关系对后面的开发起不到很大作用 用例图 参与者模型化了用户与系统进行交互时可能充当的角色 用例描述了用户使用系统能够完成一项特定的任务 绘制用例图 确立系统边界 需要的留下，不需要的剁掉 确立系统边界 分内外，向系统内找用例，向系统外找参与者。 找出位于系统外部的事物，画小人 找出系统内部的事物，画椭圆 找参与者 一个用例描述了系统及其用户之间的一类交互 系统通常有不同种类的用户，他们能够执行系统功能的不同子集 用户与系统在进行交互时能够担任的不同角色称为参与者 参与者：代表了与系统交互的事物 定义：是系统外部的一个实体，它以某种方式参与了用例的执行过程。 参与者可以是：人担当的角色、计算机系统、机械或者电子设备； 参与者由他们参与用例时所担当的角色来代表，例如，顾客。 一个参与者并不时指一个特定的人或一个特定的实体 注意： 为什么要定义参与者？ 某个特定参与者初始化某个用例的原因几乎总是为什么需要该用例的主要原因 参与者在环境中的角色和其独一无二的行为及其系统职责会对用例产生重要的影响 为什么不先找用例？ 先找参与者的原因 参与者比用例明显 参与者的个数远比用例的个数少 找到一个参与者，就可以找到一堆用例 参与者是系统外部人物的代表，所以是先找出参与者，才能够从参与者的角度去寻找用例。 先找参与者的原因(续) 关注参与者，就能将注意力集中于如何使用系统而不是如何创建或实现系统。 参与者还决定了系统需求的完整性 如何确定参与者 谁或什么将初始化与系统有关的事件 谁或什么与系统交互将有助于系统对某个事件做出响应 有报告界面吗？ 有系统管理界面吗？ 系统需要与其他遗留系统交互吗？ 是否已定义过该系统的参与者？ 如果系统中发生了一个事件，是否需要通知某个外部实体？系统是否需要与外部实体交互以帮助自己完成任务？ 参与者一定是直接并且主动向系统发出动作并获得反馈的,否则就不是参与者. 案例2：谁是参与者？ 小王到银行开户，向大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折，在这个场景中，谁是参与者？ 小王？ 柜台职员？ 大厅经理？ 案例2（续） 谁对系统有着明确的目标和要求并且主动发出动作？ 系统是为谁服务的？ 案例三:机票预订系统 1. 机票购买者通过登录网站购买机票 ---------机票购买者就是参与者 有趣的问题：哪个参与者启动了用例？ 有时候，一个用例是由一个并不与系统实际进行物理交互的实体的需求所触发。 案例三:机票预订系统(续) 2. 假如机票购买者通过呼叫中心,由人工座席操作订票系统购买机票 --------人工座席是系统参与者 --------机票购买者是呼叫中心的参与者 案例三:机票预订系统(续) 3.如果机票购买者通过呼叫中心的自动语音预订机票而不是通过人工座席呢? 案例三:机票预订系统(续) 4.如果扩大系统边界,让呼叫中心称为机票预订系统的一个子系统,并且夹着机票购买者可以自主选择通过人工座席,自动语音还是网站预订机票呢? 如何区分参与者还是工人呢? 参与者的角色 用例建模 用例视图应该包含一组定义了该系统完整功能的用例，或者至少定义了当前迭代所规定功能的用例 用例视图应该是客户、最终用户、领域专家、测试人员和任何其他涉及系统的人员，不需要详细了解系统结构和实现就容易理解的 关键问题 用例分析的关键是专注于“怎样才能使系统为用户提供可观