第6章 餐馆系统：设计 第5章产生的用例实化阐明了如何用应用层中的对象实现系统的业务功能。设计的最重要的任务就是将应用层的模型扩展到整个系统。本章将讨论一些处理输入输出和持久存储的基本策略，并且将细化分析类图，使它包含关于数据类型、消息参数等等更丰富的信息。在设计阶段终结前，我们的目的是要对系统有足够详细的理解，使实现可以开始。 为了设计系统的这些方面，我们需要对系统的软硬件环境做出一些决定。在接下来的这两章，我们将假定，餐馆预约系统要作为一个单用户的桌面应用系统实现。因此，我们将它设计为一个Jav a应用程序，其用户界面是基于窗口的。对于持久性，我们假定使用一个关系数据库存储有关预约和顾客等持久数据。 6 .1 接收用户输入 在第5章，来自用户的系统消息在顺序图中是作为指向一个代表预约系统的控制对象来显现的。但是，预约系统对象是一个应用层的对象，所以实际上消息并不会直接发送到这个对象。必须有某个表示层的对象，它的责任是接收用户的输入并转发给控制对象。 表示层的这个接收用户输入的对象可以很合理地描述为一个边界对象。它表示呈现给一个特定参与者的用户界面。就预约系统来说，我们假定所有用户使用相同的用户界面，因此将这个类命名为“StaffUI”。 我们假设，为了执行“显示预约”用例，用户首先要选择一个适当的菜单选项。这引起一个对话框的出现，在对话框中，用户输入需要的日期，然后单击“OK”按钮将请求提交给系统。通常，不值得对用户和标准用户界面构件，如菜单和对话框，交互的细节建模。用户界面框架提供了可复用的类来实现这些构件，而这些如何进行的细节可以安全地留作实现的议题。 重要的是在用户单击“OK”按钮以提交在对话框中输入的数据时所接收的消息。图6.1中，显示了这个边界对象 “StaffUI”，它接收这个消息，然后将处理这个消息的责任委派给先前确定的应用层中的控制对象。这是用协作图表示的，所以可以表明代表不同层的包，以阐明系统的架构。这也说明，在UML中，包是一个相当弱的概念，链接和消息可以轻易地跨越包的边界。 图6 .1 处理系统消息 在用户可以通过标准动作，例如由鼠标产生消息，与系统交互的情况下，经常需要由系统来处理各个用户界面事件。在这些情况下，边界对象的作用更加重要。 例如，有些用例要求用户选择一个显示的预约。选择预约很自然的一种方法是用户用鼠标单击该预约，这种方法支持直接操纵所显示的预约目标。用户界面...
