第6章餐馆系统的设计.pptVIP

第6章 餐馆系统的设计 第5章产生的用例实化阐明了如何用应用层中的对象实现系统的业务功能。 设计最重要的任务就是将应用层的模型扩展到整个系统。 本章将讨论一些处理输入输出和持久存储的基本策略，并且细化分析类图，使它包含关于数据类型、消息参数等等更丰富的信息 假定餐馆预约系统要作为一个单用户的桌面应用系统实现 6.1 接收用户输入 在第5章，来自用户的系统消息在顺序图中是作为指向一个代表预约系统的控制对象来显示的。 但是，预约系统对象是一个应用层的对象，所以实际上消息并不会直接发送到这个对象。必须有某个表示层的对象，它的责任是接收用户的输入并转发给控制对象 表示层的这个接收用户输入的对象可以很合理地描述为一个边界对象(StaffUI) 通常，不值得对用户和标准用户界面构件(如菜单和对话框)交互的细节建模。用户界面框架提供了可复用的类来实现这些构件，而这些如何进行的细节可以安全地留作实现的议题 将鼠标坐标转化为对应有意义的信息的责任交给了用户界面对象 有些交互包含多个用户产生的事件。例如，用户能够将预约从一个餐桌移动到另一个餐桌，方法是将预约的矩形从屏幕上的一个位置拖到另一个位置。 这个交互将涉及用户产生的多个事件：开始是一个按下鼠标(mouse down)消息选择所需的预定，接着是若干移动鼠标(mouse move)消息，最后是一个松开鼠标(mouse up)消息，表明预约已经放在它最终的位置 Transfer消息只是在预约的新位置松开鼠标键的时候才被发送给预约系统。这表明，边界对象检测到的用户产生的事件和发送给控制器的系统消息之间的对应不必要是一对一 6.2 产生输出 StaffUI类具有两个不同的角色： 1.作为边界类，接收来自用户的消息并将消息转发给控制器类 2.作为视图类，将应用数据或模型呈现给用户(显示系统的输出) 为确保用户所看到的和系统状态是一致的，需借助某些方法让视图知道模型中的变化 一种常见而且简单的实现方法是由视图类对应用类进行定期的查询，以发现是否有什么变化(轮询) 使用轮询存在很多问题(费时) 更好的办法：只要应用有什么变化，由应用类来通知视图类，对视图的更新只是在需要时才发生 但是，应用层应该独立于表示层。如何通知？ 6.2.1 应用设计模式 观察者模式适用于： 1.一个对象的变化需要改变其他对象，并且你不知道有多少对象需要改变的时候 2.一个对象应该能够通知其他对象，而无需设想那些对象是谁的时候 目前的情况包含了这两个条件的元素：想要视图对象随着应用对象的变化而改变，并且想让应用对象能够通知视图对象的这个变化，但不依赖视图对象 问题的解决依赖于多态性和动态绑定。在应用层定义一个接口，任何希望接到模型相关变化的通知的类必须实现该接口。这样的类称为观察者。这个接口非常简单，包含单独一个操作，只要显示需要更新时就调用这个操作 预约系统类维护一组对观察者的引用，当它们的状态改变时，就向每个观察者发送update消息。观察者可以是无论什么类，但是预约系统只通过应用层定义的接口去访问观察者，如此就保持了系统的层次结构 表示层的StaffUI类实现了BookingObserver接口。在UML中，接口的实现是用带空心箭头的虚线表示的。在系统开始工作时，通过addObserver操作向预约系统的观察者列表加入一个StaffUI的实例。这样，由于动态绑定，StaffUI对象就会收到发给观察者列表的update消息 一旦StaffUI对象收到了updateDisplay消息，它就需要查明什么发生了改变 6.3 持久数据存储 持久数据是指以某种方式长时间或永久地存储的数据，使数据在系统关闭时不会丢失，而在需要的时候可以重新装入 有多种可能的存储策略能够用于提供持久性。本节中的设计基础是假设使用关系数据库提供持久存储 实现分为两个不同部分： 1.设计一个数据库模式是必要的，它允许存储和检索系统的代码所保存的数据 2.必须设计访问数据库以及从数据库读出数据和写入数据的代码 6.3.1 设计数据库模式 第一步需决定哪些数据需要作为持久的 下一步是描述持久类和关联如何保存在数据库中。 将类图映射到关系数据库模式的基本策略就是用一个表来表示每一个类 对存储关联的问题的常见的解决办法是使对象本体在数据库中明确化，方法是给每个表一个额外的域来表示特定实例的本体 对象标识符充当每个表的主键，即使在类的属性中似乎存在一个自然的键的情况下 6.3.2 保存和装入持久对象 定义系统如何在数据库和内存之间移动持久数据 一种简单的方法是基于一个类一个类地来处理数据：对模型中的每个持久类，定义一个相关联的映射器类，其责任是在需要时将数据存储到数据库，以及根据保存的数据值重建对象 为每个持久类定义一个表示持久对象的子类，这个子类新增加一个属性来保存