UML旅游管理系统「建议收藏」

大家好，又见面了，我是你们的朋友全栈君。

一、需求概述

1.1项目概述

随着人们的生活质量的逐步提高，外出旅游成为人们生活中不可或缺的一项活动。开发一个旅游管理系统可以为大家提供便捷的途径。系统管理员可以发布和管理旅行路线。旅客可以查询路线，预定路线。

1.2用户需求分析

分析的系统的参与者有系统管理员、会员、普通用户三个群体。分别对三个群体的需求进行具体分析。

系统管理员：管理员作为系统的管理者。需要对线路的数据库进行管理。比如发布新的线路，对不需要的线路进行删除、修改线路的具体信息。对于已经发布的线路，系统管理员可以查看预定的情况。同时，由于旅游的各项流程通常需要实名化，所以该系统不能用虚拟身份预定，因而管理员需要对用户提交的注册信息进行审核。

普通用户：普通用户进入网站首页并没有抱着一定要预定线路的想法，所以他们的需求是可以比较方便的查看线路信息，所以系统的线路要通过类型进行分类，方便用户查看。若是有看中的线路想要进行预定，则需要进行实名注册等待管理员核实身份后方可进行预定。

会员：已经通过实名认证的用户可以通过网站进行查看线路、预定线路。因为线路的人数约束、出行日期等各种因素，所以在会员提交预订申请后需要系统根据数据库里的线路信息进行计算，满足才可以生成订单。会员可以在线查看本人订单的状态。并且在一定的时间范围内，会员可以对订单进行取消。在出行完成后，用户还可以根据自己体验到的服务对订单进行评价，发布自己的感受给别的用户提供参考。

1.3数据库

管理员列表：管理员名称、管理员编号（主键）、管理员密码

会员列表：会员名称、会员编号（主键）、会员密码、订单编号（外键）

订单列表：订单编号（主键）、价格、线路编号（外键）、会员编号（外键）、人数、日期

线路信息：线路编号（主键）、价格、人数限制、出行日期等

二、用例图建模

2.1普通用户用例

用例概述：普通用户进入网站后，可以在网站上按照给定的线路类型进行线路查看。若是想要预定线路，则需要填写真实的身份信息进行注册，等到系统管理员审核通过后才可以成为会员，进行线路的预定。用例图如下：

图1 普通用户用例图

2.2会员用例

   用例概述：会员通过身份验证进行登录后可以进行线路的预订。会员先按照线路类型找到想要预定的线路，接着填写人数等具体的预定信息进行提交，系统对收到的信息进行计算，若是相关条件不满足则结束预定。条件满足则生成出行订单，会员进行付款。在成行前48小时内，用户可以取消订单。进行旅行后用户还可对订单进行评价。用例图如下：

图2  会员用例图

会员进行订单预订的活动顺序是：

（1）进入主页面。

（2）选择喜欢的线路类型，比如国内游、出国游等等。

（3）点击相关线路可以查看路线详情。

（4）选择好了之后可以填写预定信息，提交申请。

（5）系统计算是否可以通过申请。

（6）用户进行支付，没有在48小时内支付则订单自动取消。

（7）用户在成行48小时前取消订单则系统删除订单并进行退款。

（8）用户出行。

（9）出行完成后会员可以对订单进行评价。

由此可以到预订线路的活动图如下：

图3  预订活动图

2.3系统管理员用例

   用例概述：管理员需要先通过身份验证进行登录。登录成功后，管理员可以对系统中发布的线路进行修改、删除、增加。还可以查看线路的预订信息，对收到的注册申请进行审核。用例图如下：

图4 系统管理员用例图

三、静态结构建模

首先要确定旅游管理系统中的类。有系统管理员类、普通用户类、会员类、线路类和订单类。

系统管理员要登录系统需要用户名name和密码password。需要的方法有发布线路、删除线路、查看预定信息、批准用户注册。

会员进行登录也需要用户名name和密码password。需要的功能函数有查看线路、预定线路、付款、订单评价。

普通用户则不需要这些属性，只需要查看线路的方法和注册的方法。

线路需要价格price属性、人数people number属性、日期date属性。由管理员进行线路的增加删除修改等操作。

用户所下的订单需要记录用户名、人数、出行日期、价格等。订单可以有用户取消。

根据这些属性和需要实现的功能，可以得到系统的类图模型。类图模型如下：

图5  系统类图

四、动态行为建模

4.1顺序图

4.1.1会员进行线路预订的工作流程：

（1）会员进入旅游系统的主页面。选定需要的线路类型，进行线路的预览挑选。

（2）选定线路后可以进入线路的详情页进行进一步的了解。

（3）了解完全后若是决定进行预定，则填写预定需要的信息，比如人数、日期等，填写完成后提交预定申请给系统。

（4）系统对所提交的预定信息进行计算，看看相关条件是否满足。计算得到不满足则结束预定，返回路线详情页并提醒会员预定失败。系统计算得到相关条件满足则对信息进行整合生成订单。

（5）订单生成成功的话则跳转到支付页面，提醒用户进行支付。

（6）用户进行支付，支付成功地话则跳转到支付成功界面，显示支付成功。

（7）提示用户预定成功，返回路线详情页。

根据这个工作流程可以画出线路预订的顺序图，顺序图如下：

图6  线路预订顺序图

4.1.2添加线路顺序图

管理员添加线路的工作流程。

（1）进入系统主页面。

（2）管理员填写用户名和密码。

（3）系统进行登录信息的检验。

（4）登陆成功则转到管理界面。

（5）找到添加线路的功能，填写新增线路的信息。

（6）新添加的线路可以更新保存在数据库中。

（7）操作完成后显示操作成功信息。

根据这个工作流程可以画出管理员添加线路的顺序图，顺序图如下：

图7  添加线路顺序图

4.2订单状态机图

订单包含的状态有：生成中、生成成功、生成失败、代付款、待出行、已取消、已完成几种状态。

（1）生成中与生成成功之间的转换条件是系统计算得的结果是否满足。

（2）代付款与待出行、已取消之间的转换条件是是否在48小时内付款。

（3）待出行与待评价、已取消之间的转换条件是是否在成行前48小时内取消了预订订单。

由此可以订单的状态机图如下：

图8 订单状态机图

五、实现方式建模

5.1组件图

在旅游预订系统中,可以对系统得主要参与者与主要业务实体类分别创建对应得构件并进行映射。之前在类图中创建了系统管理员类、会员类、订单类,线路类与控制类,所以映射出相同得构件,包含系统管理员构件,会员构件、订单构件、线路构件与业务逻辑构件。除此之外,还必须有一个主程序构件。根据这些构件及其关系创建得构件图如下图所示。

其中需要注意的是必须有控制组件，因为线路各方面的限制，所以不是每一个预订都可以编程订单，必须结合线路的具体情况进行控制。

图9  组件图

5.2部署建模

系统的部署图描绘得就是系统节点上运行资源的安排。在这个旅游预定系统中,系统包含三种节点,分别就是:主页面浏览器节点,普通用户和会员通过浏览器可进行查询与预定操作,管理员也通过此节点进行线路的管理和预定信息的查看。系统服务器节点,用于处理系统得业务逻辑;数据库节点,由一台数据库服务器负责数据得存储、更新、处理等。旅游预定系统得部署图如下图所示。

图10  部署图

总结

在这次实验中，我对需求建模的各个阶段有了更为深入全面的了解。也对其中所用到的用例图、活动图、顺序图等图的功能和绘制过程掌握的更加熟练。

一般来讲，需求分析都要先确定系统的主要参与者，然后再对各个群体的需求进行具体的分析，建立一个合适的数据库，其中包含用户和业务实体。之后通过分析得到的用户所需的具体功能要求对系统进行建模，使用多种侧重点不同的图对系统进行全面的规划，进而使得系统的实现人员可以清楚地理解用户的需求。通过这样的流程，可以在系统用户与设计者之间架设一个沟通的桥梁，避免因为沟通不当造成的各种资源的浪费。可见，系统的UML建模十分重要。