UML外卖系统报告（包含具体需求分析）

1 系统背景

随着互联网技术的快速发展，外卖订餐服务逐渐成为人们生活中的一部分。传统的电话订餐方式面临诸多不便和限制，而基于互联网的外卖订餐系统则提供了更加便捷、快速和高效的订餐服务。这种系统通过将餐厅、顾客和配送人员连接起来，实现了点餐、支付、配送等关键环节的无缝协作。

外卖订餐系统的目标是简化人们的订餐过程，提供便捷的外卖服务。系统允许顾客通过网页或手机应用平台进行在线订餐，浏览菜单、选择餐品、定制口味，并可选择不同的支付方式完成支付。餐厅方面可以通过系统管理菜单、接受新的订单、派发配送任务，并对订单进行统计和分析。配送人员可以通过系统接受配送任务，并实时更新配送进度。

外卖订餐系统的需求来源于顾客对于更加方便快捷的订餐方式的期望，以及餐厅和配送人员对于提升效率和客户满意度的追求。因此，通过设计和实现一个高效、可靠、易用的外卖订餐系统，可以提升整个订餐服务的质量和效率，实现顾客、餐厅和配送人员的共赢。

2 系统开发环境

2.1 硬件环境

项目	最低配置	推荐配置
内存	淮海晚报	2G
CPU	单核	四核
硬盘	10G	500G
带宽	512K	10M

表2-1 硬件环境表

2.2 软件环境

（1）操作系统：Windows 11

（2）数据库软件：

MySQL8.0： 用于支持数据库

Navicat Premium: 用于专业人员管理数据库数据

（3）Java环境：

java version “1.8.0_201”

Java™ SE Runtime Environment (build 1.8.0_201-b09)

Java HotSpot™ 64-Bit Server VM (build 25.201-b09, mixed mode)

1. 配置环境

IDEA 2019.3.3 x64

Node v14

网络：100Mbps的无线网络

2.3 相关技术

1. 编程语言：系统将使用Java作为主要开发语言，以实现系统的功能和逻辑。

2. 开发框架：系统将采用Spring、ASP.NET等作为开发框架，以提供开发所需的基础设施和工具。

3. 数据库：系统将使用MySQL作为数据存储和管理的技术，以支持数据的持久化存储和高效查询。

4. 前端技术：系统的用户界面将采用HTML、CSS、JavaScript等进行开发，以实现用户友好的交互体验和界面设计。

5. 云平台服务：系统的部署和运行将基于Azure提供的云计算服务，以实现系统的可用性、可扩展性和灵活性。

6. 版本控制：系统开发过程中将使用Git进行代码版本管理，以确保开发团队的协作和代码的版本控制。

3 需求分析

3.1 可行性分析

这个系统是基于Java并结合MySQL语言开发的外卖点餐系统。

在Java开发方面，我已经具备一定的基础，并在实践中深入研究了Java进阶教程，掌握了Windows图形化界面和Java面向对象等操作。

在数据库方面，我专注于MySQL关系型数据库，在实现外卖点餐系统中的数据操作时，严谨地运用各种MySQL关系型语句，并将其与Windows GUI界面相结合。

3.2 功能需求

1.系统组成：系统管理、订单管理、商家、订餐者、配送员。每个部门都有专门人员进行

管理执行不同的功能。

2.登录模块：用户使用自己的账号密码登录相应端系统，从而进行订餐、评论等操作。管理员使用自己的账号密码登录相应端系统，从而进行订单管理、评论、餐品管理等操作。（其中用户可为订餐者，配送员，商家，管理员）

3.评论模块：商家、配送员查看用户评价。

4.订餐模块：订餐者选择相应商家，在相应商家选择自己想要的菜，根据自己需求下订单，商家级配送员根据情况进行接单。订餐者可对自己的订单进行删除、添加等，订餐管理员可对订单进行查看、更新订单等。

5.店铺管理模块：商家根据店铺对商家名，商家介绍，及其相关菜品种类，价格进行修改、删除等操作以及申请成为外卖商家店铺操作。

6.订单管理模块：用户可对自己的订单进行删除、添加等，餐厅管理人员可对订单进行查看、更新订单等。

7.维护管理模块：管理员系统进行测试、修复及其相关用户管理。

3.3 性能需求

1. 并发处理：系统应能够处理大量用户同时访问、点餐和支付的需求，保证并发用户的正常操作。

2. 响应时间：系统应能够在合理的时间内响应用户的请求，包括菜单浏览、搜索、点餐和支付等功能的响应时间。

3. 可用性：系统应具备高可用性，保证24小时稳定运行，避免因系统故障或维护而导致的长时间无法使用。

4. 安全性：系统应保护用户信息的安全性，采用合适的加密和身份验证机制，防止未授权访问及数据泄露。

5. 扩展性：系统应具备良好的扩展性，能够根据用户量的增加灵活地扩展服务器和网络资源，以保证系统的性能和稳定性。

6. 容错性：系统应具备容错能力，能够处理和恢复部分系统故障，保证系统的连续性和可靠性。

以下是性能处理方面：

（1）并发度：1000（Tomcat）

（2）响应时间：5s

（3）事务处理：2分钟

（4）可扩展性：基于接口的MVC架构

（5）安全性：基于角色的权限管理

3.4 系统用例

1.参与者：①管理员②商家③订餐者④配送员

3.4.1顶层用例图

介绍个用例之间相互关系。

图1顶层用例图

3.4.2查看评价用例图

商家、配送员查看用户评价

图 2查看评价用例图

3.4.3登录用例图

用户使用自己的账号密码登录相应端系统，从而进行订餐、评论等操作。管理员使用自己的账号密码登录相应端系统，从而进行订单管理、评论、餐品管理等操作。（其中用户可为订餐者，配送员，商家，管理员）

图 3登录用例图

3.4.4订餐用例图

订餐者选择相应商家，在相应商家选择自己想要的菜，根据自己需求下订单，商家级配送员根据情况进行接单。订餐者可对自己的订单进行删除、添加等，订餐管理员可对订单进行查看、更新订单等。

图 4订餐用例图

3.4.5店铺管理用例图

图 5店铺管理用例图

3.4.6订单管理用例图

用户可对自己的订单进行删除、添加等，餐厅管理人员可对订单进行查看、更新订单等

图6 订单管理用例图

图7配送订单管理用例图

3.4.7维护系统用例图

管理员系统进行测试、修复及其相关用户管理。

图8维护系统用例图

3.4.8一级用例图

图9一级用例图

4 系统概要设计

4.1 系统运行原理

1. 用户注册与登录：

用户通过注册账号并登录系统，可以使用系统的各项功能。系统在用户注册时进行账号信息的有效性验证，并将用户信息保存在用户数据库中。

2. 餐厅信息管理：

管理员可以添加、编辑和删除餐厅信息，包括餐厅名称、地址、联系信息等。用户可以根据餐厅名和位置等信息查询餐厅，以选择合适的餐厅进行订餐。

3. 菜单管理：

餐厅管理员可以在系统中添加、编辑和删除菜单项，包括菜名、价格、描述等。用户可以浏览餐厅的菜单，并选择自己想要的菜品进行订购。

4. 订单管理：

用户选择菜品后，系统会根据用户的选择生成订单。订单包括用户信息、餐厅信息、菜品信息和订单状态等。系统会实时更新订单状态，例如待付款、正在配送和已完成等状态。

5. 支付与配送：

用户在系统中选择合适的支付方式完成付款，并填写配送地址和联系方式。系统将根据订单状态进行配送，并及时更新订单状态。用户可以通过系统追踪订单状态，以了解订单的配送进度。

6. 评价与反馈：

用户可以对已完成的订单进行评价和反馈。系统会显示用户的评价和餐厅的评分，以帮助其他用户选择餐厅和菜品。

7. 管理与维护：

系统管理员可以对系统进行管理和维护，包括用户管理、餐厅管理、订单管理等。管理员还可以分析和统计系统的运行情况，例如用户使用情况、菜品销量等，以便优化系统的性能和用户体验。

4.2 系统框架结构图

本系统采用了前后端分离的方式，在后端框架中我们可将其看成三层结构Web服务层、业务逻辑服务层和持久层，前端则是用Vue搭建的HTML页面，前后端通过Axios封装的Ajax技术跨域传值，数据则用Json格式封装，在这里前后端分离架构图如图4-1所示：

图4-1 前后端分离架构图

5 数据库设计

5.1需求分析

分析用户的需求，包括数据、功能和性能需求

5.1.1. 数据需求分析

• 用户需要存储和管理餐厅的菜单信息，包括菜名、描述、价格、类别等。

• 用户需要存储和管理用户信息，包括用户名、密码、联系方式等。

• 用户需要存储和管理订单信息，包括订单号、用户信息、菜单项、订单状态、订单金额

• 用户需要存储和管理配送地址信息，包括用户ID、收货人姓名、电话号码、地址等。

• 用户需要存储和管理支付信息，包括订单号、支付方式、支付状态、支付金额等。

5.1.2. 功能需求分析

• 用户需要能够通过系统浏览餐厅的菜单，并查看菜品的详细信息。

• 用户需要能够将菜品加入到购物车，并进行添加、编辑和删除操作。

• 用户需要能够下单，并选择配送地址和支付方式。

• 用户需要能够查看订单状态和支付状态，并进行相应的操作，如取消订单、确认收货等。

• 用户需要能够查看历史订单，并进行评价、投诉等操作。

• 管理员需要能够管理菜单，包括添加、编辑、删除菜品。

• 管理员需要能够管理用户，包括查看用户信息、冻结用户等操作。

• 管理员需要能够处理订单，包括接单、派送等操作。

5.1.3. 性能需求分析

• 系统需要能够处理大量用户的并发访问，保证用户的响应时间在可接受范围内。

• 数据库需要能够存储大量的菜品、用户、订单等数据，保证数据的读写操作的及时性和准确性。

• 系统需要具备良好的稳定性和可靠性，确保数据不会丢失或意外损坏。

• 数据库查询和索引设计需要优化，以提高系统的性能和响应速度。

5.2概念结构设计

主要采用E-R模型进行设计，包括画E-R图

图5.1 E-R图设计1

抽象出系统的实体，并设计部分E-R图，如下。

用户信息（用户编号、姓名、手机号、性别、身份证号、头像、状态）如图5. 2

图5.2 用户信息实体图

菜品信息（菜品编号、菜品名称、菜品分类id、菜品价格、商品码、图片、描述信息、状态、顺序、创建时间、更新时间、创建人、修改人）如图5.3

图5.3 菜品信息实体图

订单信息（订单编号、订单名、订单状态、下单用户、地址id、下单时间、结账时间、支付方式、实收金额、备注、手机号）如图5.4

图54 订单信息实体图

地址信息（编号、用户id、收货人、性别、手机号、省级区划编号、省级名称、市级区划编号、市级名称、区级区划编号、区级名称、详细地址、标签）如图5.5

图5.5 地址信息实体图

订单明细（编号、名字、图片、订单id、菜品id、套餐id、口味、数量、金额）如图5.6

图5.6 订单明细实体图

5.3逻辑结构设计

通过将E-R图转换成表，实现从E-R模型到关系模型的转换

据数据库概念结构设计中的实体及属性描述、以及数据库的规范化理论，设计管理员信息表、分类信息表、菜品管理信息表、订单信息表、订单明细表、、购物车信息表和用户信息表、表5.7至表5.12是各个数据库表的逻辑结构。

表5.7 管理员信息表

字段名	列类型与长度	描述	备注
num	varchar(255)	工号	主键
name	varchar(32)	姓名	非空
username	varchar(32)	姓名	非空
password	varchar(64)	密码	非空

表5.8分类信息表

字段名	列类型与长度	描述	备注
id	bigint(20)	编号	主键
type	int(11)	类型	非空
name	varchar(64)	分类名称	非空
sotr	int(11)	顺序	非空
Create_time	datetime	创建时间	非空
Update_time	datetime	更新时间	非空
Create_user	bigint(20)	创建人	非空
Update_user	bigint(20)	修改人	非空

表5.9 菜品管理信息表

字段名	列类型与长度	描述	备注
id	bigint(20)	编号	主键
name	varchar(64)	菜品名称	非空
category_id	bigint(20)	菜品分类id	非空
price	decimal(10,2)	菜品价格	非空
code	varchar(64)	商品码	非空
image	varchar(200)	图片	非空
description	varchar(400)	描述信息	非空
status	int(11)	0 停售 1 起售	非空
sort	int(11)	顺序	非空
Create_time	datetime	创建时间	非空
Update_time	datetime	更新时间	非空
Create_user	bigint(20)	创建人	非空
Update_user	bigint(20)	修改人	非空
is_deleted	int(11)	是否删除	非空

表5.10 订单信息表

字段名	列类型与长度	描述	备注
id	bigint(20)	编号	主键
number	varchar(50)	订单号	非空
status	int(11)	订单状态 1待付款，2待派送，3已派送，4已完成，5已取消	非空
user_id	bigint(20)	下单用户	非空
address_book_id	bigint(20)	地址id	非空
order_time	datetime	下单时间	非空
checkout_time	datetime	结账时间	非空
pay_method	int(11)	支付方式 1微信,2支付宝	非空
amount	varchar(255)	实收金额	非空
remark	varchar(255)	备注	非空
phone	varchar(11)	电话	非空
address	varchar(255)	地址	非空
user_name	varchar(32)	用户名	非空
consignee	varchar(50)	收货人	非空

表5.11