交互和状态变化.pptVIP

* * 第十八章 交互和状态变化 本章将在前一章用例分析的基础上进一步深入研究用例。用例将作为理解系统的功能部件和它们之间交互的基础。本章的主要内容有： ● 列举出系统中的工作部件。 ● 修改用例。 ● 分析功能部件之间的交互。 上一章介绍的用例的分析离开发出最终的实际WIN系统还很远，甚至离编码都还有一定的距离。 分析用例有助于澄清系统中的功能部件。尽管我们 现在已经对用例了解很多了，但是仍然要进一步建立系统中的工作部件之间的交互和功能部件状态变化(如何变化和何时变化)的模型。有了这些信息后，程序员的工作就变得容易许多，他们就知道如何对类编码以及如何使类相互协作。 18.1 系统中的工作部件 一种开始分析的方式是首先根据每个功能包中的用例列举出系统所包括的工作部件。尽管我们在上一章没有分析每个包中的所有用例，但仍然能列举出用例所提示出的系统工作部件。 18.1.1 Server包 在上一张中我们通过分析Server包中的前9个用例列举出了系统的一些软件部件。在手提式个人计算机上，WIN系统需要“输入定单(order entry)” 、“修改定单(change order)”、“跟踪定单状态(order status tracking)”、“顾客状态(customer status)”和“消息发送(message sending)”等屏幕界面。一个主屏幕界面也是必需的。我们的分析还说明厨房的桌面电脑需要一个“跟踪定单(order-tracking)”屏幕界面。除此之外，WIM系统还需要一个数据库来保存定单信息。 上一章我们没分析的用例也能提示出系统的 构件。例如，“Summon an assistant”用例需要一个给助手发消息的屏幕界面；“Take a drink order”用例需要一个输入饮料定单的屏幕界面。通过这些用户界面还必须能够接收确认消息(例如，一名清洁师收到了服务员发出的召唤请求后或者收到了休息室发来的饮料已经为顾客准备好的消息后要发回一个确认应答消息)。 对于Server包，它所要求的主要系统构件无非是一些与定单录入和消息收发等有关的用户屏幕界面。 同样，Chef包、Busser包和Assistant包中的用例需要的构件也可以类似得出。 18.1.2 Bartender包 这个包中的用例需要饮料数据库和相应的用户界面屏幕来访问数据库中的饮料信息。吧台服务员使用的用户界面必须要显示出来自服务员的通知消息(顾客的餐桌已经准备好的消息)以及来自服务员的请求饮料消息。吧台服务员同样要能够发送对上述两个消息的确认应答消息。 18.1.3 Coat-check clerk包 衣帽保管员的手提式电脑中的软件构件应当包括打印票据的用户屏幕界面。打印出的票据应当包括每个条目名称和条目的描述，而且系统还应当 具有一个所保管物品信息的数据库。 18.2 系统中的交互 下面要说明系统中的构件如何交互以实现用例所代表的功能。下面我们对Server包中的用例中构件之间的交互建立模型。系统中的用例数目可能很大，但实际的开发项目对每个用例都要做这件事。前面的章节我们已经学习过，每个用例背后都隐藏着一张顺序图。 18.2.1 用例“Take an order” 先从用例“Take an order”开始，根据第19章“开发 用例”，这个用例的步骤序列为： 1．服务员激活他的手提式个人计算机的“输入定单”用户界面。 2．“输入定单”用户界面出现在显示器屏幕上。 3．服务员将顾客的菜单选项录入到WIN系统中。 4．系统将定单发送到厨房的桌面电脑。 根据上一章开发出的用例模型，这个用例包含了“Tansmit the order to the kitchen”，此用例的步骤序列为： 1．点击“定单”用户界面上的“send to kitchen” 按钮。 2 ． WIN系统将定单发送到无线局域网。 3．定单到达厨房的桌面电脑。 4．“输入定单”用户界面出现提示信息，提示定单已经被正确传递到厨房的桌面电脑。 一张顺序图将会精确地表示出用例中的交互，为了绘制顺序图我们必须要考虑几方面的问题。 首先，当服务员接到了顾客的定单，实际上，服务员要创建某种事物——一份定单。它是WIN系统中的一个对象(同样也是在前面的领域分析中识别出的 Order