-系统行为.ppt

系统行为 目的： 你将能将： 定义系统行为 定义用例与执行者 理解如何编写用例文档 使用用例图，展示执行者，用例，及它们之间关系 定义用例的场景（scenario） 什么是系统行为？ 系统行为表达系统的动作与反应 外界可见的、可测试的系统活动 系统行为由用例捕获 用例描述系统，环境，及系统与环境之间的关系 用例建模的主要概念 执行者描述与系统交互的事物 用例为系统执行的一系列动作，它向某个执行者产生可见的结果 什么是用例模型？ 用例模型为系统预期功能（用例）及其环境（执行者）的模型 需求分析、设计，测试中均使用同一个用例模型 用例模型的好处 用例模型 用于与最终用户和领域专家进行交流 Provides buy-in at an early stage of system development 达到对需求的共同理解 用于识别 谁将与系统发生交互，系统应做什么事 系统应有的接口 用于验证 捕获了所有的需求 开发者已理解了这些需求 执行者（Actors） 执行者不是系统的一部分，它代表系统用户可能扮演的角色 执行者可主动地与系统交换信息 执行者可以是信息的被动接受者 执行可代表人，机器，或另一个系统 发现执行者：提问单 谁对某些需求感兴趣？ 使用系统的机构在哪里？ 谁为系统提供此信息？使用此信息？移去此信息？ 谁使用此功能？ 谁支持、维护此系统？ 系统使用了外部资源吗？ 执行者执行用例需要什么？ 一个执行者是否扮演几种不同角色？几个执行者是否扮演同一个角色？ 执行者实例 一个用户可担当几个执行者 执行者与系统边界 用例（Use Cases） 用例模仿执行者与系统之间对话 用例由执行者执行系统中某一功能发动 用例为一个完整、有定义的事件流 所有用例集合起来，构成了使用系统的所有可能的方式 发现用例：提问单 执行者的任务是什么？ 执行者是否将在系统中创建，存储，删除或读信息？ 什么用例将创建，存储，删除或读该信息？ 执行者是否需将突然的外部变动通知系统？ 是否要将系统中某一突发事件通知执行者？ 系统要用正确的行为来支持业务？ 哪些用例将支持与维护系统？ 这些用例是否可履行所有的功能需求？ 用例的信息源 系统规格说明/问题陈述 领域相关的文化 会见领域专家 个人的领域知识 传统系统 用例图（ Use Case Diagram） 用例图通过画出传送用例与执行者间的激发（stimuli）来说明它们之间的交互 用例文档编制 用例文档包括 简述 几行文字说明用例目的 详细的事件流 描述用例启动时出现的主要的备选的事件流 编制的文档读起来象执行者与用例之间的对话 这二个文档应以客户可理解的术语书写 用例的事件流 每个用例 有一条正常的、基本的事务序列 可有几条备选的事务序列 通常有几条异常事务序列处理出错情形 还可有定义好的前置与后置条件 用例的事件流(续) 描述的只是属于本用例的事件，而不是其它用例中发生的事件 避免使用含糊的术语，如“例如”、“等”及“信息” 事件流应描述 用例何时开始与结束，怎样开始与结束 何时用例与执行者交互 执行者与用例交换什么信息 不描述用户接口的细节 基本的事件流 备选的事件流 谁读用例文档 客户——批准系统应做的事 用户——获得系统理解 系统开发者——记录系统的行为 评审者——检查事件流 系统分析员（系统设计员）——提供进行分析与设计的基础 系统测试员——作为测试用例的基础 项目负责人——提供项目计划的输入 技术文书——编写用户手册的基础 课程注册的例子 每学期开始，学生需要一张课程目录单，包含该学期提供的课程表。每一课程的信息应包括诸如教授，系，及先决条件等内容，以有助于学生作出明智的选择。 此新系统允许学生选择下学期的四门课程。此外，为防止学生分配不到主要选课，每个学生要指定二门候选课程。课程最多允许十个学生参加，最少三个学生。如果不到三个学生，则此课程撤消。一旦学生完成注册过程，此注册系统发送信息到学费系统，为学生开出这学期的账单。 课程注册的例子（续） 教授必须能访问联机系统指定他们所讲授的课程，教授还要知道哪些学生已选择了他的课程。 每一学期要有一段时间可让学生们变动他们的课程表，在这段时间里学生们必须能够访问此系统，以增加或取消课程。 Use Case Diagram 简述 -- 注册课程用例 1.1 简述 此用例由学生启动，它为学生提供了创建、删除、修改与/或回顾某一学期课程表的功能。 事件流——注册课程用例 2.1 前置条件 无 2.2 主事件流 此用例从学生键入学生id时开始，系统核对学生的id是否有效（E-1），并提出学生选择当前学期或以后学期（E-2），学生键入所要求的“学期”，系统提示学生选择所需求的活动：创建、回顾、修改、打印、删除、或退出。 如果新选的活动为：