2014年用例建模指南.docVIP

指南：用例 用例 用例实例是系统执行的一系列动作，这些动作将生成特定主角可观测的结果值。一个用例定义一组用例实例。 主题 解释 如何查找用例 用例如何演进 是否详细说明了所有的用例？ 用例的范围 用例如何实现 一个用例具有许多可能的实例 用例实例的并行 名称 简要说明 事件流 - 内容 事件流 - 结构 事件流 - 风格 事件流 - 示例 特殊需求 前置条件和后置条件 扩展点 用例图 解释 以上定义中有几个关键词： 用例实例。以上定义所说的序列实际上是贯穿整个系统的某个特定事件流，即一个实例。可能会有许多事件流，而许多事件流可能非常相似。为了使用例模型便于理解性，应该将相似的事件流组合到一个用例中。确定和说明某个用例实际上就是确定和说明一组相关的事件流。 系统执行。这意味着系统提供用例。主角和系统的某个用例实例进行通信。 可观测的结果值。您可以给一个成功执行的用例赋予一个值。用例应该确保主角可以执行某个具有可确定值的任务。确定用例的正确级别或粒度是非常重要的事情。正确级别是指所实现的用例不是太小。在某些特定的环境中，可以将一个用例当作组织内的一个计划单元，该单元包括了担任系统的主角角色的个人。 动作。一个动作就是一个计算或算法过程。当主角向系统提供信号或当系统得到时间事件时，动作即被调用。动作可能包含向调用的主角或其他主角进行的信号传输。动作是不可分的，它要么完全执行，要么根本不执行。 特定主角。主角是查找正确用例的关键，这尤其是因为主角可帮助您避开太大的用例。例如，考虑一个可视化建模工具。该应用程序有两个真正的主角：开发人员，他负责以该工具作为支持来进行系统开发；系统管理员，他负责管理该工具。这两个主角对系统都有各自的要求，因而需要自己的用例集。 系统的功能由不同的用例来定义，每个用例都代表了一个特定的事件流。用例说明将定义执行用例时在系统中发生的事件。 例如，在自动柜员机中，客户可以从帐户中提取现金、将现金转入帐户或核对帐户余额。这些功能对应于可以用用例来代表的事件流。 每个用例本身就有一个要执行的任务。所收集到的用例组成了所有可能的系统使用方法。只需注意一下用例任务的名称，就可以对该用例任务有一个大致的了解。 如何查找用例 以下问题可以帮助您确定用例： 对于已确定的各个主角，哪些任务会涉及到系统？ 是否需要将系统中发生的某些特定事件通知给此主角？ 此主角是否需要将突发变更或外部变更通知给系统？ 系统是否给业务提供了正确的行为？ 您已经确定的用例是否可以执行所有功能？ 哪些用例将支持和维护系统？ 在系统内应该修改或创建什么信息？ 有些用例不代表系统的主要功能，因而通常会被忽略。这些用例可能属于以下类型： 系统启动和停止。 系统的维护。例如，添加新用户和建立用户简档。 维护在系统中存储的数据。例如，所构建的系统和遗留系统平行工作，所以数据需要在两个系统之间达到同步。 修改系统行为所需的功能。例如创建新报告的功能，它不仅可以创建硬代码，还可以对系统中存储的数据创建一组特定报告。 如果已经开发了业务用例模型和业务对象模型，另请参见指南：从业务模型到系统。 用例如何演进 在精化的早期迭代中，只对少数几个用例（在构架方面有重要意义的用例）进行比简要说明更为详细的说明。在深入到细节之前，通常应该先编写用例的提纲（按照分步格式）。此分步提纲应该是您定义用例事件流结构的首次尝试（请参见下文的事件流 - 结构）。始终要从基本的用例流开始。一旦对基本流提纲形成了一致意见，就可以添加与基本流相关的备选流内容。 当精化阶段即将结束时，应完成您计划要详细说明的所有用例。 是否详细说明了所有的用例？ 模型中通常会有一些简单的用例，它们不需要详细的事件流说明，对它们使用分步提纲就可以了。要作出这一决定，依据的标准是：您没有发现作为读者的用户对该用例的含义存在异议，而且设计人员和测试人员对于按分步格式提供的详细程度感到满意。这种简单用例的示例之一是描述简单的输入或从系统中检索某些数据的用例。 用例的范围 通常很难判断一组系统交互或对话是否属于一个或几个用例。请考虑回收机的使用情况。客户将贮藏物品（如罐子、瓶子和箱子）插入回收机。当插入所有的贮藏物品后，她按下某个按钮，打印了一份收据。这样，她就可以用这一收据换取现金。 是否插入贮藏物品属于一个用例，而索取收据属于另一个用例？或者，以上过程只是一个用例？此过程有两个动作，缺少了任何一个，另一个动作都对客户没有任何意义。所以，应该将所有插入和获取收据当作一个完整对话，这样才对客户有意义。因而，从插入第一个贮藏物品到按下按钮获得收据的完整对话过程是一个完整的用例，也就是一个用例。 此外，最好将这两个动作连在一起，这样就可