软件工程课程设计-餐厅订餐管理信息系统.doc

- 1 - 经济管理学院 本科软件工程课程设计 餐厅订餐管理信息系统 组长： 组员： 2009 年 7 月 15 日 - 2 - 目 录 第第 1 1 章章 绪绪 论论 - 4 - 1.1 系统开发的背景和意义- 4 - 1.2 国内外研究发展现状- 4 - 1.2.1 面向对象技术的发展与现状- 4 - 1.2.2 UML 的建模语言- 5 - 1.2.3 UML 的应用领域- 6 - 1.2.4 网上订餐的发展与现状- 6 - 第第 2 2 章章 业务建模业务建模 - 7 - 2.1 RUP 软件开发过程- 7 - 2.2 业务术语表- 8 - 2.3 主业务用例图- 9 - 第第 3 3 章章 分析与设计分析与设计 - 10 - 3.1 业务流程调查- 10 - 3.1.1 订餐系统业务流程调查- 10 - 3.1.2 岗位职责- 11 - 3.2 业务用例分析- 11 - 3.2.2 订餐系统活动图- 15 - 3.3 顺序图- 18 - 餐厅订餐系统的顺序图- 19 - 3.3.1 CancelBooking- 19 - 3.3.2 DeleteMember- 20 - 3.3.3 DisplayBooking- 20 - 3.3.4DisplayMember- 21 - 3.3.5 ModifyBooking- 22 - 3.3.6 ModifyMember- 23 - 3.3.7RecordArrival- 23 - 3.3.8RecordBooking - 24 - 3.3.9RecordLeft - 25 - 3.3.10RecordWalkIn- 26 - 3.3.11RegisterMember- 27 - 3.3.12RemindBooking- 28 - - 3 - 3.3.13SearchBooking- 28 - 3.4 协作图- 29 - 订餐系统协作图- 29 - 3.4.1 CancelBooking- 30 - 3.4.2 DisplayMember- 30 - 3.4.3ModifyBooking- 31 - 3.4.4ModifyMember- 31 - 3.4.5RecordArrival- 32 - 3.4.6RecordBooking - 33 - 3.4.7RecordLeft - 33 - 3.4.8RecordWalkIn- 34 - 3.4.6RegisterMember- 35 - 3.4.9RemindBooking- 35 - 3.4.10SearchBooking- 36 - 3.5 活动图- 36 - 3.6 业务类图- 37 - 3.6.1 餐厅订餐系统业务类图- 37 - 3.6.2 餐厅订餐系统业务类描述- 38 - 3.6.3 数据库详细设计- 39 - 第第 4 章章 系统实现系统实现 - 39 - 4.1 系统构件图 - 39 - 4.5 部署图- 39 - 4.5.1 网络结构图- 39 - 4.5.2 系统部署图- 39 - 4.6 界面设计- 39 - 4.6.1 本系统用户界面程序设计遵循的原则- 39 - 4.6.2 输入输出设计- 39 - - - 4 - - 第 1 章 绪 论 1.1 系统开发的背景和意义 随着全球经济一体化的逐步发展和深入，网上订餐已成为传统订餐必不可少的经营策略之 一。目前，网上订餐在国际互联网上可以实现的商务功能已经多样化，可以完成从最基本的信 息展示、信息发布功能到在线交易、在线客户服务、在线网站管理等功能，可以说，现在传统 订餐所具备的功能几乎都可以在互联网上进行电子商务的高效运作，虽然传统订餐的规模有所 不同，但是随着互联网与电子商务的发展，它将有力的改变现存企业竞争的模式，给企业以高 效低成本的发展空间。 1.2 国内外研究发展现状 1.2.1 面向对象技术的发展与现状 目前，我国的信息化水平不仅远远落后于起步较早的西方发达国家，而且大大逊色于与我 们起点相同的邻国印度。采用传统面向过程的方法开发应用系统，程序元素（数据、语句）相 互之间的关系复杂，系统功能隐含在程序代码中，造成开发困难、维护不易，且稳定性、可重 用性较差。在系统开发方面，利用传统程序设计语言的软件开发方法出现于 20 世纪 70 年代， 在 80 年代被广泛采用，其中最重要的是结构化分析和结构化设计方法（Yourdon-79）和它的变 体，如实时结构化设计方法等。这些方法最初由 Constantine、Mellor、Ward、Yourdon 和其他 一些人发明和推广，在一些大型系统，特别是和政府签约的航空和国防领域的系统中取得了一 定突破，在这些系统中，主持项目的政府官员强调开发过程的有组织性和开发设计文档的完备 和充分。结果不是像预料的那么好许多计算机辅助软件工程系统（CASE）只是摘录一些已 实现的系统设计的报表生成器，尽管如此，这些方法中仍包含一些好的思想，有时在一些大系 统中是很有效的。 随着应用系统规模的日益庞大，面向过程的程序设计方法，越来越难以胜任软件系统的开 发。20 世纪 80 年代在软件开发各种概念和方法积累的基础上，对于如何超越程序复杂性障碍、 如何在计算机系统中自然地表示客观世界，人们拿起了思维科学中的面向对象技术作为武器。 面向对象思想的运用，被认为是程序设计方法学方面的一场实质性革命。Maurice Wilkes 在图 灵奖颁奖仪式上说：“对象是软件界 80 年代以来最激动人心的革新之一。” 90 年代，面向对 象技术四面开花、蓬勃发展，面向对象方法的应用从编程阶段延伸至软件开发的上游、下游阶 段，出现了面向对象分析、面向对象设计、面向对象测试等技术。如今，面向对象技术成为计 算机领域中的一种主流技术，在学术界，面向对象的方法与技术已经成为最受关注的研究热点 - - 5 - - 之一；在产业界，越来越多的公司从传统的软件开发技术转向面向对象技术，特别是在一些发 达国家，几乎所有的新软件开发都全面或部分地采用面向对象技术。 1.2.2 UML 的建模语言 1997 年 11 月，UML 被 OMG 全体成员一致通过，并被采纳为标准。OMG 承担了进一步完善 UML 标准的工作。在 UML 标准通过前，就已经有许多概括 UML 精华的书出版发行。许多软件开发 工具供应商声称他们的产品支持或计划支持 UML，若干软件工程方法学家宣布他们将使用 UML 的 表示法进行以后的研究工作。UML 的出现似乎深受计算机界欢迎，因为它是由官方出面集中了许 多专家的经验形成的，减少了各种软件开发工具之间无谓的分歧。我们希望建模语言的标准化 既能促进软件开发人员广泛使用面向对象建模技术，同时也能带来 UML 支持工具和培训市场的 繁荣，因为不论是用户还是供应商都不用再考虑到底应该采用哪一种开发方法。 UML 的最终目标是在尽可能简单的同时能够对实际需要建立的系统的各个方面建模。UML 需 要有足够的表达能力以便可以处理现代软件系统中出现的所有概念，例如并发和分布，以及软 件工程中使用的技巧，如封装和组件。它必须是一个通用语言，像任何一种通用程序设计语言 一样。然而，这样就意味着 UML 必将十分庞大，不可能像描述一个近乎于玩具一样的软件系统 那样简单。现代语言和操作系统比起 40 年前要复杂多，因为我们对它们的要求越来越多。UML 提供了多种模型，不是在一天之内就能够掌握的。它比先前的建模语言更复杂，因为它更全面。 计算机技术的飞速发展创造了人类历史上新的奇迹，但是，随着现代软件工程的复杂程度 不断提高，项目失败的可能性也相应的增加了。信息系统的专家们发现当他们面对越来越多的 源代码的时候，脑海中系统模型及其内部的联系也越发混沌和模糊了。面对现代社会庞大而繁 杂的信息事务，专家们渴望使信息变得简单易懂。无论何种复杂程度的工程项目，设计者都是 从建模开始的，设计者通过创建模型和设计蓝图来描述系统的结构。比如说，电子工程设计人 员使用惯用标记和示意图进行复杂的系统的最初设计，会计总是在表格上规划公司的财务蓝图， 而行政管理人员则常使用组织结构图这种可视化的方式来描述所管理的部门。正是因为感到无 法对整个复杂的系统全面地把握，所以我需要建模。 建模的意义重大， “分而治之” ，这是一个古老而有效的概念。可以想象，当我们把特别复 杂而困难的问题细化分解之后，一次只是设法解决其中一个的时候，事情就容易解决多了。模 型的作用就是使复杂的信息关联变的简单易懂，它使我们容易洞察复杂堆砌而成的原始数据背 后的规律，并能有效地使我们将系统需求映射到软件结构上去。 Rose 支持三层结构方案。浏览器/服务器体系结构的广泛使用预示了系统复杂化的发展趋势， 为了解决这一问题，与之相应的三层结构方案越来越得到了广泛的应用。传统的两层结构不是 “胖客户机”就是“胖服务器” ，胖客户机结构将事务处理原则放在用户端处理，胖服务器则将 - - 6 - - 之集成在数据库中，大量的数据流动为维护和编程带来了极大的困难，而且，其中包含的事务 处理原则不能与其它应用共享。三层结构方案是指由用户接口层、事务处理原则层和数据层的 应用模型。与传统的两层结构相比，它有着更多的优点：对应用结构任意一层做出修改时，只 对其它层产生极小的影响。固有的可塑性，三层既可共存于单机之中，也可根据需要相互分开。 公用代码数据库使事务处理规则在系统中共享。 1.2.3 UML 的应用领域 UML 的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。其中最常 用的是建立软件系统的模型，但它同样可以用于非软件领域的系统，如机械系统、企业机构或 业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之,UML 是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。此外,UML 适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。在需求分析阶段,可以用 用例来捕获用户需求。通过用例建模,描述对系统感兴趣的外部角色及其对系统(用例)的功能要 求。分析阶段主要关心问题域中的主要概念(如抽象、类和对象等)和机制,需要识别这些类以及 它们相互间的关系,并用 UML 类图来描述。 为实现用例,类之间需要协作,这可以用 UML 动态模型来描述。在分析阶段,只对问题域的对 象(现实世界的概念)建模,而不考虑定义软件系统中技术细节的类(如处理用户接口、数据库、 通讯和并行性等问题的类)。这些技术细节将在设计阶段引入,因此设计阶段为构造阶段提供更 详细的规格说明。编程(构造)是一个独立的阶段,其任务是用面向对象编程语言将来自设计阶段 的类转换成实际的代码。在用 UML 建立分析和设计模型时,应尽量避免考虑把模型转换成某种特 定的编程语言。因为在早期阶段,模型仅仅是理解和分析系统结构的工具,过早考虑编码问题十 分不利于建立简单正确的模型。UML 模型还可作为测试阶段的依据。系统通常需要经过单元测试、 集成测试、系统测试和验收测试。不同的测试小组使用不同的 UML 图作为测试依据:单元测试使 用类图和类规格说明；集成测试使用部件图和合作图；系统测试使用用例图来验证系统的行为， 验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。 总之，标准建模语言 UML 适用于以面向对象技术来描述任何类型的系统，而且适用于系统 开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。 1.2.4 网上订餐的发展与现状 随着科技的高速发展，互联网正以前所未有的冲击力影响着人类的生活。我国网民人数由 2000 年 1 月的 890 万激增到 2009 年底的 3.36 亿名，网上购物也不再是白领们追求时尚的专利， 它益发地受到人们的推崇，成为了越来越多人生活方式。网上订餐业务就是在这样的环境下日 - - 7 - - 趋升温。如何更好地开展网上订餐业务意义非凡。 网上订餐系统可以使企业通过站点，让顾客直接从网站订货。同时通过与一些电子商务服务机 构合作，简化过去资金流转的问题。 第 2 章 业务建模 统一建模语言（UML）是一个通用的可视化建模语言，用于对软件进行描述、可视化处理、 构造和建立软件系统制品的文档。它记录了对必须构造的系统的决定和理解，可用于对系统的 理解、设计、浏览、配置、维护和信息控制。UML 适用于各种软件开发方法、软件生命周期的各 个阶段、各种应用领域以及各种开发工具，是一种总结了以往建模技术的经验并吸收当今优秀 成果的标准建模方法。UML 包括概念的语义、表示法和说明，提供了静态、动态、系统环境及组 织结构的模型。它可被交互的可视化建模工具所支持，这些工具提供了代码生成器和报表生成 器。UML 标准并没有定义一种标准的开发过程，但它适用于迭代式的开发过程。它是为支持大部 分现存的面向对象开发过程而设计的。 UML 不是一门程序设计语言。但可以使用代码生成器工具将 UML 模型转换为多种程序设计语 言代码，或使用反向生成器工具将程序源代码转换为 UML。UML 不是一种可用于定理证明的高度 形式化的语言，这样的语言有很多种，但它们通用性较差，不易理解和使用。UML 是一种通用建 模语言。对于一些专门领域，例如用户图形界面（GUI）设计、超大规模集成电路（VLSI）设计、 基于规则的人工智能领域，使用专门的语言和工具可能会更适合些。UML 是一种离散的建模语言， 不适合对诸如工程和物理学领域中的连续系统建模。它是一个综合的通用建模语言，适合对诸 如由计算机软件、固件或数字逻辑构成的离散系统建模。 UML 描述了一个系统的静态结构和动态行为。UML 将系统描述为一些离散的相互作用的对象 并最终为外部用户提供一定功能的模型结构。静态结构定义了系统中重要对象的属性和操作以 及这些对象之间的相互关系。动态行为定义了对象的时间特性和对象为完成目标而相互进行通 信的机制。从不同但相互联系的角度对系统建立的模型可用于不同的目的。 UML 还包括可将模型分解成包的结构组件，以便于软件小组将大的系统分解成易于处理的块 结构，并理解和控制各个包间的依赖关系，在复杂的开发环境中管理模型单元。它还包括用于 显示系统实现和组织运行的组件。 2.1 RUP 软件开发过程 Rational Unified Process（RUP，统一开发过程）是一套面向对象的软件工程过程。RUP 说明了如何有效地使用成熟技术开发软件。传统软件项目失败的原因有： 1混乱的需求管理。 2开发者之间以及开发者和用户不清晰的交流 - - 8 - - 3架构不够坚固。 4没有发现需求、设计和实现中的不一致。 5缺少有效的测试。 6对项目状态的主观估计。 7没有正确地处理项目开发过程中的风险。 8没有对项目变更进行控制。 如瀑布模型将软件生存周期划分为 6 个阶段：需求分析、设计、实现、测试、运行和维护。 瀑布模型最为突出的缺点是缺乏灵活性。传统的瀑布开发模型是一个一维的模型，开发过程被 划分为多个连续的阶段。在 RUP 中，软件开发生命周期根据时间和 RUP 的核心工作流划分为二 维空间。横轴表示项目的时间维，纵轴以内容来组织为自然的逻辑活动。 图 2-1 RUP 软件开发过程 RUP 中有 9 个核心工作流，分为 6 个核心过程工作流（Core Process Workflows）和 3 个核 心支持工作流（Core Supporting Workflows） 。9 个核心工作流在项目中轮流被使用，在每一次 迭代中以不同的重点和强度重复。业务建模（Business Modeling）理解系统的组织结构及其商 业运作，确保所有参与人员对开发系统有共同的认识。 2.2 业务术语表 软件构架：在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结 构问题包括总体组织结构和全局控制结构，通信、同步和数据访问的协议，设计元素的功能分 配，物理分布，设计元素的组成，定标与性能，备选设计的选择。 逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包 和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。 实施视图：包括实施模型及其从模块到包和层的组织形式的概览。同时还描述了将逻辑视 - - 9 - - 图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。 进程视图：包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象 和类向任务的分配情况。只有在系统具有很高程度的并行时，才需要该视图。在 Rational Unified Process 中，它是设计模型的子集。 配置视图：包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图） 向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。 用例图：用例图是包括参与者、由系统边界（一个矩形）封闭的一组用例、参与者和用例 之间的关联、用例间的关系以及参与者的泛化的图。用例图表示了来自用例模型（用例，参与 者）的元素。 活动图：活动图是状态机的一个特殊例子，在该状态机中所有的或大部分的状态都是活动 状态或动作状态，所有或大部分的转换由源状态中活动的完成所触发。活动图表示一个程序或 工作流。活动图是模型中的完整单元。 类图：类图是静态视图的图形表达方式，表示声明的（静态的）模型元素，如类、类型及 其内容及相互关系。类图可以表示包的视图，包含嵌套包的符号。 协作图：协作图是表示角色间交互的视图，即，协作中的实例及其链接。与顺序图不同， 协作图表示了角色之间的关系。另一方面，协作图也不将时间作为单独的维来表示，所以必须 使用顺序号来判断消息的顺序以及并行线程。 2.3 主业务用例图 本系统是一个餐馆订餐系统，主要功能是为餐馆提供订餐记录和维护功能，同时由我们自 己扩展了订菜和定时提醒的功能。下面使用了用例图的方式表现了整个系统的所有功能。系统 用例图如图 2-2 所示： - - 10 - - Display bookings Staff Cancel booking Record booking Remind booking Receptionist Record arrival Record walk-in Register member Delete member Display member informationModify member information Search empty table Table transfer Head Waiter Record left Cancel booking Record booking Remind booking Record arrival Register member Delete member Display member informationModify member information Search empty table Table transfer Record left Record walk-in Display bookings ReceptionistHead WaiterStaff 图 2-2 系统用例图 第 3 章 分析与设计 系统分析与设计过程首先根据业务用例和业务活动图进行聚类，聚类活动在系统分析时开 始。聚类活动是个连续的过程，需要不断地进行丰富和完善，需要按照面向对象设计的思想， 划分出子系统类，并为类添加应该具有的方法或属性，以及这些方法或属性的可见性，这些可 以通过设计类图来描述。系统设计的任务就是要依据系统分析文档资料，采用正确的方法，确 定系统功能模块在计算机内应该用那些程序组成，它们之间用什么方式连接在一起，以构成一 个最好的系统结构。 3.1 业务流程调查 3.1.1 订餐系统业务流程调查 信息系统分析与设计的第一步是要了解和理解业务。在这个过程中需要通过问卷调查、现 场调研、业务实习等手段了解业务开展的组织机构、掌握业务活动的规律、理解用户的实际需 求，通过简洁直观的方式展示给用户，并以此作为业务讨论的依据和摸板，最终形成用户和开 发者双方都能理解的标准文档。 - - 11 - - 3.1.2 岗位职责 1餐厅经理：本岗位的主要职责是控制整个餐厅的运作，有效控制整个公司的工作，从而 提高竞争力。 2侍者领班：本岗位的主要职责是指导监督餐厅服务人员的工作。 3.接待员：本岗位的主要职责是接待用餐人员，安排餐住。 4财务人员：本岗位的主要职责是进行各种开销和财务结算工作。 3.2 业务用例分析 用例视图是被称为参与者的外部用户所能观察到的系统功能的模型图。用例是系统中的一 个功能单元，可以被描述为参与者与系统之间的一次交互作用。用例模型的用途是列出系统中 的用例和参与者，并显示哪个参与者参与了哪个用例的执行。 用例建模的主要目标是： 1. 将需求模型变为可视化模型，并最终得到用户确认； 2.给出清晰、一致的关于系统做什么的描述，确定系统的功能要求； 3.提供从功能需求到系统分析、设计、实现各阶段的度量标准； 4.为最终系统测试提供基准，据此验证系统是否达到功能要求。 3.2.1 订餐系统用例图 系统的功能需求使用用例图来描述，将用例分析和描述分解详述如下： 用例名：Record booking 角色：Receptionist 目的：记录预约 描述： 1、 接待员执行“显示预约”用例； 2、 有一张合适的（equal）餐桌（table）可以使用；接待员输入顾客姓名和电话号码、 预订时间、用餐人数以及预留的餐桌 3、 系统记录和显示新预约 没有可用的餐桌：可选事件路径 1、 接待员执行“显示预约”用例； 2、 没有合适的餐桌可以使用，用例终止 判断 judge 用例名：Remind booking - - 12 - - 角色：Receptionist 目的：订餐提醒 描述： 1、 系统显示预约用餐时间超过当前系统时间的预约 2、 接待员执行“显示预约”用例 3、 接待员打电话提醒顾客，询问是否取消预约 4、 如果顾客回答“否” ，用例终止 5、 如果顾客回答“是” ，接待员执行“取消预约”用例 用例名：Cancel booking 角色：Receptionist 目的：取消订单 描述： 1、 接待员选择要求的预约 2、 接待员取消预约 3、 系统询问接待员确认取消 4、 接待员回答“是” ，系统记录取消并更新显示 用例名：Table transfer 角色：Receptionist ,Head Waiter 目的：换桌 描述： 1、 侍者领班选择需要的预约 2、 侍者领班改变该预约的餐桌分配 3、 系统记录改变并更新显示 用例名：Display bookings 角色：用户 目的：显示餐馆信息 描述 1、 用户输入一个日期 2、 系统显示当日的预约 用例名：Search empty table 角色：Receptionist 目的：查找空桌 描述： 1、 接待员输入日期和时间 - - 13 - - 2、 系统显示空桌的信息 用例名：Modify member information 角色：用户 目的：修改会员 描述： 1、 用户执行“显示会员信息”用例 2、 修改会员信息 3、 系统询问用户确认修改 4、 用户确认修改 5、 用户回答“是” ，系统记录更新并显示更新 用例名：Display member information 角色：用户 目的：显示会员信息 描述： 1、 用户输入会员号 2、 系统显示该会员的信息 用例名：Delete member 角色 Head Waiter 目的：删除会员 描述： 1、 侍者领班选择要取消的会员 2、 侍者领班取消该会员 3、 系统询问侍者领班确认取消 4、 侍者领班回答“是” ，系统记录取消并更新显示 用例名：Register member 角色：Head Waiter 目的：会员注册 描述： 1、 侍者领班输入顾客的姓名和电话号码 2、 系统记录并显示该顾客的信息 可选事件路径 1、 侍者领班输入顾客的姓名和电话号码 2、 系统显示已存在持有该姓名和电话号码的会员，用例终止 用例名：Record left 角色 Receptionist - - 14 - - 目的：记录离开 描述： 1、 接待员输入餐桌号 2、 系统显示使用该餐桌的所有预约和未预约登记 3、 如果存在预约或未预约登记处于用餐状态，接待员确认该预约或未预约登记已 经离开 4、 系统对此进行记录并更新显示器，将顾客标记为已离开 不存在预约和未预约登记：可选事件路径 1、 接待员输入餐桌号 2、 系统显示使用该餐桌的所有预约和未预约登记 3、 如果不存在预约或未预约登记处于用餐状态，用例终止 用例名：Record walk-in 角色 Head Waiter 目的：记录未预约登记 描述： 1、 侍者领班执行“显示预约”用例 2、 侍者领班输入时间、用餐人数和分配给顾客的餐桌 3、 系统记录并显示新预约 没有可用的餐桌：可选事件路径 1、 接待员执行“显示预约”用例； 2、 没有合适的餐桌可以使用，用例终止 用例名：Record arrival 角色 Head Waiter 目的：记录到达 描述： 1、 侍者领班执行“显示预约”用例 2、 侍者领班确认一个选定的预约已经到达 3、 系统对此进行记录并更新显示，将顾客标记为已到达 不存在预约：可选事件路径 1、 侍者领班执行“显示预约”用例 2、 系统中没有记录该顾客的预约，所以侍者领班输入预约时间、用餐人数和餐桌 号，创建一个未预约登记 3、 系统记录并显示新预约 不存在预约&没有可用餐桌：可选事件路径 - - 15 - - 1、 侍者领班执行“显示预约”用例 2、 系统中没有记录该顾客的预约，并且当前没有合适的餐桌可以使用，用例终止 3.2.2 订餐系统活动图 在用例的基础上，需要对每一个业务活动进行详细描述。UML 中的活动图用于描述满足用例 要求所要进行的活动以及活动间的约束关系，有利于识别并行活动和工作流程情况。活动图实 际上就是用来为用例的事件流建模的工具。下面用活动图来对订餐系统的主要活动进行描述。 图 3-1 描述了餐厅订餐系统的记录预约活动图 图 3-1 记录预约活动图 。 图 3-2 描述了餐厅订餐系统的记录到达活动图。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 业 业 业 业 业业 业 业 业 业 业业 业 业 业 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 业 业 业 业 业业 业 业 业 业 业业 业 业 业 - - 16 - - 图 3-2 记录到达活动图 - - 17 - - 图 3-3 描述了餐厅订餐系统的记录离开活动图。 图 3-3 记录离开 图 3-4 描述了餐厅订餐系统的修改会员信息活动图。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、