民宿管理系统的设计与实现

其他项目，点击作者主页

目录

1 系统简介

2 系统相关技术

2.1 Java技术

2.2 SSM框架

2.3 MySQL数据库

3 需求分析

3.1 系统介绍

3.1.1 系统概述

3.1.2 系统面向的用户群体

3.1.3 系统范围

3.1.4 系统中的角色

3.2 可行性分析

3.2.1 技术可行性

3.2.2 经济可行性

3.2.3 操作可行性

3.3 系统功能需求

3.4 系统用例

3.4.1 系统用例图

3.4.2 用例规约

4 系统设计

4.1 系统架构设计

4.2 系统时序分析

4.2.1 动态管理

4.2.2 房间管理

4.2.3 订单管理

4.2.4 用户管理

4.2.5 数据统计

4.2.6 房间预订

4.3 系统数据库设计

4.3.1 概念结构设计

4.3.2 逻辑结构设计

5 系统实现

5.1 运行环境

5.2 系统模块汇总

5.3 用户功能的实现

5.3.1 民宿动态

5.3.2 房间查询

5.3.3 房间详情

5.3.4 预订房间

5.3.5 我的订单

5.4 管理员功能的实现

5.4.1 订单管理

5.4.2 管理员管理

5.4.3 用户信息管理

5.4.4 房间信息管理

5.4.5 民宿动态管理

5.4.6 统计

6 总结

1 系统简介

本系统对民宿管理进行了设计与实现。系统分为用户预订端和后台管理端。用户模块的功能以查询并预订房间为核心，再加上登录注册以及收藏、浏览公告等功能。管理者模块主要功能有管理员管理、用户管理、房间管理、民宿动态管理、日志管理，以及统计等功能。

本民宿管理系统设计与实现是基于B/S架构的，采用Java语言和JSP语言来开发，使用了SSM框架，用MySQL数据库来存储数据。本系统还存在一些不足之处，功能还需进一步丰富。但基本能够满足民宿管理的需求，同时降低了耦合度，便于后期维护。

2 系统相关技术

2.1 Java技术

多年以来，Java一直都是深受业内人士喜爱的编程语言。它具有面向对象的特点，让人们免去一些繁琐且无意义的工作，节省开发人的时间和精力。

Java是Web服务端目前使用最为广泛的编程语言之一。它将现实中的一些信息的特点和过程进行抽取，通过继承的结构将对象联系起来，使得开发代码的时候只需要关注对象本身的属性和方法，简化开发。

2.2 SSM框架

SSM框架是Java的一个常用框架，它的每个部分的职责互不干扰。它将代码分层，使模块解耦，也使得代码更加方便开发。

使用SSM框架后，无需再频繁手动创建对象，而是把这些都交给框架容器去处理，简化开发过程。框架中集成了多种功能模块，致力于Java EE编程领域各层的解决方案。

2.3 MySQL数据库

MySQL是一个关系型数据库管理系统。它所创建的表可以分别存储信息并且相互关联，从而降低了每张表的大小，使得数据的存储更加灵活、对数据的操作速度更快。

由于它是关系型的表存储方式，可以在有必要的时候重新创建一张表，将这张表与已存在的表关联起来，充分发挥扩展性强的特点。另外，该数据库在存储数据的时候会将本地数据文件加密，使数据安全存储。

3 需求分析

3.1 系统介绍

3.1.1 系统概述

本系统以预订房间和管理民宿信息为核心，目的在于帮助管理者科学规范且高效地管理民宿，节省人力物力、提高效益。

为了能够帮助管理，系统具有这些特点：系统界面色彩柔和、布局合理；有合理的权限分配以及数据的保护机制，确保数据准确安全；能够直观地、准确地反映民宿资源和收入等数据，方便管理者了解民宿经营情况，作出合适的规划。

3.1.2 系统面向的用户群体

系统一般是由顾客和管理者使用的。

顾客（普通用户）：即需要租住民宿房间的顾客，他们能够通过预订系统预订房间，进行相关操作。

管理者：包括民宿房东和民宿工作的管理员。他们通过系统管理民宿资源和信息，管理房间和处理订单等。

3.1.3 系统范围

系统基于B/S，使所有使用者都能够在连接网络的设备上通过网页使用系统功能，最大程度达到数据共享，满足系统用户需求。

基于Web的民宿管理系统分为前台和后台系统。开发的民宿管理系统面向的是民宿的工作人员和客户，其功能包括前台用户的登录注册、查询房间、房间预订、收藏房间以及订单管理等信息的处理，包括管理员对房间、订单和日志以及可视化统计等功能模块的管理，能够满足民宿管理者和顾客对系统的使用和需要。

3.1.4 系统中的角色

经过分析，从本民宿管理系统中提取出三种角色，分别是用户、房东、管理员。本系统的角色和其职责如表3-1所示。

表3-1 角色及其职责表

3.2 可行性分析

3.2.1 技术可行性

通过分析以上的系统需求，进而对技术进行分析。首先需要使用数据库存储各种数据，包括用户数据、房间信息、订单信息等。其次，需要使用到前后端交互技术，包括SSM框架以及HTML、CSS和JavaScript三大技术。这些技术条件基本都可以达到，技术可行性是没有问题的。

3.2.2 经济可行性

经过分析，本次开发系统需要使用的一些工具基本是开源的，而且由于系统本身不算大，对设备的配置没有很高的要求，日常使用的计算机就可以完成系统的开发和运行。因此，从经济方面考虑，没有问题。

3.2.3 操作可行性

由于系统的特点，在操作方面不会繁琐。在使用系统时，不需要进行复杂的操作，根据引导输入相关信息即可，其他的逻辑处理由系统本身完成。而且，目标客户都有一定的智能设备的使用经验，能够轻松地使用系统。

3.3 系统功能需求

在对本系统进行了业务逻辑分析后，明确了本系统分为用户预订端和后台管理端的设计。

用户端模块：由客户使用。用户模块的功能以查询并预订房间为核心，再加上登录注册以及收藏、浏览公告等功能。功能详情如下。

(1) 系统注册和登录：在正式使用本系统时需要登录才能进行租房操作。登录或注册需要查询数据库验证是否合法，并给出提示信息。此模块包含忘记密码功能。

(2) 房间查询：用户可以浏览和通过筛选条件查询房间信息，在登录后可以进行预订和收藏房间等操作。

(3) 预订：用户在登录后可以在房间详情页预订房间，预订时需填写个人信息、选择预订日期。

(4) 订单管理：可以取消订单或结算付款。取消订单不影响同一房间资源同一日期的再次预订；付款成功可以到线下办理入住。

(5) 个人信息：用户可以在这里改个人信息。

(6) 民宿动态信息：用户可以了解民宿动态，合理规划行程和住宿。

(7) 我的收藏：用户在登录后可以收藏喜欢的房间，在我的收藏页面可以看到已收藏的房间。

后台管理端模块：由管理者使用，其中，管理者包括房东和管理员，两者的功能职责稍有区别，房东拥有最高权限。管理者登录后主要功能有管理员管理，用户管理，房间管理，民宿动态管理，日志管理，以及统计功能。

(1) 登录：管理员使用系统时需要登录。管理员账户由房东（老板）添加。

(2) 管理员信息：房东可以管理自己和低级别管理员的信息，此功能只对房东开放。

(3) 用户信息管理：管理员可以管理顾客的账号，仅限于查看不敏感数据和删除功能。

(4) 订单管理：展示和操作订单信息。

(5) 房间管理：管理者在这里管理房间资源信息。

(6) 动态管理：管理公告等动态信息，用户端可以查看到这些动态信息。

(7) 日志管理：主要为登录日志，日志在用户登录时自动添加。此处提供删除按钮。

(8) 统计：对民宿经营信息进行统计。主要是两方面的统计：房源信息统计和收入情况统计。房源统计包括不同房型的数量、面积等统计；收入统计包括不同时期、不同房型的收入情况的展示。

根据分析，可以确定系统的功能模块信息，如图3-1所示。

图3-1 系统功能模块图

3.4 系统用例

3.4.1 系统用例图

通过系统用例分析，外部参与者可以看到系统的功能。在分析之后，明确了系统包含前台和后台，前台主要包括搜索并预订房间等，后台管理模块主要是对民宿信息的管理，包括房间的管理、用户管理以及统计等。系统的总用例图如图所示。

图3-2 总用例图

管理者包括房东和管理员，登录后可以管理用户、房间、动态、订单和日志，可以查看统计信息。其中房东另外有对管理员操作的功能。管理者用例图包括房东和管理员的用例，如图3-3所示。

图3-3 管理者用例图

用户可以查看网站信息，包括查询房间、预订房间、民宿动态、注册登录、个人资料、我的订单、收藏。用户用例图如图3-4所示。

图3-4 用户用例图

3.4.2 用例规约

房间添加用例规约如表3-2所示。

表3-2 房间添加用例规约

房间预订用例规约如表3-3所示。

表3-3 房间预订用例规约

4 系统设计

4.1 系统架构设计

该系统采用B/S架构和SSM框架，主要分为四个层次：视图层、控制层、服务层、数据持久层[15]。系统架构图如图4-1所示。

图4-1 系统架构图

视图层：视图层用来显示本系统的界面以及与控制层数据交互。采用了Bootstrap和ECharts等一些框架和插件。

控制层：用来接收页面提交的数据，自动封装，并发送给服务层。

服务层：接收传来的数据，在进行业务处理后，调用数据持久层对数据库进行查看或修改等操作。

数据持久层：将传来的数据保存到本地库中，或者用来查询相关内容。

其他服务组件：为系统的运行提供基础条件。

以上各层组成了完整的整体，保证了系统的运行。

4.2 系统时序分析

4.2.1 动态管理

此处以添加动态为例。系统引入了编辑器插件，功能丰富。管理者在编辑内容时，如果有附件信息，自动上传附件，在提交后会把相关信息录入数据库，最终把操作结果返回到页面。

动态的添加可以用时序图来描述，如图4-2所示。

图4-2 动态添加时序图

4.2.2 房间管理

这里以添加房间功能为例进行描述。对于民宿管理系统来说，房间信息的添加是基本功能，帮助管理者在系统中录入新的房间信息。

房间添加的时序图如图4-3所示。

图4-3 添加房间时序图

4.2.3 订单管理

订单管理包括办理入住和取消等功能。用户在预订房间后管理员这里才会有订单生成。此处以订单的展示为例。调用订单管理功能时，系统会先向数据库查询订单数据，然后将数据展示在浏览器。

订单展示的时序图如图4-4所示。

图4-4 订单展示时序图

4.2.4 用户管理

房东能够对管理员和用户进行管理，能够更改管理员的信息，对于用户只有查看和删除权限。

这里以删除用户信息为例。页面会列出所有的用户。在删除用户时，将对应的编号传入后台，然后执行删除语句。

删除用户的时序图如图4-5所示。

图4-5 删除用户时序图

4.2.5 数据统计

适当的统计能够帮助管理者清晰明了地掌握民宿的经营信息，以此为依据对民宿的经营管理做出合适的调整。本系统的统计包括对房型和收入的统计。这里以收入统计为例。主要就是向数据库查询相关信息进行数据处理，随后将处理过的数据以图表形式展示。

收入统计的时序图如图4-6所示。

图4-6 收入统计时序图

4.2.6 房间预订

用户在前端可以预订房间，预订时进行账号验证。登录后才可以进行预订。预订房间时需要填写完整的正确的信息才能预订成功。

房间预订的时序图如图4-7所示。

图4-7 房间预订时序图

4.3 系统数据库设计

数据库对于信息系统来说有重大意义，想要完成一个优秀的项目首先要设计好数据库。数据库是系统的根本，系统的重要数据几乎都在其中存储。一个好的数据库能够使系统性能优越，也能使数据的安全得到保障。

4.3.1 概念结构设计

数据库概念模型可以将现实存在的一些数据抽象到数据库，从而做到信息世界的建模。本文采用E-R模型法来设计。

根据系统的功能模块划分，抽象出实体大概有七类，分别是管理员类、用户类、房间类、日志类、动态类、收藏类、订单类。整体的E-R图如图4-8所示。

图4-8 整体E-R图

详细分析了本系统中大部分的实体，本系统的各基本实体属性图如下。

(1) 管理员具体有六个属性。分别是编号、电话、类型、姓名、密码和用户名。

管理员实体属性图如图4-9所示。

图4-9 管理员实体属性图

(2) 收藏实体具有这些属性：编号、房间id和用户id。

收藏实体属性图如图4-10所示。

图4-10 收藏实体属性图

(3) 民宿动态实体具有这些属性：编号、名称、描述、操作时间。

民宿动态实体属性图如图4-11所示。

图4-11 民宿动态实体属性图

(4) 房屋实体具有这些属性：编号、房间编号、名称、添加时间、图片、租金、室型、朝向、户型、面积、出租类型、区域、地址、房主名字、电话、标签和状态。

房屋实体属性图如图4-12所示。

图4-12 房屋实体属性图

(5) 订单实体具有这些属性：编号、用户编号、房间编号、租金、描述、下单时间、附件、状态、开始时间、租住天数、结束时间、姓名、身份证号、电话和房间id。

订单实体属性图如图4-13所示。

图4-13 订单实体属性图

(6) 用户实体具体是这些属性：编号、姓名、用户名、密码等。

用户实体属性图如图4-14所示。

图4-14 用户实体属性图

(7) 日志实体具有这些属性：编号、用户名、信息以及操作时间。

日志实体属性图如图4-15所示。

图4-15 日志实体属性图

4.3.2 逻辑结构设计

根据对数据库结构的分析，联系集及其属性可定义为以下形式：

(1) 管理联系集：管理员同用户、房间、订单、公告、日志存在一对多联系集，表明管理者可能够操作多个房间、订单、公告、用户、日志的信息。用户跟日志存在一对多联系集，用户可以有多个日志信息。

(2) 收藏联系集：用户和房间之间存在多对多的联系集，表明一个用户可以收藏多个房间，而一个房间可以被多个用户收藏。

(3) 预订联系集：用户同房间之间是一对多联系集，因此对用户能够租下的房屋数量没有要求。

5 系统实现

5.1 运行环境

本民宿管理系统在服务器上运行，在浏览器上访问页面，具体运行环境如下。

操作系统：Windows 10家庭版

开发工具包：MySQL驱动、jQuery、Bootstrap、ECharts以及一些其他Maven的依赖等

数据库：MySQL 8.0

开发软件：IntelliJ IDEA 2021.2

服务器：Tomcat

5.2 系统模块汇总

本民宿管理系统分为用户端和后台管理端，系统的模块汇总表如表5-1和表5-2所示。

其中表5-1是用户预订子系统的模块汇总，包含了用户可以操作的功能。

表5-1 用户预订模块表

表5-2是后台管理子系统的模块汇总，管理员用该子系统来管理民宿。

表5-2 后台管理模块表

5.3 用户功能的实现

用户可以浏览网站页面，包括找房、预订、查看公告等。其主页如图5-1所示。

图5-1 网站主页图

5.3.1 民宿动态

民宿动态会展示管理员发布的动态信息，如公告。用户可以点击民宿动态查看民宿动态信息，用以规划住宿行程。如果有动态信息，会显示动态；如果没有动态数据，友好提示用户。另外，点击链接会跳转页面浏览具体内容。

(1) 本模块的具体设计

本模块需要后台向数据库查询动态信息，需要用到share民宿动态表。

此模块的功能操作较为简单。用户点击查看民宿动态后，浏览器向控制层发送请求，随之后台向数据库查询数据，最终查询到的结果原路返回到浏览器。如果查询到动态信息，浏览器将数据列表显示在界面，用户此时可以点击动态列表来查看详情。如果查不到数据，提示用户没有信息。

民宿动态的功能流程图如图5-2所示。

图5-2 民宿动态功能流程图

(2) 其运行界面如图5-3所示。

5-3 民宿动态界面

5.3.2 房间查询

房间查询页面可以向用户展现系统的房间资源。用户可以输入条件进行包括模糊查询在内的多条件查询，并且用户选择的条件会在查询后仍然显示在页面，避免每次重输。在房间列表上显示房间面积、价格等信息，方便用户初步了解房间，进行筛选。

(1) 具体设计

用户第一次进入页面时，查询条件为空，将会列出所有房间供用户浏览。输入信息后，会根据输入或选择的内容向数据库综合查询。最终将查询的结果展示给用户。

本模块需要向数据库查询房间的信息，用到的数据表有：house房间表。

功能流程图如图5-4所示。

图5-4 房间查询流程图

(2) 其界面如图5-5所示。

图5-5 房间查询界面

5.3.3 房间详情

房屋详情界面用来帮助用户尽可能地了解房间的信息。其中，图片能够直观地反映房间情况，还有房型和面积等基本信息也必不可少。另外，在详情页面，提供了收藏和预订入口，用户可以进行收藏、预订操作。

(1) 具体设计

本模块需要向数据库查询房间的详细信息和收藏情况，用到的数据表有：house房间表、shoucang收藏表。

本模块的功能流程是这样的。用户在浏览房间时点击某一房间，浏览器将该房间的id传入后台，后台根据此id向数据库查询房间的详细信息，如果已登录，同时查询该用户是否收藏该房间，然后将数据返回给浏览器，浏览器跳转到房间详情页面展示。如果用户已经登录并且收藏了此房间，右上角会显示“已收藏”，反之显示“收藏”两个字。本模块的功能流程图如图5-6所示。

图5-6 房屋详情功能流程图

(2) 其界面如图5-7所示。

图5-7 房屋详情界面

5.3.4 预订房间

在下单页面会展示房间的部分信息，但不可修改。用户需要选择租住时间，已过日期不可选择，房间已被预订的期间不可选择，并且结束日期需在开始日期之后。另外，必须填写自己相关信息才可下单。

(1) 模块具体设计

本模块首先需要查询房间信息，然后将订单写入数据库，因此用到house房间表和torder订单表。

用户在房间详情页点击预订会进行登录验证，没有登录会跳转登录页面，登录后才可以下单，下单页面会根据该房间的id展示房间的关键信息。用户在下单页面点击日历选择合适的日期，填写所必须的内容后可以下单。后台创建订单，将相关数据存储并返回提示信息。然后在我的订单里面，可以支付或取消订单。

功能流程图如图5-8所示。

图5-8 预订功能流程图

(2) 其界面如图5-9所示。

图5-9 预订界面

5.3.5 我的订单

此页面展示用户的订单信息，其中租金是根据单价和租住天数计算出的最终价格。另外，根据订单状态提供不同的功能操作，例如支付、取消功能。用户也可以在这里点击房间链接跳转到房间详情页。

用户点击支付或取消都会向后台发出请求，改变数据库数据，然后会刷新此页面。

此模块涉及的数据表为torder订单表。

其界面如图5-10所示。

图5-10 我的订单界面

5.4 管理员功能的实现

5.4.1 订单管理

订单管理界面分页展示每个订单的信息，包括租客的信息、房间信息等。同时会根据订单状态有选择地提供入住、退房和删除等操作按钮，管理者可以进行相关操作改变订单状态。

(1) 模块具体设计

此模块涉及torder订单表。

管理者进入订单页，后台向数据库按页码查询数据，显示在页面上。与此同时，系统判断订单状态，提供相应功能：如果订单未支付，显示取消和删除按钮；如果订单状态是已支付，显示删除、入住和取消按钮；如果订单状态是已入住，显示删除和退房按钮；如果是已退房，提供删除按钮。

订单管理的功能流程图如图5-11所示。

图5-11 订单管理功能流程图

(2) 其界面如图5-12所示。

图5-12 订单管理界面

5.4.2 管理员管理

此功能不对一般管理员开放。仅房东（老板）可以有管理员管理功能。系统会根据登录账号的权限提供不同的功能。页面不显示账号的密码，房东可以添加、修改和删除管理员，可以编辑自己的信息，但不允许编辑、删除与自己权限相同的账户。

此功能需要查询管理员账户，用到管理员表。

其界面如图5-13所示。

图5-13 管理员管理界面

5.4.3 用户信息管理

此页面分页显示普通用户的账号信息，但不涉及个人敏感信息。此处只提供查看和删除功能。在对业务功能及其性质的分析后，确定此处不支持对普通用户的添加和编辑，仅能用户自行注册账户和修改信息。

此模块会向用户表查询信息进行展示，因此要用到用户user表。

其界面如图5-14所示。

图5-14 用户信息管理界面

5.4.4 房间信息管理

此模块用于管理房间。在添加房间时需填写房间名称、地址、租金和房东等基本信息。也需要上传房间展示图片，图片会被上传保存防止丢失。查询和删改管理时，系统都会根据房间id进行操作，确保数据的正确性。

此模块可对房间表进行增删改查操作，因此本模块需要用到house房间表。

本小节的功能流程以添加房间为例。管理者在页面调用添加功能，会在页面中间出现添加窗口。管理者在此窗口填写房间的信息，信息需填写完整，同时上传房间图片。若未完整填写信息，弹出提示框。待信息校验合法后，将房间信息添加到数据库，返回处理结果。

房间添加功能流程图如图5-15所示。

图5-15 房间添加功能流程图

房间添加的运行界面如图5-16所示。

图5-16 房屋添加界面

5.4.5 民宿动态管理

此模块提供民宿动态的添加、查看和删改功能。其中，添加和编辑功能用到了百度的编辑器插件，管理者使用该编辑器编辑内容的同时，可以对内容的样式进行编辑，包括图片和文本的编辑。向后台提交数据时会把HTML标签和内容一同发送，数据库把这些数据作为一个字符串一并保存。这样也方便了页面的展示。

此模块涉及动态的增删改查，需要用到share民宿动态表。

其管理界面如图5-17所示。

图5-17 民宿动态管理界面

5.4.6 统计

管理员可以对房源、收入进行统计，房源统计包括不同房型的数量、面积等统计；收入统计包括不同月份、不同房型的收入情况的展示。

(1) 对于房型的统计涉及两方面的内容：房型的数量、面积和价格。

其中房型的数量统计采用环形图展示，在环形图中，不同的房型用不同的颜色表示。通过环形图中不同色彩的百分比，可以清晰的了解房型的数量比重，将鼠标放在图上可以查看该房型的数量。房型数量统计如图5-18所示。

图5-18 房型数量统计图

关于不同房型的面积和价格统计展示在同一折线统计图上。系统首先查出所有房间的面积和价格信息，根据房型分组统计，最终将整理好的数据展示在浏览器页面。使用折线图的优点在于能够根据房型的变化，直观地反映出面积和价格的变化趋势。其统计图如图5-19所示。

图5-19 面积和价格统计图

(2) 收入统计对于民宿管理者来说尤为重要，管理者可以根据这些便捷地掌握民宿经营情况，据此作出合理的规划。在这里，主要针对不同房型和日期做出统计。

关于收入统计，主要向管理者展示不同房型和日期的订单数和营业额。

收入统计主要采用柱形图来展示数据，方便管理者对于营业信息有一个直观的了解。其中特别的是，对于每个月份的营业额，采用折线图的统计方式，帮助管理者掌握不同月份的收入升降趋势。其统计图如图5-20所示。

图5-20 收入统计图

统计模块需要向数据库查询房型、面积、价格、订单数和收入等信息，因此需要用到house房间表和torder订单表。

6 总结

随着信息时代的发展和人们对高质量生活的追求，有更多的人喜欢上个性化的民宿，民宿经营的信息化已经成为了趋势和潮流。本系统是一个基于B/S架构的民宿管理系统，实现了浏览器页面和后台服务器端的开发。系统使用了SSM框架和MySQL数据库等技术，较大程度上降低了各模块的耦合度，以便于后期维护和升级。

源码+过程性文档+论文