课件文稿软件开发2015 ch_04_05_06.ppt

* 东南大学“软件开发方法与技术”课程 * 东南大学“软件开发方法与技术”课程 * 东南大学“软件开发方法与技术”课程 * 东南大学“软件开发方法与技术”课程 * 东南大学“软件开发方法与技术”课程 * 东南大学“软件开发方法与技术”课程 Explaining the Sections(各部分的解释) 绪言元素：最重要的元素放在USE CASE的一开始，次要放到USE CASE 的末尾。 * 东南大学“软件开发方法与技术”课程 … 项目相关人员及其兴趣列表: 这个列表十分重要和实用。它建议并界定了系统必须做什么。 * 东南大学“软件开发方法与技术”课程 … 前置条件和后置条件：前置条件规定了在用例中的一个场景开始之前必须为“真”的条件。前置条件在用例中不会被检验，我们假定这些条件都是满足的。后置条件规定了用例成功结束后必须为“真”的条件。 * 东南大学“软件开发方法与技术”课程 … 主要成功场景和步骤（或基本流程）：它描述了能够满足项目相关人员兴趣的典型成功路径。它通常不包括任何条件和分支，可以将所有的条件处理放到“扩展”部分，从而使主要成功场景更容易理解和扩展。 * 东南大学“软件开发方法与技术”课程 … 扩展（或替代流程）：“扩展”部分非产重要，它们说明了所有其它的场景或分支，无论是成功的场景还是失败的场景。 * 东南大学“软件开发方法与技术”课程 … 特殊要求：如果有一些与此用例有关的非功能需求（象质量属性或约束条件），那么将它们和用例记录在一起。 * 东南大学“软件开发方法与技术”课程 … 技术和数据的变化列表：系统通常有一些技术上的变化是关于“应该怎么做”，而不是“应该做什么”，需要在用例中将这种变化记录下来。 * 东南大学“软件开发方法与技术”课程 用例的目标和范围 How should use cases be discovered? It is common to be unsure if something is a valid (or more practically, a useful) use case. Tasks can be grouped at many levels of granularity, from one or a few small steps, up to enterprise-level activities. At what level and scope should use cases be expressed? * 东南大学“软件开发方法与技术”课程 How should use cases be discovered? Which of these is a valid use case? Negotiate a Supplier Contract Handle Returns Log In 可以认为这些都是用例，但它们处于不同的级别，依赖于系统边界、参与者和目标。 在POS系统的实例中，与其泛泛地问“什么是合理的用例？”，不如更直接地问：“对应用的需求分析来说，在什么级别上描述用例最有帮助。” * 东南大学“软件开发方法与技术”课程 Elementary Business Process (EBP) According to EBP, a use-case should describe: A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state. e.g., Approve Credit or Price Order [original source lost]. * 东南大学“软件开发方法与技术”课程 EBP指导原则 用例不是类似“删除一个列表项”或“打印文档”这样简单的小步骤。一个成功场景会包含5－10这样步骤。用例也不是一个需要好几天和很多对话才能完成的工作，例如“谈判一个供货合同”。它是能够在一个对话、几分钟或一个小时的时间内就可以完成的任务。 A common use case mistake is defining many use cases at too low a level; that is, as a single step, subfunction, or subtask within an EBP. 对计算机应用进行需求分析的时候，应专注于“基本业务过程（EBP）级别的用例”。 * 东南大学“软件开发方法与技术”课程 So… Whi