企业官网建设流程全解析

简介：针对航空订票系统的UML建模设计PDF文档，面向软件工程学习者与UML初学者，完整演示如何用用例图、类图、包图、顺序图、协作图、状态图、活动图、组件图和部署图，将业务需求转化为规范的系统模型。文档以订票业务为主线，覆盖新用户注册、登录验证、航班查询、机票预订与退票等核心功能，并展示用户、管理员和外部信用评价系统之间的角色权限与依赖关系，便于理解各图之间在实际项目中的协同作用。不仅适合作为《UML建模设计》课程作业或毕业设计参考，也能帮助开发人员快速梳理系统结构、识别类与交互关系、编写规范设计文档。资源封装为单个PDF文件，压缩包大小2.04MB，内容紧凑完整，便于离线阅读与打印。目前已有1958人学习下载，适合需要借助实例快速掌握UML实际项目建模的开发者与高校学生。

1. 为什么值得下载这份 UML 建模设计：一门课设的完整建模顺序

如果你正在做 UML 课程设计，手头最缺的往往不是“会用 Rose”的技能，而是一套能照着重绘的完整图集。这份《UML 建模设计航空订票系统》恰恰把九类 UML 图一次画全了：用例图、类图、包图、顺序图、协作图、状态图、活动图、组件图、部署图，而且全部围绕同一个航空订票系统展开。换句话说，它不是零散的图例，而是一条从需求捕获到物理部署的完整建模链路。适合三类人：准备交 UML 课设的学生，想快速搭一套“用例＋类图＋交互图”演示模型的从业者，以及准备相关认证考试、需要图型对照复习的人。我先说一个反直觉的结论：这份资料真正值钱的不是某一图画得多标准，而是它让你看到九张图在同一系统上如何彼此咬合。下文所有步骤我都按这份文档的原始结构拆开讲，并把我自己画图时的习惯补进去。

2. 从用例到状态：先把系统边界和权限规则画清楚

2.1 用例图：三个角色、两处 include、一个 extend

文档里的用例图把角色分成三类：已登录用户、未登录用户、管理员。未登录用户只能查询航班信息；已登录用户可以购买、查看、退订机票；管理员可以安排航班信息。这张图最值得留意的是“外部信用评价系统”的接入：购买用例与“继续购买”“禁止购买”之间是扩展关系，触发条件是信用等级。

画用例图时要区分两个概念，文档里没有展开说，但评阅老师通常会追问：

• 包含关系：子用例是父用例的必经步骤。例如“购买机票”必然包含“选择航班”和“确认订单”，这是<<include>>。
• 扩展关系：子用例是可选或异常路径下的补充。例如信用等级过低时触发“禁止购买”，这是<<extend>>。

用 Rational Rose 画图时，两种关系的箭头方向正好相反，这是新手最常画反的地方。包含关系是从基用例指向被包含用例，扩展关系是从扩展用例指向基用例。文档里用“购买—继续购买—禁止购买”表达信用审核的追加逻辑，方向是对的，但你需要确认图中是否加了<<extend>>标签，否则老师看不出这是扩展关系。

2.2 状态图：别漏掉“禁止购买”这个终态

原文档对状态图的描述是“有 7 种状态，由用户登录开始”。我按原文把状态流拆成了下面这张表，方便你画完对照：

这里有一个容易踩坑的地方：文档正文在用例图情景里明确写了“信用等级过低时不允许购买”，但状态图描述里没有单独把“禁止购买”列成一个终态。你画状态图时，务必把这个终态补上，否则用例图和状态图对不上，评阅时会追问“禁止购买的路径去哪了”。

2.3 落地步骤：从功能清单拆出用例与状态

我一般画图前不做任何 UML 操作，先把需求拆成一张功能用例表。对照这份文档的 1.2 节，可以快速拆出：

1. 新用户注册：用例名“用户注册”，前置条件是用户名可用且两次密码一致。
2. 登录验证：用例名“系统登录”，扩展点是三次错误后自动关闭系统。
3. 航班查询：未登录用户可执行，已登录也可执行。
4. 订票：包含“查询舱位”“选择航线”“添加机票”三个子步骤。
5. 退票：用户先查询“我的机票”，再按票号退订。
6. 管理员安排航班：只对管理员角色开放。

拿到这张表之后再画用例图，每个用例你都能说清参与者、前置条件和后置条件。顺序图、协作图里的消息也全部从这张表里出，不会东拼西凑。

3. 静态建模三层递进：类图、包图与组件图怎么配合

3.1 类图：继承关系的方向先想清楚，再看原稿

文档里类图的主要设定是：订票系统是父类，已登录用户、未登录用户、管理员是子类，子类继承父类的属性和操作；评价系统与已登录用户之间是依赖关系。

作为课程设计，这样画能展示“泛化”这个知识点，但如果你把它当工程图用，这个继承方向值得商榷。一个系统类作为用户类的父类，在业务语义上并不自然；更常见的设计是“订票系统”持有用户的集合，而不是继承关系。我画类图时会这样调整：

# 从类图到代码骨架的映射示例（仅示意） class TicketSystem: """订票系统：持有用户和航班，而不是用户继承系统""" def __init__(self): self.users = [] # 用户列表，关联关系 self.flights = [] # 航班列表 def login(self, username, password, role): # role 区分客户或管理员，决定可用菜单 pass class User: """已登录用户：核心属性与操作""" def __init__(self, name, id_card, phone): self.name = name self.id_card = id_card self.phone = phone def book(self, flight_id): # 调用订票接口，写入订单表 pass def cancel(self, ticket_id): # 退票入口，原文档此处是删除数据库记录 pass class Admin(User): """管理员：继承用户基础信息，再扩展航班管理权限""" def arrange_flight(self, flight_info): # 对应用例图中的“安排航班信息” pass

这个例子的逻辑说明：TicketSystem用组合关系持有用户列表，比“用户继承系统”更贴近真实的面向对象设计；Admin继承User，符合文档里“管理员也是一种用户角色”的描述。参数上要注意login里的role参数是关键，它决定了登录后返回的是客户菜单还是管理员菜单，这正好对应原文档 1.2 节里的权限控制逻辑。

3.2 包图：依赖关系用虚线箭头还是实线箭头

原文档包图的核心表述是：业务包与用户包、管理员包、购买业务包之间存在依赖关系，任何一部分变化都会影响业务层；业务层变化又会波及信用评价包。

这里有个符号细节：UML 依赖关系用“虚线箭头”表示，箭头指向被依赖的一方。文档里“业务依赖于用户信息和管理员信息”，正确的画法是从业务包画虚线箭头指向用户包和管理员包，表示“若用户模型变了，业务包也需要适配”。

如果你要在自己的项目里复用这个分层，我建议把包划分成四个：view（界面）、business（业务）、data（数据访问）、util（公共工具）。用户可以和管理员拆在两个包也可以放在同一个user包里，取决于你们课设要求画到多细。原文档把购买业务单独拆出来，逻辑上是为了突出“购买”这个核心流程，你自己画的时候可以合并到业务包，不必照抄。

3.3 组件图：把逻辑模块映射到物理文件

组件图原文档由五个组件构成：客户端程序、管理员程序、服务器端程序、数据库端程序、数据库。其中客户端和管理员程序依赖于服务器端程序，服务器端程序通过接口连接数据库端程序，数据库端程序再依赖数据库。

画组件图时要注意它和包图的区别：包图是逻辑分组，组件图是物理模块。以常见做法来看，我会先把源代码按组件列一遍，比如：

这样评审老师问你“组件图里接口在哪”，你可以直接指服务器端和数据库端之间的那个接口符号。

4. 动态行为建模：顺序图、协作图与活动图的顺序安排

4.1 顺序图：七个对象、两次判断

文档里的顺序图描述了用户登录、订票、评价三个动作的交互顺序。原文提到“七个方框表示七个对象”，结合上下文，我通常会把七个对象拆成：用户、登录界面、订票系统、购买系统、查询系统、评价系统、数据库。

标准画法是这样推进的：

1. 用户向登录界面提交账号密码。
2. 登录界面把验证请求发给订票系统。
3. 订票系统返回验证结果。
4. 用户发起购买查询，订票系统转发到查询系统。
5. 购买系统向评价系统发起信用检查。
6. 评价系统返回“允许购买”或“禁止购买”。
7. 购买成功后写数据库，界面显示机票信息。

顺序图画完之后要检查一件事：每条消息箭头上标注的方法名，必须能在类图对应的类里找到。比如“评价系统”里要有check_month_return_count()之类的操作，如果没有，类图和顺序图就不一致。文档原文里确实提到了评价系统“检索用户的退票次数与时间”，说明建模时是有意保留这个方法的，这一点做得比较完整。

4.2 协作图：同样的交互，不同视角

协作图在原文档里画的是用户登录模块：输入账号密码、验证登录、读取个人信息、服务器反馈验证、用户购票、数据库插入记录、显示金额账户信息。

协作图和顺序图的信息来源相同，但协作图更看重对象之间的“链”和角色。原文档里的表述有一处容易误导：协作图并非完全不关心顺序，它只是把时序用消息编号来表达，而不是用纵向时间轴表达。如果你在 Rose 里画出协作图，箭头上的数字编号就是消息顺序，比如1: 输入帐号密码、2: 验证登录、3: 读取个人信息。

我自己的习惯是：顺序图用来给老师讲“时间先后”，协作图用来给老师看“谁和谁有连接”。同一场景画两张图不是凑数，而是分别回答“下一步做什么”和“上下游是谁”。

4.3 活动图：验证码分支、并行事件和泳道

原文档的活动图部分画了两个流程：用户登录流程和管理员登录流程。用户登录流程里有很有价值的一个片段——发送验证码之后，系统判断用户是否收到验证码。没有收到时出现并行分支：取消发送并结束登录，或重新发送验证码再次验证。

这个场景用活动图表达时要注意“并行分支”的画法：从判断节点引出两条分支，各自连接后续活动。如果你在 Visio 图里画，注意在分支汇合处加一个合并节点，否则图是不闭合的。

原文档的活动图有个可改进点：没有画泳道。活动图加上泳道后，能直观看出“用户做什么”“系统做什么”。特别是验证码发送这段，用户的动作是“填写身份信息”“接收验证码”，系统的动作是“发送验证码”“校验验证码”，分泳道后职责一目了然。如果你的老师要求体现职责分配，建议在重绘时把泳道补上。

4.4 建议的建模次序

文档原稿是把九张图直接罗列出来的，但实际建模流程有更合理的顺序。我的习惯是：

1. 先画用例图，确定系统边界和角色。
2. 再画类图，把用例中的参与者变成类和方法。
3. 接着画顺序图，验证类之间的交互是否跑得通。
4. 用协作图补充对象间的结构关系。
5. 用状态图描述核心对象的生命周期。
6. 用活动图描述业务流程和分支。
7. 最后画组件图和部署图，把软件结构落到物理设备。

这个顺序用在这份航空订票系统上，你会发现每个图都不是另一次创作，而是前一张图换个视角的产物。

5. 一致性检查与部署边界：把九张图串起来最容易翻车的地方

5.1 部署图：HTTP 与 ADO 别张冠李戴

部署图在图集中算最简单的部分，但细节里的技术选型值得你多看一眼。文档写明系统由用户端、管理员端、服务器端、数据库四类节点组成；用户端和管理员端通过 HTTP 连服务器，服务器通过 ADO 连数据库。

HTTP 是应用层协议，表达的是“浏览器/客户端”到“服务器”的通信方式。ADO 则是微软的数据库访问组件，常见于早期桌面系统或 ASP.NET 技术栈。如果你打算把自己的课设框架改成 Java 或 Spring Boot，就不要照抄 ADO 了，把部署图上的标注换成 JDBC 或 MyBatis 更符合当前技术栈。

这里常被追问的一个点是：既然用户端和管理员端都走 HTTP，为什么还要画成两个节点？从物理设备图上讲，管理员端和用户端可能安装在不同终端上，它们权限不同、程序包不同，所以在部署图上分开画，对应到前面组件图里的“客户端程序”和“管理员程序”两个物理组件，整体就自洽了。

5.2 模型一致性：九张图之间必须满足的四个对照点

评审时最容易被问倒的问题，不是某张图画错，而是图与图之间互相矛盾。结合这份文档，我整理了一份查图清单：

5.3 避坑：四个反复出现的常见问题

以下这些是我在实际评审和自查中反复遇到的坑，按“现象→原因→解决”列出，你可以一条一条对照。

问题一：包含和扩展关系画反，Rose 不报错，但老师一眼就看出来。

现象：用例图里购买机票指向查询航班用的是扩展关系，但查询航班其实是购买的前置必经步骤。

原因：新手笼统地把“有关联”都画成带箭头的虚线，没有区分<<include>>和<<extend>>的语义。

解决：画完用例图，逐条问自己一个问题：“没有这个子用例，父用例还能完成吗？”不能完成就是包含，偶尔才触发就是扩展。购买机票必然要先查航班，所以购买对查航班的依赖是包含；信用过低触发禁止购买，是典型的扩展。

问题二：顺序图和协作图画了同一场景，被质疑凑工作量。

现象：两张图上角色和消息几乎一样，只是布局不同。

原因：顺序图强调时间线，协作图强调对象链，但初学者常把两图画成同一张图的两种排版。

解决：换一种典型做法——顺序图画“用户订票流程”，协作图画“管理员安排航班流程”，或者顺序图画“正常购买”，协作图画“退票场景”。这样两张图各有侧重，工作量也更实在。

问题三：状态图没有终态，图不闭合。

现象：状态图从“未登录”开始画到“已购买”就结束了，没有标注“禁止购买”或“退出系统”。

原因：只按业务流程正向画了一遍，没有考虑规则里的异常分支。

解决：将文档里的信用评价规则补上：评价通过进“可购买”，评价不通过进“禁止购买”，用户退出登录则回到“未登录”。检查每个分支是否有出口。

问题四：类图里只写类名，不写属性和方法。

现象：类图里只有管理员、用户几个方框，下面一片空白。

原因：觉得属性方法会在代码里实现，图里省略没关系。

解决：按原文档补全核心属性和操作。至少保证关键方法名和顺序图消息一致，比如book()、cancel()、arrange_flight()。

5.4 答辩时怎么讲这套图

把九张图串起来讲，我建议用“需求→结构→行为→部署”的路线，不要平铺直叙逐图介绍。下面是一个可以直接套用的讲稿骨架：

• “系统的外部角色有三类，我通过用例图圈定边界，再通过功能列表逐项映射。”
• “类图展示了核心实体和权限模型，其中评价系统与用户之间的依赖关系对应了信用等级规则。”
• “顺序图展示了订票和退票的完整消息链路，状态图补充了信用过低时的禁止购买分支。”
• “最后，部署图说明了系统是 B/S 结构，用户端和管理员端通过 HTTP 访问服务器，服务器通过数据库接口完成持久化。”

这样讲，老师跟着你的思路走一遍，知道每张图解决什么问题，比按图序干讲更有说服力。

6. 进阶：把这套模型变成你项目里的“图纸”

6.1 从类图到建表语句：一份可直接改写的 SQL 映射

类图最终要落到数据库设计。我按文档里的用户、航班、订单、评价四个核心类，给出一份基础建表脚本：

-- 用户表：对应类图中 User 类的属性 CREATE TABLE user_info ( id INT PRIMARY KEY AUTO_INCREMENT, -- 用户主键 username VARCHAR(50) UNIQUE NOT NULL, -- 登录名，注册时校验可用性 password_hash VARCHAR(255) NOT NULL, -- 密码散列，原文是明文校验，工程上应加密 role TINYINT DEFAULT 0, -- 0 客户，1 管理员，控制菜单权限 id_card VARCHAR(18), -- 身份证号 phone VARCHAR(20), -- 联系电话 created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 航班表：对应类图中航班信息 CREATE TABLE flight ( id INT PRIMARY KEY AUTO_INCREMENT, flight_no VARCHAR(20) NOT NULL, -- 航班号，例如 CA1835 origin VARCHAR(50) NOT NULL, -- 出发城市 destination VARCHAR(50) NOT NULL, -- 到达城市 departure_time DATETIME NOT NULL, price DECIMAL(10,2) NOT NULL, -- 票价，退票时用于显示金额 seats_left INT DEFAULT 180 -- 余票数量，订票成功减一 ); -- 订单表：对应订票与退票两个核心用例 CREATE TABLE ticket_order ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, -- 下单用户，外键关联 user_info flight_id INT NOT NULL, -- 航班，外键关联 flight status TINYINT DEFAULT 0, -- 0 已预订，1 已退票 create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 信用记录表：对应评价系统的退票次数统计 CREATE TABLE credit_log ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, return_month VARCHAR(7) NOT NULL, -- 格式：2024-06，按月份统计 return_count INT DEFAULT 0, -- 当月退票次数，超过 2 次降级 level TINYINT DEFAULT 3 -- 信用等级，过低时禁止购票 );

这段脚本的逻辑说明：user_info表里的role字段对应文档里“客户/管理员两种登录方式”的权限控制，查询菜单时根据该字段过滤；ticket_order表里的status字段把“退票”实现成软状态更新，比原文档“从数据库删除本条信息”更稳妥；credit_log表用return_month加return_count统计一个月内退票次数，对应“一个月退订两次及以上”的规则。参数上你只需要改VARCHAR长度和DECIMAL精度，就能套用到自己的课设里。

6.2 三个容易被忽略的边界细节

第一个是登录重试次数。文档里写了三次错误自动关闭系统，这个规则在类图里没有专门属性，但在需求里是硬约束。我建议在用户类加一个login_attempts属性，每次登录失败自增，等于 3 时锁定会话，这也让状态图多了一个“会话关闭”状态。

第二个是退票软删除。原文档退票功能是“在数据库机票信息表中删除本条信息”，工程上不推荐直接物理删除，否则无法统计退票次数。把删除改成status = 1的状态更新，信用评价系统才能查得到历史退票记录，否则信用规则无从谈起。

第三个是“注册成功后免登录”的细节。文档说注册成功可以直接进入用户主界面，这背后其实省略了一次登录动作，相当于注册用例的后置条件是“直接创建会话”。画状态图时，这里要补一条从“注册成功”指向“已登录”的迁移线，不补的话状态流会断。

我从那次之后，每次画 UML 图都强制自己走一遍这样的流程：先列功能表，再画用例图，让每个用例都能在类图和顺序图里找到对应的落点，最后才画组件图和部署图。碰到信用规则这类带条件的分支，一律先在状态图里补终态，再去画别的图。这套习惯帮我在答辩和评审里少踩了很多坑，希望这份文档的拆解也能帮到你。

本文还有配套的精品资源，点击获取