- 一、系统模块分析
- a) 普通用户
- b) 管理员
- 二、UML建模示例
- 1、航班管理系统UML类图表示
- 2、航班管理系统UML用例图表示
- 3、航班管理系统UML时序图表示
- 三、设计模式分析
- 1、设计模式1：
这一部分主要针对提出的方案进行简要的分析。包括：订票系统的使用对象，以及这些对象分别可以实现的操作。这里不同的对象群体可以进行不同的操作，两者操作互不影响，但是信息可能有交叉。
在该系统中，将对象分为了普通用户和航班公司管理员两大类。
用户需要实现的操作有：
- 信息注册与登录 ，每一个用户都有唯一的信息身份与之匹配，保证订票时信息互不冲突，这里并不打算实现以游客登录的方式进入订票系统；
- 航班信息查询，主要包括用户查询对应的机票信息，查询方式有按时间查询，按出发到达城市查询等；
- 订票 ，查询到对应的航班后，用户可以确认订单，这里在订单进行过程中仅限用户进行一次订票，且仅有一次退票和改签的机会；
- 个人信息查询与修改，这里用户可以修改自己的信息，并且可以查询自己的订单信息。
管理员需要实现的操作有：
- 信息登录 ，相对于用户，管理员只是很少一部分群体，而且管理员是系统指定的部分群体，实现对航班信息的维护和管理，管理员有专用的密码，有固定的管理员号码，没有注册和游客登录功能；
- 航班信息设置，管理员需要设置航班的航班号，开始和结束的城市，起飞时间，历经时长以及票数；
- 航班管理 ，用户提交订单、退票和改签时，需要管理员及时与用户反馈。
依据上述分析，该系统中分为用户和管理员两大类。其中用户类中描述的对象有：注册、登录、订票、查询、改签、退票、信息修改。用户类图表示如下图所示。
管理员类有：登录、航班管理、航班信息管理。管理员类图如下所示：
根据实际情形分析，该系统共分为三个层次。首先是系统的顶层管理。顶层管理将整个系统分为了管理员和用户两大类。顶层系统控制着整个航班管理系统的正常运行，其用例图如下：
顶层将系统分为了用户和管理员两大类。其中管理员需要执行操作时必须登录系统，否则默认为用户执行。管理员用例图如下：
用户在查询航班信息时可以以游客身份登录，但是在执行其他操作（如订票功能）必须登录信息，如果查询不到用户信息，必须注册，否则无法执行。用户的用例图如下：
UML时序图是通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。它可以表示用例的行为顺序，当执行一个用例行为时，其中的每条消息对应一个类操作或状态机中引起转换的触发事件。
在本例中，主要分析了以下事件的时序图：
- 管理员添加航班信息 ：
- 用户注册功能：
- 管理员或用户修改个人信息 ：
- 用户退票功能 ：
