基于UML的餐馆预约系统的设计与实现第一章 餐馆系统的业务建模11 非正式的需求要开发的系统的意图是，通过改进为顾客预定和分配餐桌的过程，支持一家餐馆的日常经营。111 对计算机化系统的需要原始手工系统速度慢，而且，预约登记单很快就变得难以理解。这可能导致经营上的问题，例如，实际上有空餐桌而由于这个预约单不是很明显，会妨碍顾客进行预约；没有备份系统，如果一张预约单被毁坏了，餐桌就没有了那个晚上有什么预约的记录。由于这些以及其他原因，该餐馆意欲开发一个预约单的自动化版本。新系统应该和现有的预约单显示同样的信息，并且有大致相同的格式，使餐馆员工易于转换到新系统。当记录了新的预约时，或者对已有的预约进行修改时，应该立即更新显示，使餐馆员工在工作时总能使用可获得的最新信息。系统必须易于记录餐馆营业时发生的有意义的事情，例如顾客的到来。系统的操作应当尽可能是直接操作屏幕上显示的数据。例如，可以简单地将预约拖动到屏幕上一个适当的位置以改变一个预约的时间或者分配的餐桌。12 用例建模用例视图应该是客户、最终用户、领域专家、测试人员和任何其他涉及系统的人员，不需要详细了解系统结构和实现就容易理解的。用例视图不描述软件系统的组织或结构，它的作用是给设计者施加约束，设计者必须设计出一个能够提供用例视图中指定的功能的结构。121 用例通过考虑在系统实现后餐馆员工能够用它来做什么，草拟出一组初步的用例。这些用例所支持的主要任务：（1） 记录一个新的预约信息（“记录预约”）（2） 取消一个预约（“取消预约”）（3） 记录一位顾客的到来（“记录到来”）（4） 将一位顾客从一张餐桌移到另一张餐桌（“调换餐桌”）122 参与者在餐馆预约系统中，所提出的用例可以分成两组。第一组由与维护提前预约信息有关的用例组成。顾客将联系餐馆提前预约或取消提前预约，一般地，接待员将接到这些电话并更新预约系统中存储的信息，因此，我们能够确定一个相应用例关联的参与者。在第二组中有许多任务需要在餐馆营业时执行，包括记录顾客的到来，以及为了适应不可预料的经营需要将一行用餐者从一个餐桌移到另一个餐桌。这些工作譬如说可能是一个侍者领班的责任，因此我们能够标识另一个与这些用例关联的参与者。123 用例图餐馆预约系统的初始用例图如图11所示，其中包括了上面确定的参与者与用例。13 描述用例用例描述了系统和它的用户之间在一定层次上的完整的交互。例如，一个打电话给餐馆进行预约的顾客，会和餐馆的一位将在系统中记录预约的店员讲话，该店员需要充当一个接待员（即使这并不是他们正式职位的描述），并且以某种方式和系统交互。这种情况下，该店员被认为是接待员参与者的一个实例，发生在接待员和系统之间的交互是用例的一个实例。131 事件路径用例描述必须定义在执行用例时用户和系统之间的交互。在“记录预约”用例中，基本事件路径将描述这样的情况：一位顾客打电话进行预约，在要求的日期和时间有一张合适的餐桌是空闲的，接待员输入顾客的姓名和电话号码并记录预约。这样的事件路径，如下所示，能够以稍微结构化的方式表示，以强调用户的动作和系统响应之间的交互：记录预约：基本事件路径（1） 接待员输入要预约的日期；（2） 系统显示该日的预约；（3） 有一张合适的餐桌可以使用：接待员输入顾客的姓名和电话号码、预约的时间、用餐人数和餐桌号；（4） 系统记录并显示该预约。如果在顾客要求的日期和时间没有可用的餐桌，上面描述的基本事件路径就不能完成。在这种情况下会发生什么可以通过一个可选事件路径描述，如下所示：记录预约没有可用的餐桌：可选事件路径（1） 接待员输入要求预约的日期；（2） 系统显示该日的预约；（3） 没有合适的餐桌可以使用，用例终止。可选事件路径描述的情况，可以作为营业的一个正常部分出现，它们并没有指出产生了误解，或者发生了错误。在另外一些情况下，也许因为一个错误或用户的疏忽而不可能完成基本事件路径，这些情况则由例外事件路径描述。如果接待员错误地试图将一个预约分配到过小而不能满足就餐者人数的餐桌就座时，这可能就要作为一个例外事件路径描述了。记录预约餐桌过小：例外事件路径（1） 接待员输入要求预约的日期；（2） 系统显示该日的预约；（3） 接待员输入顾客的姓名和电话，预约的时间，用餐人数和餐桌号；（4） 输入的预约用餐人数多于餐桌能容纳的人数，于是系统发出一个警告信息询问用户是否想要继续预约；（5） 如果回答“否”，用例将不进行预约而终止；（6） 如果回答“是”，预约将被输入，并附有一个警告标志。132 用户界面原型用例描述的重点是定义系统和用户之间交互的总体结构，而包含用户界面的细节会使之不清晰。并且，用户界面应该被设计得协调一致并便于使用，而这只有合理地考虑了各式各样的用户任务才能做到。14 组织用例模型记录一个预约后要处理的重要事件是顾客到达餐馆，该用例的基本事件路径如下：记录到达：基本事件路径（1） 侍者领班输入当前日期；（2） 系统显示当天的预约；（3） 侍者领班确认一个选定的预约已经到达；（4） 系统对此进行记录并更新显示器，将顾客标记为已到达。在这个用例中，如果系统记录中没有到达顾客的预约，可能发生一个可选事件路径：如果有适当的餐桌是空闲的，则创建一个未经预约的登记。记录到达没有提前预定：可选事件路径（1） 侍者领班输入当前日期；（2） 系统显示当天的预约；（3） 系统中没有记录该顾客的预约，所以侍者领班输入预约时间、用餐人数和餐桌号，创建一个未预约登记；（4） 系统记录并显示新预约。141 用例包含考虑餐馆经理可能试图计算一个特定的晚上要雇佣多少个侍者，那么，简单地看看当天的预约可能是估计餐馆大约会有多繁忙的一个好办法。这就需要定义一个相应于显示给定一天预约任务的新用例。这个用例能够被餐馆的任何工作人员执行，因而任何参与者都可以在下面对基本事件路径的描述中被提及。显示预约：基本事件路径（1） 用户输入一个日期；（2） 系统显示当日的预约。这个新用例和已经描述的用例之间的关系可以这样来描述：只要在执行其他用例之一时就包含“显示预约”用例中的交互。记录预约：基本事件路径（修改）（1） 接待员执行 “显示预约”用例；（2） 接待员输入顾客姓名和电话号码、预定的时间、用餐人数以及预留的餐桌；（3） 系统记录和显示新预约。一个用例和它所包含的其他用例之间的关系在用例图中用一个连接两个用例的虚线箭头表示，称为依赖。图12表示了“记录预约”和“显示预约”之间的“包含”依赖性。142 参与者泛化参与者之间泛化的含义是，特化的参与者可以参与和更一般的参与者关联的所有用例。图13中描述了一个新参与者，它表示餐馆所有员工可以共享的能力，称为“员工”已有的参与者通过泛化与新参与者相关，表示它们被看作是“员工”的特殊情况，定义了只能由一个员工子集共享的附加特性。图13指定了接待员和侍者领班都可以执行“显示预约”用例。另外，可以指派给特化的参与者更多的责任，图13指定只有接待员才能够记录预约，而只有侍者领班才可以记录到达。143 用例扩展“记录到达”用例的可选事件路径规定，如果系统没有记录一个顾客的预约，侍者领班将通过创建一个未预约登记来表示他们在餐馆用餐的事实。但是，将记录未预约登记表示为单独一个用例可能更好一些，因为未预约登记将会为那些从不提前进行预约的顾客创建。“记录未预约顾客”用例的基本事件路径将会被某个没有预约就来用餐的人触发。它的结构非常类似于“记录预约”用例，只是在记录的细节上不同。记录未预约顾客：基本事件路径（1） 侍者领班执行“显示预约”用例；（2） 侍者领班输入时间、用餐人数和分配给顾客的餐桌；（3） 系统记录并显示新预约。“记录到达”用例的可选事件路径和这个新用例的描述之间有相当多的重叠。“记录未预约顾客”用例只是在“记录到达”的某些情况下被执行，也就是该顾客没有记录的预约，但有一个适当的餐桌空闲，并且顾客还想在餐馆用餐时才被执行。“记录到达”用例可以被“记录未预约顾客”用例扩展，来描述这种情况。如图1415 完成用例模型取消预约的基本事件路径可以如下指定。取消预约：基本事件路径（1） 接待员选择要求的预约；（2） 接待员取消该预约；（3） 系统询问接待员确认取消；（4） 接待员回答“是”，系统记录取消并更新显示。“调换餐桌”用例的基本事件路径也可以独立于用户界面的细节进行定义如下。调换餐桌：基本事件路径（1） 侍者领班选择需要的预约；（2） 侍者领班改变该预约的餐桌分配；（3） 系统记录改变并更新显示。这个用例可以通过一个菜单选项调用，由用户在一个对话框中填写新的餐桌号，或者通过将预约矩形拖到它的新位置完成调换餐桌。151 一个用例模型完成图15描述的是一个完整的用例图，它是总结了上面对餐馆预约系统的第一次迭代的用例讨论。16 领域建模在餐馆预约系统中，关键的业务需求是记录顾客已经预定的事实，所以领域建模可以从标识表示预定和顾客这两个类开始。系统必须记录每个进行预定的顾客的姓名和电话号码，比较合理的是将这些作为顾客类的属性建模。预定的日期和时间是很直接的属性，可以作为属性建模。系统还必须记录分配给一个预定的餐桌，这可以通过将餐桌号作为预定的另一个属性来记录，还有一个选择是将每张餐桌作为一个自主对象建模，因而在领域模型中引入了一个餐桌类。餐馆需要记录每张餐桌的其他信息，例如，餐桌可以容纳的用餐人数。在一个对象模型中，这个信息必须作为一个类的属性记录，而餐桌类是存储该信息的很自然的地方。图17是扩充以后包含了预定的各种特性的领域模型。预定类和餐桌类之间的关联的重数指明一个预定只能对应一张餐桌，排除了餐馆为就座于多个餐桌的大团体提供预定的可能。领域模型没有涉及未预约的就餐者，未预约和预定由一些共同的属性，就是存储的基本数据和到餐桌的链接，但不同的是对未预约的顾客没有顾客信息的记录。对模型的这个细化如图18所示。第二章 餐馆系统的分析21 分析的目的以用例描述的形式所陈述的需求是定义系统外部行为非常有价值的工具，但是对系统的内部结构，或如何提出一组交互的对象来支持所要求的功能并没有给出任何指导。因此，把分析的任务描述为是构造一个模型，来说明这些交互的对象如何能够交付用例中规定的行为。22 对象设计为了产生实化一个用例的交互图，必须在一组对象之间分配所需要的数据和处理，从而这些对象就可以进行交互以支持用例规定的功能。221 对象责任面向对象程序设计的启示是软件对象反映的是在现实世界或应用领域中找出对象。面向对象系统中的数据不是保存在一个单独的中央数据存储中，而是分布在系统的所有对象中。可以用责任的术语来描述说每个对象负责管理系统中数据的一个子集。一个对象负责的数据不仅包括它的属性值，还包括它所维护的与系统中其他对象的链接。对象负有的另一类责任是支持某些处理，这些处理最终在它的类所实现的方法中定义。由对象进行的处理典型地包括：在该对象可用的数据上实行某些计算，或者通过给其他对象发送消息协同进行一个较大的操作以及用它们返回的数据做些事情。对象设计的一个基本原则是，在进行用例实化时，设计者应该定义具有功能上内聚的责任集的对象和类。23 软件架构定义良好的对象应该有一组内聚的责任。例如，在餐馆预约系统的情况中，可能会提出建议，顾客对象应该负责任何与顾客有关的事宜，从在屏幕上显示顾客信息，维护顾客的姓名和电话号码使之可以使用，到将这些数据存储到一个关系数