前言
📌博主介绍：一线全栈工程师，毕设实战引路人。技术栈覆盖Java、Python、C#、PHP、Node.js及UniApp跨端开发，擅长多语言项目落地与架构设计。持续分享毕设源码、开题报告、技术选型心得与职场踩坑经验。用工程化思维写代码，帮你把毕设做成作品集。👍👍
👇🏻 精彩专栏 推荐订阅👇🏻
uniapp/微信小程序/安卓app精品实战案例【2000套】
✅文末获取源码✅
感兴趣的可以先收藏起来，还有大家在毕设选题，项目以及论文编写等相关问题都可以找我咨询，希望帮助更多的人❤️
系统分析
UML用例图是描述系统功能需求的图形化工具，用它来表示系统与外部参与者之间的交互关系，可以清楚地知道系统的功能。用例图是用用例来表示系统可以执行的具体功能，参与者是和系统交互的各种用户或者外部系统。用例图在分析设计阶段使用，可以保证系统功能的完整正确，也可以帮助开发人员和客户达成一致。用例图是用直观的图形来表示系统功能和角色之间的一一对应关系。本文将对系统按照角色模块进行需求分析。
管理员角色
管理员在系统中负责平台秩序的管理与维护，查看平台任务大厅内全部公开的任务信息，可以进行查询、重置或者删除等操作。管理员对订单信息进行监控，处理异常的接单行为。订单沟通记录可以被管理员查看，保证交流内容符合规范。订单延时申请要经过管理员审核或者备案。送达信息由管理员进行核对和归档。用户提交的反馈投诉由管理员受理审核后作出相应处理。跑腿用户的提现申请需要管理员审核通过之后才能进行打款。管理员角色用例图如图所示。
管理员用例图
消费者角色
消费者角色通过系统发布个人跑腿需求，在任务大厅浏览、搜索、查看任务详情，对感兴趣的任务可以点赞或者收藏。用户填写任务要求、费用、上传相关图片后提交发布。用户可以查看已经发布的任务的接单状态以及接单者信息。当订单需要更改送达时间的时候，用户可以提交延时申请并解释原因。用户在下单时可以和接单的跑腿用户进行在线交流。订单完成后用户查看送达信息并对服务进行反馈或者投诉。用户角色用例图如图所示。
消费者用例图
骑手角色
骑手角色可以在系统中提供跑腿服务，可以浏览任务大厅，选择合适的任务进行接单。接单之后，跑腿用户需要管理自己的接单信息，在任务完成后上传物品相片、填写备注来确认送达。在订单执行的过程中，跑腿人员要同发布任务的用户进行沟通，及时回复用户的问题。跑腿用户可以查看自己对投诉的反馈。对于由于用户原因造成的订单延时，跑腿用户可以查看相关记录。跑腿用户账户余额可以提现申请功能中选择提现方式，输入卡号金额后提交申请。跑腿用户角色用例图如图所示。
跑腿用户用例图
可行性分析
从技术可行性上来说，本系统所用的技术栈成熟、生态健全。SpringBoot框架可以简化Java后端服务的配置和部署，可以快速创建RESTful API。Vue.js作为渐进式前端框架，组件化开发方式利于维护，结合uni-app可以实现一套代码多端发布。MySQL是关系型数据库，事务支持以及数据一致性保证机制适合于本系统交易场景。这些技术有充足的学习资源和社区支持，开发风险小。因此系统从技术上是可行的。
操作可行性上，系统功能设计来源于校园真实的需要。用户和跑腿用户角色明确，任务发布、接单、沟通、送达等流程符合线下服务逻辑。前端界面使用微信小程序生态进行开发，用户不需要下载额外的应用程序，操作门槛低。管理员后台使用常规的Web管理界面，数据展示及操作方式符合管理习惯。整体交互设计要直观，用户学习成本要低。因此系统在操作上是可行的。
从经济可行性角度而言，系统开发所用到的技术大部分是开源技术，免费工具居多，软件授权费为零。可以选用性价比高的云服务器或者校内服务器，硬件投入少。开发团队是由学生组成的，人力成本主要是学习和时间的投入。系统上线之后会产生服务价值，潜在的打赏、佣金或者广告收入可以覆盖基本的运维开销。就投入产出比来说，项目具备实施的价值。因此系统在经济上是可行的。
系统整体上采用经典的分层架构思想，目的是达到高内聚、低耦合的设计目的。用户界面层分为移动端小程序和PC端管理后台两部分，都是基于Vue.js生态来构建的，小程序端使用uni-app跨端能力进行高效开发。应用服务层以SpringBoot为核心，封装所有的核心业务规则，用设计良好的RESTful API给前端提供数据和服务[14]。数据持久层采用MySQL数据库存储业务实体数据，用MyBatis框架完成对象关系映射，简化数据库操作。系统支持层包含项目构建、开发环境、日志记录、测试、文档等基础支撑组件，保证开发流程的规范化以及系统运行的可观测性。各层之间依靠明确定义的接口来交流，共同支持校园跑腿业务的正常运转。整个系统的架构图如图4-1所示。整个系统架构如图4-1所示。
系统架构图
系统结构功能设计
系统以校园跑腿服务核心业务流程为依托，给管理员、消费者、跑腿骑手三种角色提供不同的功能支持。管理员在后台集中管理任务、订单、沟通、投诉、财务申请等，保证平台的正常运转。消费者作为需求方，主要通过任务大厅发布和管理自己的需求，跟踪订单进度、服务反馈。跑腿用户属于服务供给方，主要做任务承接、执行沟通、收益提现。各个角色的功能相对独立又通过订单流程紧密耦合在一起，形成一个完整的服务闭环。系统功能结构图如图所示。
系统功能结构图
用户进入任务大厅之后，点击发布按钮就进入到表单填写页面。用户输入任务标题、费用、取件和送达地址、时间要求等主要信息，可以上传物品图片。系统会校验表单内容的完整性，不通过会提示用户补充。校验通过之后，任务数据上传至服务器，成功之后用户界面跳转回任务大厅，新发布的任务会显示在列表中。任务发布流程图如图所示。
任务发布流程图
订单接单流程设计
跑腿用户在任务大厅浏览到合适的任务之后，可以查看任务详细要求。用户决定接单就点击接单按钮，系统后台要验证该跑腿用户账户状态是否正常，以及是否已经接单超过限制。验证失败就提示用户原因，验证成功就生成一条接单记录，任务状态改为“已接单”，并向发布该任务的消费用户发送接单通知。订单接单流程图如图所示。
订单接单流程图
订单沟通流程设计
用户或者跑腿用户在订单执行过程中，可以在订单详情页中进入专用的沟通界面。在界面下方的输入框内输入消息的内容，然后点击发送按钮，把消息的内容提交给服务器去储存。服务器会把这条消息实时推送给对话的另一方，对方设备上的沟通界面就会自动刷新并显示这条新的消息，从而实现双向实时交流。订单沟通流程图如图所示。
订单沟通流程图
确认送达流程设计
跑腿用户完成任务之后，在订单详情页上进行确认送达的操作。流程要求跑腿用户上传一张物品已经送达的现场照片，例如物品和门牌号的合影。然后填写一段文字备注，说明送达的情况。系统检查照片和备注都已经提交之后，跑腿用户才可以提交。系统随即生成一条送达信息记录，把相应的订单状态更新为“已完成”，并通知消费用户订单已经送达。确认送达流程图如图所示。
确认送达流程图
投诉反馈流程设计
消费者对已经完成的订单服务不满意时可以提出投诉。用户进入对应订单页面后，选择投诉反馈功能，首先要从预设的投诉类型列表里选择一项，比如送达超时或者物品损坏。用户上传相关的证明图片或者聊天记录截图。最后填写详细的投诉内容描述。系统对提交的内容进行基本的合规性检查后，保存投诉信息，将状态设置为“待审核”，等待管理员处理。投诉反馈流程图如图所示。
投诉反馈流程图
数据库设计
在数据库设计阶段，用ER图将概念模型转化为具体的数据库结构。本阶段任务是对各个数据表的字段类型、约束条件、表与表之间关系进行设计，为后面物理设计做好铺垫。在此基础上再对数据存储方案以及查询性能进行优化。
ER图是数据库概念设计的主要工具，用以表示实体类型、属性特征及实体间的关系[15]。利用图形化的建模方法可以清楚地表示出系统数据的逻辑结构，便于了解各个数据实体之间关系，为数据库的物理实现提供完整的理论基础。下面分别给出系统全局E-R图结构以及主要实体的详细属性构成。系统全局E-R图如图所示。
系统E-R图
消费用户实体主要包括消费用户id、用户姓名、用户电话、审核状态等属性。实体属性图如图所示。
消费用户实体属性图
跑腿用户实体主要包括跑腿用户id、跑腿姓名、跑腿电话、账户余额等属性。实体属性图如图所示。
跑腿用户实体属性图
任务大厅实体主要包括任务大厅id、跑腿标题、取件地址、送达地址等属性。实体属性图如图所示。
任务大厅实体属性图
接单信息实体主要包括接单信息id、跑腿标题、跑腿用户、接单日期等属性。实体属性图如图所示。
接单信息实体属性图
订单沟通实体主要包括订单沟通id、跑腿标题、沟通问题、跑腿回复等属性。实体属性图如图所示。
订单沟通实体属性图
订单延时实体主要包括订单延时id、跑腿标题、延至时间、延时原因等属性。实体属性图如图所示。
订单延时实体属性图
送达信息实体主要包括送达信息id、跑腿标题、送达时间、完成时间等属性。实体属性图如图所示。
送达信息实体属性图
反馈投诉实体主要包括反馈投诉id、跑腿标题、投诉类型、审核状态等属性。实体属性图如图所示。
反馈投诉实体属性图
提现申请实体主要包括提现申请id、跑腿姓名、提现方式、提现金额等属性。实体属性图如图所示。
提现申请实体属性图
跑腿类型实体主要包括跑腿类型id、跑腿类型等属性。实体属性图如图所示。
跑腿类型实体属性图
CREATE TABLE `mission_hall`(mission_hall_id int(11) NOT NULL AUTO_INCREMENT COMMENT '任务大厅ID',
`runs_title` varchar(64) comment '跑腿标题',
`run_errands_no` varchar(64) comment '跑腿编号',
`consumer_user` int(11) DEFAULT 0 comment '消费用户',
`user_name` varchar(64) comment '用户姓名',
`user_phone` varchar(64) comment '用户电话',
`pour_address` varchar(64) comment '取件地址',
`address_for_service` varchar(64) comment '送达地址',
`delivery_time` datetime comment '送达时间',
`type_of_errands` varchar(64) comment '跑腿类型',
`cost_of_running_errands` double(8,2) DEFAULT 0 comment '跑腿费用',
`order_status` varchar(64) comment '订单状态',
`item_specificss` varchar(255) comment '物品详情',
`order_requirements` text comment '订单要求',
`pay_state` varchar(16) DEFAULT '未支付' NOT NULL comment '支付状态',
`pay_type` varchar(16) DEFAULT '' comment '支付类型: 微信、支付宝、网银',
`order_receiving_information_limit_times` int(8) DEFAULT 1 NOT NULL comment '接单限制次数',
`cancel_message_limit_times` int(8) DEFAULT 1 NOT NULL comment '取消限制次数',
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`create_by` int(11) DEFAULT '1' NOT NULL comment '创建用户ID',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
PRIMARY KEY (mission_hall_id))ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 comment '任务大厅';代码参考
@RestController
@RequestMapping("/cancel_message")
public class CancelMessageController extends BaseController<CancelMessage, CancelMessageService> {
/**
* 取消信息对象
*/
@Autowired
public CancelMessageController(CancelMessageService service) {
setService(service);
@Autowired
private JavaMailSender mailSender;
/**
* 发送验证码到邮箱API
*
* @param email
* @return
*/
@GetMapping("send_email")
public Map<String, Object> sendEmail(String email) {
//判断邮箱号是否为空
if (StringUtils.isEmpty(email)) {
return error(30000, "参数错误");
}
try {
//随机生成 6位数的验证码
int code = (int) (Math.floor(Math.random() * 900000) + 100000);
// 创建MimeMessage对象
MimeMessage mimeMessage = mailSender.createMimeMessage();
// 使用MimeMessageHelper辅助类构建邮件
MimeMessageHelper helper = new MimeMessageHelper(mimeMessage, true);
// 设置收件人、发件人、主题和内容
helper.setFrom("3216252476@qq.com"); // 替换为你的QQ邮箱地址
helper.setTo(email);
helper.setSubject("找回密码");
helper.setText("<h1>验证码为："+code+"</h1>", true);
// 发送邮件
mailSender.send(mimeMessage);
Calendar cal = Calendar.getInstance();
cal.add(Calendar.MINUTE,10);
String token = service.encryption(code + "_" + cal.getTime());
SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
Map<String, Object> map = new HashMap<>();
map.put("token",token);
map.put("code",code);
map.put("expire_time",format.format(cal.getTime()));
this.addMap(map);
Map<String, Object> result = new HashMap<>();
result.put("result",1);
result.put("token",token);
return result;
}catch (MessagingException e){
e.printStackTrace();
return error(30000, e.getMessage());
}
}
@GetMapping("verify_email_code")
public Map<String, Object> verifyEmailCode(String token,String code) {
if (StringUtils.isEmpty(token) || StringUtils.isEmpty(code)) {
return error(30000, "参数错误");
}else {
Map<String,String> queryMap = new HashMap<>();
queryMap.put("token",token);
Map<String,String> configMap = new HashMap<>();
configMap.put("like","false");
List resultList = service.selectBaseList(service.select(queryMap, configMap));
if (resultList.size() > 0) {
CodeToken obj = (CodeToken) resultList.get(0);
Date now = new Date();
if (obj.getExpire_time().after(now)){
if (code.equals(obj.getCode())){
return success(1);
}else {
return error(30000, "验证码错误");
}
}else {
return error(30000, "验证码已失效");
}
}else {
return error(30000, "token请求错误");
@PostMapping("/add")
@Transactional
public Map<String, Object> add(HttpServletRequest request) throws IOException {
Map<String,Object> paramMap = service.readBody(request.getReader());
paramMap.entrySet().removeIf(entry -> {
Object value = entry.getValue();
return value instanceof String && ((String) value).isEmpty();
});
CustomerChatLog customer_chat_log = new CustomerChatLog();
customer_chat_log.setCustomer_chat_id(paramMap.get("customer_chat_id")==null?null:String.valueOf(paramMap.get("customer_chat_id")));
customer_chat_log.setContent(paramMap.get("content")==null?null:String.valueOf(paramMap.get("content")));
this.addEntity(customer_chat_log);
System.out.println("在线沟通记录新增成功");
return success(1);
}
@PostMapping("/set")
@Transactional
public Map<String, Object> set(HttpServletRequest request) throws IOException {
Map<String,String> queryMap = service.readQuery(request);
Map<String,String> configMap = service.readConfig(request);
Map<String,Object> paramMap = service.readBody(request.getReader());
paramMap.entrySet().removeIf(entry -> {
Object value = entry.getValue();
return value instanceof String && ((String) value).isEmpty();
});
CustomerChatLog customer_chat_log = new CustomerChatLog();
customer_chat_log.setCustomer_chat_id(paramMap.get("customer_chat_id")==null?null:String.valueOf(paramMap.get("customer_chat_id")));
customer_chat_log.setContent(paramMap.get("content")==null?null:String.valueOf(paramMap.get("content")));
this.setEntity(queryMap,configMap,customer_chat_log);
System.out.println("在线沟通记录修改成功");
return success(1);管理员用该功能对平台全部任务进行管理，并列出所有的用户发布跑腿需求。查询功能可以按关键词、状态等条件筛选任务。重置操作用来清除查询条件，恢复默认视图。
任务大厅管理界面
接单信息管理功能实现
该模块用来管理已经产生的接单记录。管理员可以查询各个订单的接单情况，列表中显示接单者和对应的任务。重置功能刷新数据列表，管理员可以进入详情页查看,接单信息管理界面如图所示。
接单信息管理界面
订单沟通管理功能实现
该功能使管理员可以对用户和跑腿用户之间的交流内容进行监督。系统对所有的订单沟通历史进行记录，管理员可以查询。重置操作初始化查询条件，管理员可以查看任意对话的详细信息。
订单沟通管理界面
订单延时管理功能实现
该模块用来处理用户发起的订单延时申请。管理员可以查询所有的延时申请记录，列表中显示申请的订单和申请的时间。重置功能用来重新加载列表。
订单延时管理界面
送达信息管理功能实现
该功能是对订单完成确认信息进行核对与管理。管理员可以查询所有已经确认送达的记录。重置操作会刷新数据视图，管理员可以进入详情页查看送达时间、完成时间、跑腿用户上传的物品照片和送达备注。对于虚假或者信息不全的送达确认，管理员可以将其删除，保证服务结果的真实性、可追溯性。
送达信息管理界面
反馈投诉管理功能实现
模块集中处理用户提交的各项服务投诉。管理员查询投诉列表，了解投诉对象及投诉类型。重置功能对查询状态进行初始化。管理员查看投诉详情，审核用户上传的证明图片以及内容描述。审核操作是对投诉的处理，管理员可以对投诉进行通过或者不通过的处理，对于通过的投诉还可以进行审核回复。无效投诉可以由管理员直接删除记录。
反馈投诉管理界面
提现申请管理功能实现
该功能实现跑腿用户余额提现的请求。管理员可以查询所有的待处理以及历史的提现申请。重置操作清除筛选条件。
提现申请管理界面
消费者功能实现
消费用户在平台内浏览和发布需求，用户进入大厅之后通过搜索框来查找具体的任务。点击任务卡片可以查看全部要求和发布者信息。用户可以对感兴趣的任务进行点赞或者收藏。发布新任务时，用户填写期望费用、上传物品图片，最后生成新订单。该功能是用户获取和提供服务的入口。
任务大厅交互界面
订单延时申请功能实现
用户在订单执行中如果需要更改收货时间，就使用该功能。首先查询个人名下可以申请延时的订单，查看当前订单详情。选择延时操作之后，用户在时间选择器中选择新的期望送达时间，在文本框中输入具体原因，最后保存并提交申请。该流程给用户提供了对临时变动有灵活应对的能力。
订单延时申请界面
接单信息查看功能实现
用户发布任务之后，使用此模块来跟踪接单状态。用户可以查看自己所有已发布的任务列表，查看是否有跑腿用户接单。用户可以进入详情页，查看已接单任务的跑腿用户姓名、电话等基本信息。订单实际送达后，用户在该页面执行送达确认操作，完成订单闭环。
接单信息查看界面
送达信息查看功能实现
在订单完成之后，用户确认服务成果。用户可以查询所有标记为送达的、与自己有关的订单列表。点击进入详情页，用户可以查看跑腿用户上传的物品送达相片、送达的具体时间、跑腿用户填写的送达备注，作为服务完成的凭证。
送达信息查看界面
订单沟通功能实现
该功能给用户提供了和接单跑腿者直接交流的途径。用户进入个人订单列表，查询需要进行沟通的订单。进入详情页之后，用户就可以看到已经存在的对话历史。用户在输入框中输入想要发送的内容，点击发送按钮，消息就会传给对方，从而实现服务过程中实时协商、解决问题。
订单沟通界面
反馈投诉功能实现
用户对已经完成的订单服务不满意时，可以提出投诉。用户查询可投诉的订单列表，选择具体的订单查看详情。进入投诉操作页面后，用户从预设的投诉类型中选择一项，上传可以证明问题的图片等文件，最后填写详细的投诉内容简介并提交。该功能是用户维护自身权益、反映服务质量的重要途径。
反馈投诉界面
骑手用户功能实现
跑腿用户处理服务执行的关键环节。用户可以查询自己已经接单的订单列表，查看每个订单的详情。任务执行完毕之后，用户点击送达按钮就进入确认操作页面。
接单与送达确认界面
送达信息查询功能实现
跑腿用户可以查询自己所有的已完成订单的送达记录。通过查询功能可以查询到用户以往确认送达的订单列表。用户可以点击详情查看自己当时上传的物品照片、填写过的送达备注和系统记录的送达和完成时间，方便进行服务复盘或者个人记录核对。
送达信息查询界面
订单沟通回复功能实现
该功能使跑腿用户可以响应用户的沟通请求。跑腿用户查询与自己有关的、需要沟通的订单列表，进入详情查看用户发来的消息历史。用户在回复输入框中输入回复的内容，点击提交按钮，回复信息就发送给消费用户，保证服务过程中双向有效沟通。
订单沟通回复界面
反馈投诉查看功能实现
跑腿用户可以查看用户对自己服务的评价和投诉。用户查询与自己有关的反馈投诉列表，了解投诉的大致情况。进入详情页之后，跑腿用户可以查看投诉的具体类型、用户上传的证明文件、详细的投诉内容描述，知晓服务中可能存在的一些问题，从而为改进服务提供依据。
反馈投诉查看界面
跑腿用户需要知道所接的订单是否会有时间变动。用户查询与自己相关的订单延时申请列表，查看有哪些订单被用户申请了延时。用户可以查看用户申请延时的新时间、申请延时的原因等信息，从而合理安排自己的服务计划，及时响应用户需求的变动。
订单延时查看界面
该模块供跑腿用户管理自己的劳动报酬提取。用户可以查询自己曾经提交过的所有提现申请记录，了解申请状态。重置操作是对申请列表进行刷新。用户进入添加操作页面，选择提现方式、输入对应银行卡号、填写期望提现金额、填写必要的备注后提交申请，等待平台审核打款。
提现申请管理界面
源码获取
私信联系我即可~
大家点赞、收藏、关注、评论啦
精彩专栏推荐订阅：在下方专栏👇🏻
👇🏻 精彩专栏 推荐订阅👇🏻
uniapp/微信小程序/安卓app精品实战案例【2000套】
感兴趣的可以先收藏起来，还有大家在毕设选题，项目以及论文编写等相关问题都可以找我咨询，希望帮助更多的人❤️
扫一扫
209
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
