CCTV-J-1-P2-用例设计规范.docVIP

文档编号 CCTV-J01-P2-YLGF 版本 V1.0 中央电视台新台址建设工程 基础应用系统集成和软件开发项目 用例设计规范 同方股份有限公司 北京大新恒太传媒科技发展有限公司 联合体 版本记录 版本 类型 说明 编制人/日期 审核人/日期 批准人/日期 V1.0 初版 新发布 项目管理部 目录 1. 目的 4 2. 适用范围 4 3. 用例建模方法与步骤 4 3.1. 确定用例范围 5 3.2. 确定角色 5 3.3. 确定用例 6 3.4. 定义关系 10 3.4.1. 角色间的关系 10 3.4.2. 角色和用例间的关系 11 3.4.3. 用例间的关系 11 3.5. 区分用例优先级 13 3.6. 详细描述用例 13 3.7. 收集其它方面的需求 13 4. 命名规范 14 5. 用例描述（Document） 14 6. 用例图风格 16 7. 协同工作 16 8. 图形词汇表 17 9. 业务术语词典 18 目的 本文档主要是规范用例设计的步骤与方法。 适用范围 用于“中央电视台新台址建设工程基础应用系统集成和软件开发项目”所有参与需求分析工作的单位及小组。 用例建模方法与步骤 用例是由系统完成的一组动作的描述，它产生对特定参与者有价值的可见结果。 一组动作：这组动作描述了完成的一个功能或者一个产生某个结果的算法过程。当参与者通过向系统提供某种输入来启动该用例时，就激活这些动作。动作是原子的，即要么全部完成要么不做。 系统完成：系统根据给定的输入所完成的工作。 有价值的可见结果：为用户描述没有价值的活动或允许用户做他不可以做的活动的用例不是真正的用例。例如，“按下电灯按钮”至少不是一个好的用例（没有交互，对参与者也没有有价值的结果），但是“按下电灯按钮且系统打开灯”是一个有意义的用例。 好的用例能够为用户描述有价值的活动，以实现需求的目标。我们应该专著于了解系统怎样才能适用于每个用户，找出每个用户的真正需求，避免提出用户根本不需要的多余的业务。 用例描述必须使用用户语言，其中的业务专业术语必须遵循统一的业务术语词典（见第九章）。 用例模型提供了一种系统而且直观的方法来捕获用户需求。使用用例会引导分析设计人员考虑谁是系统的用户以及可以通过用例来完成什么业务或任务，用例模型是系统分析、设计、实现和测试的依据。 系统所有的角色和用例及他们之间的关系组成用例模型。一张用例图描述部分用例模型，显示带有关联关系的用例和角色的集合。同领域或相同子系统的用例图可以组成一个用例包。 确定用例范围 进行一个具体的用例分析之前，先确定该用例的范围或边界是相当重要的，这一点和传统的分析方法一样。例如，在一个商品库存管理的用例图中，不应该出现商品送货的用例。 确定角色 可以从以下的人或外部系统中逐步确定系统的角色： 使用系统的人： 需要借助于系统完成日常工作的人； 维护、管理系统，保证系统正常工作的人； 对系统产生的结果感兴趣的人 系统控制的硬件设备； 系统需要交互的其它系统（计算机系统、应用软件等）； 在一个基本业务（集）已实现的系统中，系统运转的大致过程是：外部角色先初始化用例，然后用例执行其所代表的业务，执行完后用例便给角色返回一些结果，这个结果可能是角色需要的来自系统中的任何东西。 确定用例 角色需要从系统中获得的执行业务活动的目标； 如系统中发生的事件需要通知角色，或角色需要通知系统某件事，这些事件可作为用例； 对一个复杂的信息系统进行用例建模是一个复杂的过程。首先应获取应用领域的职能域，再分析职能域以获得业务过程(业务的一个完整的生命周期)，最后分析业务过程获得子业务过程并将其作为一个用例。也就是说根据业务模型来确定用例。 用例的粒度： 过粗或过细都不好；如果在一个用例中存在多个主路径，则表明该用例的粒度过粗；如果用例中只有一个路径，则表明用例的粒度过细； 注意用例中的动作是原子级的且用例的结果对参与者是有价值的。 考虑街头自动售货机：用户塞入硬币，选择一个货品，售货机吐出货品并找回零钱。 发生了三个动作，但如果只有第一个或前两个，没有第三个的话，对参与者毫无意义。三个动作都做完才更是一个完整的对话，因此应该是一个用例。 用例检查参考： 用例角色（参与者）、规格说明检查指南： 问题 建议 已经找到所有角色了吗？ 检查所有用例 每个角色都在至少一个用例中被涉及吗？ 去掉所有在用例描述中没有提到或者不与任何用例发生通讯联系的角色 是否一个角色是另一个角色的一部分？ 角色合并 有两个角色相对于系统而言扮演了类似的作用吗？ 角色泛化 某个角色是否采用几种完全不同的方式使用系统或者该角色为几种完全不同的用途意图而使用该用