UML学习06.pptVIP

系统的诞生 用例、参与者 业务建模 描述系统需求 描述系统需求 一旦标识了用例，指定了它们的组合方式，就需要显示细节。 №7 用例的细节 描述系统需求 UML没有指定应包含哪些细节或如何安排，通常根据经验进行选择。 №7 用例的细节 用例号 用例是否为抽象的 与其他用例的关系 前提条件(在执行用例前必须满足的条件) 步骤(假定满足了前提条件) 后置条件(在完成用例后必须满足的条件) 异常路径和在这些情况下应做什么(尽管路径是异常的，但如果它们对指定系统的反应非常重要，也应包含它们) 与这个用例相关的非功能性需求 第六章 收集需求 根据Standish Group对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。 而在这些高达74%的不成功项目中，有约60%的失败是源于需求问题。 有近45%的项目因为需求的问题最终导致失败。 在Standish Group的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关： №1 不完整的需求； №2 没有用户的介入； №3 不实际的客户期望； №4 需求和规范的变理； №5 提供了不再需要的。 需求阶段的目标 检查业务上下文：在考虑开发系统前，必须调查系统运行的业务上下文； 首先需要弄清楚开发系统的原因； 在决定开发系统后，就需要理解业务，并且对业务的理解应与客户的理解相同。 需求阶段的目标 描述系统需求：一旦理解了业务，并把这些理解整理为业务需求，就需要考虑系统应为用户完成什么任务。 确定系统的功能； 找出所有的约束条件：性能、开发成本、资源。 需求阶段的目标 切忌 每个系统都从某个位置开始：顾客可能提供了详细的文档，一般包含专用布局和目录；也可能只提供了任务陈述。 商店将汽车的跟踪自动化了——使用条形码、柜台终端和激光阅读器，这有许多优点：租赁助手的效率提高了20％，汽车很少失踪，客户群很快变大(根据市场调查，其部分原因至少是专业化和效率的显著提高)。 管理层认为，Internet会提供进一步提高效率、降低成本的机会。例如，现在不是打印可用汽车的目录，而可以让每个Internet冲浪人员在线浏览这些目录。对于有特权的客户，可以提供额外的服务，例如通过鼠标点击进行预约。这个领域的目标是每个商店的运营成本降低15％。 在两年内，使用电子商务的所有功能，通过Web浏览器提供所有的服务，在客户家中完成汽车的交付和收回，以达到虚拟租赁公司的目标，将未预约业务的运营成本降到最低。 用例：是部分业务或系统的使用方式； 用例是外部可见的系统功能单元； 用例是对一个系统或一个应用的一种单一的使用方式所作的描述，是关于单个活动者在与系统对话（交互）中所执行的处理行为的陈述序列。 例如：通过前面的任务描述可以知道，会员可以预约指定型号的汽车——“会员预约汽车型号”——这是一个业务用例。 我们要开发的系统就需要提供这种预约功能，因此，“预约”就是一个系统用例，它描述了要开发的系统如何让客户通过Internet进行预约。 用例、参与者 参与者是为了完成一个事件而与系统交互的实体，是用户相对系统而言所演的角色 参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者；2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者；3）时钟：当系统需要定时触发时，时钟就是参与者 我们按照一般创建顺序，依次介绍业务模型的组件。 下面要介绍的建模顺序不是一个硬性的工作流，可以从前、从后迭代，或多次重复，直到得到完整的业务模型为止。 首先，需要标识业务参与者 参与者是在业务中扮演某个角色的人、部门或独立的系统。 业务建模 №1 标识业务参与者 术语是不同专业领域中的专用语，非本专业的人不能理解，为便于不同的人员理解和交流，需要对术语进行解释和定义。 术语表的每一项都定义了一个术语，定义可长可短； 术语表可以让查看软件开发产品的人觉得行话不再神秘。 术语表还可以减小同义词的组合，允许在文档的其他地方自由使用同义词中的一个。 业务建模 №2 编写项目术语表 业务建模 №2 编写项目术语表 有了参与者后，接下来就是标识用例。 在业务建模阶段，用例可以理解为一种“服务”。 在业务建模的过程中，只是描述业务当前运作的方式，对新系统的运作方式不做考虑。 业务建模 №3 标识业务用例 如何把业务分解为用例，目前没有普遍的规则可以遵循，通常依靠常识、逻辑和经验。并且通常需要和客户一起进行划分。 业务建模 №3 标识