应用型软件开发报告模板.doc

PAGE  PAGE 20 应用型软件开发报告模板 篇一：大型应用软件设计报告 组内成员及任务描述 第一章 餐馆系统的业务建模 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用户界面原型 一般而言，在用例描述中详述用户界面不是个好主意。用例描述的重点是定义系统和用户之间交互的总体结构，而包含用户界