核对表:用例
此核对表有助于确保所有用例均已正确描述并构建。
关系
相关元素
主要描述


检查项
每个具体的用例都至少与一个参与者关联吗
如果不是,就存在问题了。不与参与者交互的用例是多余的,应该将它删除。关于更多信息,请参阅指南:用例
用例之间是互相独立的吗
如果两个用例总是以相同的顺序激活,您可能就应该将它们合并成一个用例。
对于被包含用例
它以包含它的用例为前提吗?这样的前提是应该避免的,从而使对包含用例作出的变更不会影响被包含的用例。
是否有多个用例具有非常类似的行为或事件流
如果是(而且您希望它们的行为在将来仍然类似),您就应该将它们合并为一个用例。这样在将来引入变更就更加容易了。请注意:如果您决定合并用例,就必须要让用户参与进来,因为与新的、合并的用例交互的用户很可能会受影响。
部分事件流已经构建成另一个用例了吗
如果是,就可以让新的用例使用旧的用例。
事件流的某部分已经属于另一个用例了吗
如果是,就应该抽取这一子流,让它由所讨论的用例使用。请注意:如果您决定“重用”子流,就必须要让用户参与进来,因为现有用例的用户很可能会受影响。
一个用例的事件流应该插入到另一个用例的事件流中吗
如果是,您就应该将该用例构建为与另一个用例存在扩展关系。
用例的名称是唯一、直观和说明性(这样它们在将来的某个阶段不会与其他用例混淆)的吗
如果不是,请更改名称。
客户和用户对用例名称和说明的理解一致吗
每个用例名称都必须描述用例支持的行为。
用例满足明显控制其性能的所有需求吗
您必须在用例特殊需求中包含在对象模型中要处理的所有(非功能)需求。
参与者和用例间的通信顺序符合用户的期望吗
用例的事件流开始和结束的方式和时间明确吗
可能存在仅当不满足某个条件时才能激活的行为
有没有说明如果给定条件不满足会发生什么情况?
有没有过于复杂的用例
如果您希望您的用例模型容易理解,就可能必须对复杂的用例进行分解。
用例包含完全不同的事件流吗
如果是,最好将该用例分成两个或多个独立的用例。包含完全不同的事件流的用例会很难理解、很难维护。
用例中的子流的建模准确吗
明确了谁希望执行用例吗
用例的目的也清楚吗?
参与者交互和交换的信息清楚吗
简单说明真实地反映了用例吗