OO2分析2-用例图.ppt

* * * * * * * * * * 方法：概念、使用过程指南，表示法工具。用其构造系统框架。 技术：实现方案。 * * * * * * * * * * * * * * * * * * * * * 方法：概念、使用过程指南，表示法工具。用其构造系统框架。 技术：实现方案。 * * * * * * 方法：概念、使用过程指南，表示法工具。用其构造系统框架。 技术：实现方案。 * 资金转帐 扣除费用 不允许透支 也可以使用包含 处理取款单 业务员输入处理取款命令 Include 检查口令 收集客户的取款单上的信息； 加急（扩展点）{如果客户选择了加急} extend 处理加急取款单 …… 捕获用例 1）利用参与者捕获用例 ■??? 每个参与者的主要任务是什么？ ■????为了达到某种目的，它们参加什么活动？该参与者是否将读写系统的任何信息？参与者是否该把系统外部的变化通知系统？参与者是否希望系统把预料之外的变化通知自己？ ■???在交互过程中，它们是怎样使用系统的服务来完成它们的任务以达到目的？ ■?????它们参加了什么在本质上是不同的过程？ ■?????是什么事件引起了与系统进行交互的序列？ 能完成特定功能的每一项活动就是一个用例。这些参与者参与的活动，通常会导出其他用例。 2）从系统功能角度捕获用例 用于本步骤的一些简单的指导如下： （1） 一个用例描述一项功能，这项功能不能过大。例如，把一个企业信息管理系统粗略地分为生产管理、供销管理、财务管理和人事管理等几大方面的功能，就显得粒度太大了，应该再进行细化。 （2）全面地认识和定义每一个用例，要点是以穷举的方式考虑每一个参与者与系统的交互情况，看看每个参与者要求系统提供什么功能，以及参与者的每一项输入信息将要求系统作出什么反映，进行什么处理。 （3）以穷举的方式检查用户对系统的功能需求是否能在各个用例中体现出来。 （4）一个用例应该是一个完整的任务，通常应该在一个相对短的时间段内完成。如果一个用例的各部分被分配在不同的时间段，尤其被不同的参与者执行，最好还是将各部分作为单独的用例对待。 （5）考虑对例外情况的处理。针对用例描述的基本流，要详尽地考虑各种其他的情况 场景 用例 抽象 3）使用场景技术 如果不能顺利地确定一个用例的描述，可尽早使用人们熟知的“角色扮演”技术。 描述用例 用例文档模板 用例名 描述：对该用例的一句或两句的描述。 参与者：参与该用例的参与者。 包含：该用例所包含的用例，以及包含它的用例。 扩展：该用例可以扩展的用例，以及扩展它的用例。 泛化：若该用例的子用例和父用例。 前置条件：启动此用例所必须具备的条件。 细节：该用例的细节。（基本流与可选流） 后置条件：在该用例结束时确保成立的条件。 例外：在该用例的执行的过程中可能引起的例外。 限制：在应用中可能出现的任何限制。 注释：提供可能对该用例是重要的任何附加信息。 * 4 用例图 用例图 用例图展示了用例之间以及用例与参与者之间是怎样相互联系的。用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。 用例图呈现了一些参与者和一些用例，以及它们之间的关系。 在图形上，用例图是一幅由一组参与者、一组用例以及这些元素之间的关系组成的图。这些关系是参与者和用例之间的关联、参与者之间的泛化，以及用例之间的泛化、扩展和包含。 可以选择把一些用例用一个矩形围起来，用来表示系统、子系统或“类”的边界。 用例图可以包含注解和约束。 use case A use case B use case C 用例图 参与者 S 参与者 G 被包含的use case 该用例应优先开发 运输公司 职员 订购货物 获取订单状态 获取目录 取消订单 客户 退货 客户代表 运送货物 发送货物 计算运费 供货商 ？ 对系统的需求建模，要遵循如下策略： 通过识别系统周围的参与者来建立系统的语境。 对于每个参与者，考虑它期望的或需要系统提供的行为。 把上述的行为命名为用例。 分解公共行为，放入新的用例中，以供其他的用例使用；分解异常行为，放入新的用例中，以延伸较为主要的控制流。 在用例图中对这些用例、参与者以及它们的关系进行建模。 用陈述非功能需求的注解或约束来修饰这些用例，可能还要把其中的一些附加到整个系统。 注：有人把不与系统进行内外交互的情况也作为一个用例，如在一个信用卡验证的系统中，把系统内的对信用卡的欺诈检查也作为一个用例*。 * 5 审查 审查 参与者 ■?????????确定系统环境中的所有角色，并都归入了相应的参与者。 ■????????? 每个参与者都至