第7章开发用例.ppt

第十七章 开发用例;对实际系统的理解。用例是两者之间的桥梁。 如果你已经体会到系统开发项目是由用例驱动的，那么就能更好地理解整个开发过程。注意联合应用开发会议并没有讨论开发小组如何完成每个用例所涉及的活动。会议的主题仅仅是尽可能列出所有可能的用例。这一章要详细分析上一章所列举出的用例，并开始研究如何将WIN系统中的构件具体化。开发过程进行到现在，要开发的具体系统才开始真正成为舞台上的主角。 我们将跟踪开发组的工作，处理上一章列举的部分用例。;17.1 分析和描述用例;他们以前从没有参与过系统的开发工作，缺乏经验。或者是他们不能很清楚地表达出到底要让系统为他们做什么事。 为了解决或缓解这个问题，最好在组织联合应用开发会议时一次只请一组用户参加(例如，一组服务员)。作为整体领域专家的餐馆老板，也应出席会议，帮助参加会议的一组服务员分析他们的用例。在处理Customer包中的用例时，包括多种用户的混合用户组应当一起参加会议。 系统中的用例数目通常很大。为了简化本章的内容，我们只处理Server包中的前9个用例。学习完;这些用例的处理过程后，你将能够处理Server包中的其余用例，以及其他包中的用例。; ● 用例的发起参与者。 ● 场景中与系统相关的步骤序列。 ● 场景完成后的后置条件。 ● 用例的受益参与者。 除了上述内容以外，还包括异常条件或可选的场景流程。本章做了适当的简化。 在设计文档中(提交给客户和程序员的用来指导开发的文档)，每个用例应当单独占一页，这一页最好包括一张用例图，图中画出这个用例和用例的参与者。; 与系统相共的步骤序列在场景中极其重要。它说明了系统的预期工作方式。当联合应用开发会议的参与者告诉分析员这些步骤序列时，也就意味着告诉了分析员系统最终如何工作。当会议结束后，分析员就能得出系统中包括那些构件。 关于场景的假设也很重要。后面将会看到，根据这些假设清单，就可以列出设计中要注意的事项。 以上说明了系统开发项目是由“用例驱功”的。用例是构造系统的途径。;17.3 Server包;17.3.1 用例“Take an order” 我们从用例“Take an order”开始。我们必须根据服务员提供的用例描述、假设条件、前置条件、步骤序列和后置条件来描述用例。功能包早已清楚地指明这个用例的发起参与者(Server)和受益参与者(Customer)。 对这个用例的一句话的叙述可以是“服务员将顾客的定单信息输入到他的手提式个人计算机中并将定单信息传递到厨房。”假设条件是顾客想就餐，顾客已经阅读了菜单并做出了选择。另一个假设条件是服务员的手提式个人计算机已经出现了“输入定单”用户界面。; 前置条件是顾客已经就坐并阅读了菜单，后置条件是定单被输入进WIN系统中。 用例的步骤序列是： 1．服务员激活他的手提式个人计算机的“输入定单”用户界面。 2．“输入定单”用户界面出现在显示器屏幕上。 3．服务员将顾客的菜单选项输入到WIN系统中。 4．系统将定单发送到厨房的桌面电脑。 尽管我们假设“输入定单”用户界面的存在，但到目前为止我们根本不知道这个界面看起来是什么样子，也没有说明传送定单的任何技术细节。; 这里的基本原则是当我们阐述出系统的设计假设后，就开始考虑系统应当能够做什么，并且要开始绞尽脑汁地思考怎样让系统做它应当做的事。 用例的步骤序列迫使我们不得不思考组成系统的构件有哪些。记住，用例分析的目标是描述出用户所看到的系统。 17.3.2 用例“Transmit the order to the kitchen” 这个用例至少应被包含在(也就是被使用)两个用例当中——前一个用例和用例“Change an order”。 用例的叙述是：“将输入到手提式个人计算机中的定单通过无线网络传送到厨房的桌面电脑。”假设;条件是已经具备了通信手段(通过无线网络)以及具备了“输入定单”用户界面。 与其他用例的假设条件重复了的假设条件还要叙述出来吗?是的。每个用例在设计文档中都占单独的页。为了清晰起见，即使与其他用例的假设条件相同，每个用例的假设条件都应该完整地被叙述出来。 前置条件是定单信息已经被录入到手提式个人计算机中，后置条件是定单被正确传递到厨房的桌面电脑。受益参与者是Customer