体系结构第17章.pptVIP

* * 第十七章 开发用例 收集了系统的需求，下一步就该分析系统的每项需求了。这一章要学习的内容有： ● 分析和描述用例。 ● 用例的描述格式、前置条件和后置条件。 ● 描述用例执行步骤。 ● 绘制用例图。 第18章“收集系统需求”所得到的每个功能包中的用例说明了系统必须要做的事。开发组还必须分析和理解每个用例。开发组正在从理解领域逐步走向 对实际系统的理解。用例是两者之间的桥梁。 如果你已经体会到系统开发项目是由用例驱动的，那么就能更好地理解整个开发过程。注意联合应用开发会议并没有讨论开发小组如何完成每个用例所涉及的活动。会议的主题仅仅是尽可能列出所有可能的用例。这一章要详细分析上一章所列举出的用例，并开始研究如何将WIN系统中的构件具体化。开发过程进行到现在，要开发的具体系统才开始真正成为舞台上的主角。 我们将跟踪开发组的工作，处理上一章列举的部分用例。 17.1 分析和描述用例 为了分析用例，还要再开一次联合应用开发会议，这个会议的议题是导出和分析每个用例。 这里有一句告诫：用例联合应用开发会议可能是最困难的会议，因为它需要与会者(最终系统的可能用户)成为系统分析员。在他们每个人各自的职责范围内，每人都是小的领域专家，必须发挥出他们各自的专长。 典型情况是，他们不习惯于或者不善于表达出或分析出他们所了解的业务知识。这可能是因为 他们以前从没有参与过系统的开发工作，缺乏经验。或者是他们不能很清楚地表达出到底要让系统为他们做什么事。 为了解决或缓解这个问题，最好在组织联合应用开发会议时一次只请一组用户参加(例如，一组服务员)。作为整体领域专家的餐馆老板，也应出席会议，帮助参加会议的一组服务员分析他们的用例。在处理Customer包中的用例时，包括多种用户的混合用户组应当一起参加会议。 系统中的用例数目通常很大。为了简化本章的内容，我们只处理Server包中的前9个用例。学习完 这些用例的处理过程后，你将能够处理Server包中的其余用例，以及其他包中的用例。 17.2 用例分析 回忆“用例图”中的部分内容：每个用例是一组场景的集合，每个场景又由一系列步骤组成。对于每个用例中的每个场景，需要说明的内容有： ● 场景的简单陈述。 ● 关于场景的假设条件。 ● 场景的前置条件。 ● 用例的发起参与者。 ● 场景中与系统相关的步骤序列。 ● 场景完成后的后置条件。 ● 用例的受益参与者。 除了上述内容以外，还包括异常条件或可选的场景流程。本章做了适当的简化。 在设计文档中(提交给客户和程序员的用来指导开发的文档)，每个用例应当单独占一页，这一页最好包括一张用例图，图中画出这个用例和用例的参与者。 与系统相共的步骤序列在场景中极其重要。它说明了系统的预期工作方式。当联合应用开发会议的参与者告诉分析员这些步骤序列时，也就意味着告诉了分析员系统最终如何工作。当会议结束后，分析员就能得出系统中包括那些构件。 关于场景的假设也很重要。后面将会看到，根据这些假设清单，就可以列出设计中要注意的事项。 以上说明了系统开发项目是由“用例驱功”的。用例是构造系统的途径。 17.3 Server包 Server类要参与许多活动，因为Server类几乎与其他每个类都有关联。 Server包中的用例有： 17.3.1 用例“Take an order” 我们从用例“Take an order”开始。我们必须根据服务员提供的用例描述、假设条件、前置条件、步骤序列和后置条件来描述用例。功能包早已清楚地指明这个用例的发起参与者(Server)和受益参与者(Customer)。 对这个用例的一句话的叙述可以是“服务员将顾客的定单信息输入到他的手提式个人计算机中并将定单信息传递到厨房。”假设条件是顾客想就餐，顾客已经阅读了菜单并做出了选择。另一个假设条件是服务员的手提式个人计算机已经出现了“输入定单”用户界面。 前置条件是顾客已经就坐并阅读了菜单，后置条件是定单被输入进WIN系统中。 用例的步骤序列是： 1．服务员激活他的手提式个人计算机的“输入定单”用户界面。 2．“输入定单”用户界面出现在显示器屏幕