统一建模语言精要.pptVIP

用例（Use Case） 用例定义 用例是文本形式的情节描述，用于需求的发现和记录，用例会影响后续的OOA/OOD工作。 什么是场景（情节、动作） 是参与者和系统之间的一系列特定的活动和交互，分为以下两种场影： 主成功场景（主路径）：指该功能正确执行的描述 交替场景（扩展路径）：指该功能非正确执行的描述 用例（Use Case）就是一组相关的成功（主）场景（动作、情节）和失败（交替）场景（动作、情节）的集合。用例代表的是一个完整的功能。动作（action）是系统的一次执行（能够给某个参与者输出结果值）。与参与者通信或进行计算或在系统内工作都可以称作动作。用例应支持多种可能发生的动作。比如，自动售货系统中，当顾客付款之后，系统自动送出顾客想要的饮料，这是一个动作；付款后，若需要的饮料无货则提示可否买其它货物或退款等等，这也是动作。系统中的每种可执行情况就是一个动作，每个动作由许多具体步骤实现。 用例的特征 用例总由参与者初始化 用例所代表的功能必须由参与者激活，而后才能执行。一般情况下，参与者可能并没有意识到初始化了一个用例。换句话说，参与者需要系统完成的功能，其实都是通过用例具体完成的，参与者一定会直接或间接地命令系统执行用例。 用例为参与者提供数据（值） 用例必须为参与者提供实际有用的数据（值），即用例执行完毕后会为参与者返回结果，虽然这个值并不总是需要的，但是能被参与者识别和处理。 用例具有完全性 用例是一个完整的描述。如果一个用例非常复杂，则可以被分解为多个小用例（扩展用例）， 一个小用例可以先执行完毕，但是该小用例执行结束并不能说这个用例执行结束。也就是说，不管用例内部的小用例是如何通信工作的，只有最终产生了返回给参与者的结果值，才能说用例执行完毕。 用例的目的与形式 用例，强调用户的目标和观点，是用户需求的体现 用例编写的形式： 摘要形式：需求分析早期使用，通常用于描述主路径（主成功场景） 非正式形式：需求分析早期使用，可覆盖不同的场景（此时包括了扩展路径） 详述形式：详细编写所有路径（主路径和扩展路径）的所有实现步骤和各种变化 说明：主路径一般较为简单就是成功执行的描述，步骤较少 扩展路径非常重要，有的功能模块会有很多，例如：20多个步骤组成 用例的名称应使用动词开头，因为用例表示的是功能 编写用例的时候尽量使用行业的专业名称，而不是计算机中的专业术语 在用例中不要出现，如：数据库、类等这些计算机专有名词，因为用例文档是我们与用户之间沟通的重要文档，用户有可能不懂计算机，所以要从用户的观点出发，用例文档中应使用用户所在行业的专业名词（名称）。 怎样确定用例的粒度？（用例规模的大小） 用例的粒度可大可小，一般一个系统控制在20个左右，但没有严格规定 用例是系统级的、抽象的描述，不是细化的（考虑的是“做什么what”，而不是“怎样做how”） 对复杂的系统可以划分为若干子系统处理，然后再为子系统分别创建用例 参与者与用例的关系 用例和参与者之间具有关联关系，一般这种关联关系为单向关联，并且箭头一端指向用例，表示参与者使用某一用例，一个参与者可以执行多个用例。 UML图绘制技巧 默认情况下，在绘制关联关系时，所使用的各种线条，都是带有转折点的，不能绘制斜线，如下所示： 选中关联线条，选择“Format”菜单中的“Line Style”，选择：“Toggle” 选择“Toggle”后，拖动关联线上的控制点即可 用例文档的编写 用例图非常简单，它只是用例文档的封面，最重要的还是用例文本的描述，一般用例文档由如下格式组成： 用例编号 用例名称 用例描述 参与者 前置条件：表示这个用例必须满足什么条件，它才能够正常工作 后置条件：表示用例执行完毕后，会产生什么样的结果（即：用例执行后的返回值） 基本路径（主路径，主场景，主动作） 1. XXX 2. XXX …… 扩展路径 2a.XXX 2a1.XXX 2a2.XXX …… 补充说明 ：是对基本路径和扩展路径中未尽事宜作一些说明 注：红色字部分的内容需要详细编写！ 如何编写一个用例 将重点放在基本路径和扩展路径上，从参与者的角度描述参与者与系统之间的交互，参与者向系统提供什么样的数据，系统执行了什么样的动作，产生了什么样的结果。 用例主要反映两方面内容 一个是参与者的动作 一个是系统的响应（即：系统产生的结果） 用例文档示例，参见下方注释 UML关系 UML关系 依赖 依赖(dependency)是两个事物之间的