大型应用软件设计报告

组内成员及任务描述

第一章餐馆系统的业务建模

1.1非正式的需求

目的：通过改进为顾客预定和分配餐桌的过程，支持一家餐馆的日常经营。

原始手工系统速度慢，而且预约登记单很快会变得难以理解。这可能导致经营上的问题，例如，实际上有空餐桌而由于这个预约单不是很明显，会妨碍顾客进行预约；没有备份系统，如果一张预约单被损坏，那么餐桌就没有那个晚上的预约记录。

由于这些以及其他原因，该餐馆欲开发一个预约单的自动化系统。该系统应该和现有的预约单显示同样的信息，并且有大致相同的格式，使餐馆员工易于转换到新系统。当记录了新的预约时或对已有的预约进行修改时，应该立即更新显示，使餐馆员工在工作时，总能获得最新信息。

系统必须易于记录餐馆营业时发生的有意义的事情，例如顾客的到来。系统的操作应当尽可能直接操作屏幕上显示的数据。例如，可以简单地将一个预约拖到屏幕上的一个适当的位置，来改变分配的餐桌。

1.2用例建模

用例视图应该是客户、最终用户、领域专家、测试人员和任何其他的涉及系统的人员，不需要详细了解系统结构和实现就容易理解的。用例视图不描述软件系统的组织或结构，它的作用是给设计者施加约束，设计者必须设计出一个能够提供用例视图中指定的功能的结构。

1.2.1用例

可以通过考虑在系统实现后餐馆员工能够用它来做什么，简单地草拟出一组初步的用例。下面列出了这些用例所支持的主要任务：

1．记录一个新的预约信息（“记录预约”）。

2．取消一个预约（“取消预约”）。

3．记录一位顾客的到来（“记录到达”）。

4．将一位顾客从一张餐台移到另一张餐台（“调换餐台”）。

1.2.2参与者

在餐馆预约系统的案例中，所提出的用例可以分成两组。第一组由与维护提前预约信息有关的用例组成。顾客将联系餐馆提前预约或取消提前预约，一般地，接待员将接到这些电话并更新预约系统中存储的信息，因此，我们能够确定一个与相应用例关联的参与者。

在第二组中有许多任务需要在餐馆营业时执行，包括记录顾客的到来，以及为了适应不可预料的经营需要将一行用餐者从一个餐台移到另一个餐台。这些工作譬如说可能是一个侍者领班的责任，因此我们能够标识另一个与这些用例关联的参与者。

1.2.3用例图

用例图（use case diagram）以图解的形式概括了系统中的不同参与者和用例，并显示了哪些参与者能够参与哪些用例。餐馆预约系统的初始用例图如图所示：

1.3描述用例

用例描述了系统和它的用户之间在一定层次上的完整的交互。例如，一个打电话给餐馆进行预约的顾客，会和餐馆的一位将在系统中记录预约的店员讲话。为此，该店员需要充当一个接待员，即使这并不是他们正式职位的描述，并且以某种方式和系统交互。在这种情况下，该店员被认为是接待员参与者的一个实例，发生在接待员和系统之间的交互是用例的一个实例。

1.3.1事件路径

用例描述必须定义在执行用例时用户和系统之间可能的交互。

例如，在“记录预约”用例中，基本事件路径将描述这样的情况：一位顾客打电话进行预约，在要求的日期和时间有一张合适的餐台是空闲的，接待员输入顾客的姓名和电话号码

并记录预约。这样的事件路径，如下所示，能够以稍微结构化的方式表示，以强调用户的动作和系统响应之间的交互：

记录预约：基本事件路径

1. 接待员输入要预约的日期；

2. 系统显示该日的预约；

3. 有一张合适的餐台可以使用；接待员输入顾客的姓名和电话号码、预约的时间、用餐人数和餐台号；

4. 系统记录并显示新的预约。

如果在顾客要求的日期和时间没有可用的餐台，上面描述的基本事件路径就不能完成。

在这种情况下会发生什么可以通过一个可选事件路径描述，如下所示：记录预约——没有可用的餐台：可选事件路径

1.接待员输入要求预约的日期；

2.系统显示该日的预约；

3.没有合适的餐台可以使用，用例终止。

可选事件路径描述的情况，可以作为营业的一个正常部分出现，它们并没有指出产生了

误解，或者发生了错误。在另外一些情况下，也许因为一个错误或用户的疏忽而不可能完成基本事件路径，这些情况则由例外事件路径描述。

记录预约——餐台过小：例外事件路径

1. 接待员输入要求预约的日期；

2. 系统显示该日的预约；

3. 接待员输入顾客的姓名和电话，预约的时间，用餐人数和餐台号；

4. 输入的预约用餐人数多于要求餐台的最大指定大小，于是系统发出一个警告讯息询问用户是否想要继续预约。

5. 如果回答“否”，用例将不进行预约而终止；

6. 如果回答“是”，预约将被输入，并附有一个警告标志。

1.3.2用户界面原型

一般而言，在用例描述中详述用户界面不是个好主意。用例描述的重点是定义系统和用户之间交互的总体结构，而包含用户界面的细节会使之不清晰。并且，用户界面应该被设计得协调一致并便于使用，而这只有合理地考虑了各式各样的用户任务才能做到。如果用例描述不适当地指定了用户界面的细节，可能会使用户界面设计者的工作更加困难，或者需要大量改写用例描述。

1.4组织用例模型

一旦已经记录了一个预约，接下来必须要处理的重要事件是顾客到达餐馆，这由我们称为“记录到达”的用例描述。该用例的基本事件路径如下：记录到达：基本事件路径

1. 侍者领班输入当前日期；

2. 系统显示当天的预约；

3. 侍者领班确认一个选定的预约已经到达。

4. 系统对此进行记录并更新显示器，将顾客标记为已到达。

在这个用例中，如果系统记录中没有到达顾客的预约，可能发生一个可选事件路径。在

这种情况下，如果有适当的餐台是空闲的，则创建一个未经预约的登记。

记录到达——没有提前预定：可选事件路径

1. 侍者领班输入当前日期；

2. 系统显示当天的预约；

3. 系统中没有记录该顾客的预约，所以侍者领班输入预约时间、用餐人数和餐台号，创建一个未预约登记；

4. 系统记录并显示新预约。

比较这些事件路径和为“记录预约”用例所写的事件路径，显示出在这两个用例中存在着相当数量的某些共享功能。与其多次写出相同的交互，一种更好的方法是在一个地方定义共享行为并在适当的地方引用它。UML定义的用例图表示法提供了一些可以这样做的方法，能够产生一个更简单和结构更好的用例模型。

1.4.1用例包含

餐馆经理可能试图计算一个特定的晚上要雇佣多少个侍者，那么，简单地看看当天的预约可能是估计餐馆大约会有多繁忙的一个好办法。应该定义一个相应于显示给定一天的预约的任务的新用例。这个用例能够被餐馆的任何工作人员执行，因而任何参与者都可以在下面对基本事件路径的描述中被提及。

显示预约：基本事件路径

1. 用户输入一个日期；

2. 系统显示当日的预约。

这个新用例和已经描述的用例之间的关系可以这样来描绘：只要在执行其他用例之一时就包含“显示预约”用例中的交互。