简介一份面向 UML 初学者的图书管理系统需求分析文档系统梳理用例图、类图、顺序图等核心模型从需求分析到设计落地的完整过程适合作为软件工程课程设计或毕业设计的参考资料。压缩包内为单独的 1 个 doc 文档约 265KB包含需求描述及各类 UML 图的文字说明和设计思路。文档已被 2496 人浏览学习内容结构清晰从角色需求到模型实现层层递进便于按章节查阅。文档以借书者、图书管理员、系统管理员三类角色为主线覆盖用例模型、静态模型、动态模型与实现模型其中类图包含条目、标题、借出、预定、借书者信息等核心类顺序图展示了借书模块的对象交互同时涉及出版社信息管理、库存管理、销售统计等功能模块能够帮助读者理解 UML 建模中的角色职责划分、类关系设计和消息传递表达。1. UML建模与图书管理系统需求分析先画图还是先写文档拿到“图书管理系统”这类题目时多数人的第一反应是打开 Visio 或者 PlantUML赶紧把用例图、类图画出来。这个顺序其实是反的。UML 建模的价值不在于产出几张图而在于把需求里的歧义、冲突和漏项提前暴露出来——图只是沟通的载体。一份合格的需求分析报告核心交付物不是 UML 图集而是“所有人都认可的需求基线”。图书管理系统恰好是练这个功夫最典型的对象业务边界清晰、角色不过四五个、流程不复杂但分支多足够把 UML 的九种图用上一大半又不会被业务本身的复杂度淹没。这篇笔记适合两类人正在做课程设计或毕业设计、需要交需求分析报告的学生以及刚入职需要独立写需求文档、但又没受过系统训练的初级软件工程师。我按自己画过三轮这种报告的经验把从需求获取到图件落地、再到写成可评审文档的完整路径拆开讲。2. 需求采集与三类需求的边界先把“图书馆”拆成能建模的单元2.1 业务需求、用户需求、系统需求的分层逻辑做图书管理系统需求分析第一步不是画图而是把“图书馆要一套管理系统”这句话拆成三个层次。业务需求回答的是“为什么做”——通常是提升借阅效率、降低图书盘点人工成本、减少超期未还的漏管用户需求回答的是“谁要做什么”——读者要查书、借书、续借、预约图书管理员要上架、下架、办理借还、处理超期系统需求才落到“系统要提供什么功能、遵守什么规则”。很多报告翻车的起点就是把这三个层次混在一起写导致用例图的粒度忽大忽小。我习惯用一张简单的表格先把三个层次固定住再开始画任何 UML 图。表格的列分别是“层次”“关注角色”“典型诉求/规则”“是否可测试”。其中“是否可测试”这一列特别重要——如果一条需求写出来没法验证那它就不该进需求规格说明书而应该留在项目章程里当背景描述。例如“系统要方便管理员操作”属于用户愿望不可测试“图书管理员可以在 10 秒内完成一次借书登记”才是可测试的系统需求。层次关注角色典型诉求或规则是否可测试业务需求图书馆运营方降低图书盘点人工成本减少超期漏管否方向性用户需求读者、图书管理员读者能查书、借书、续借、预约管理员能办理借还部分可测流程层面系统需求系统本身同一读者同时借阅上限为 5 本借期 30 天超期每天罚 0.1 元是可用用例验证这个分层直接决定了后续用例图的参与者划分。读者和管理员是两类完全不同的参与者它们对系统的使用目标不同、权限边界不同、操作频率也不同。如果报告里把“读者”和“管理员”画成同一个用例的多个泳道后续的类图设计一定会出问题。划分完层次后还要做一件事明确系统的边界。图书管理系统通常不包含图书采购的财务审批也不包含图书馆门禁控制这两块属于外部系统的职责。把边界画在用例图里意味着你还得确定哪些参与者是“外部系统”——比如校园一卡通中心读者身份认证可能需要调用它的接口。这个判断影响组件图的部署视角但很多报告在这里偷懒把所有功能都塞进一个系统里导致后续类图膨胀。2.2 功能需求与非功能需求用编号建立追踪关系需求分析报告里功能需求和非功能需求不能混着写。我一般用 FRFunctional Requirement和 NFRNon-Functional Requirement两个编号前缀来区分每条需求带一个唯一编号编号在后续用例图、类图、测试用例里都会被引用。没有编号的需求在评审时根本没法讨论——你说“系统应支持预约”别人问“哪条需求说的”你只能翻半天。图书管理系统的功能需求通常可以列到 20 到 30 条。核心的几条大致是FR-001 读者可以通过书名、作者、ISBN 检索馆藏图书FR-002 读者可以提交借书申请系统校验借阅额度与违章状态FR-003 管理员可以办理借书登记系统记录借出时间与应还时间FR-004 管理员可以办理还书登记系统计算是否超期并生成罚金记录FR-005 读者可以预约当前已借出的图书预约排队的顺序按预约时间先后排列FR-006 管理员可以维护图书书目信息包括新增、修改、下架。非功能需求在图书管理系统里容易被一句话带过但这里恰恰是评审老师或技术负责人最爱追问的地方。至少要覆盖性能、安全、可用性、可维护性四类每条仍然要可测试。例如 NFR-001“系统在 50 个并发查询请求下检索接口的平均响应时间不超过 2 秒”NFR-002“读者的个人借阅历史与罚金记录除本人和管理员角色外其他角色不可见”NFR-003“系统年可用性不低于 99.5%”。这些条目写清楚之后后面的架构选型和组件图才有依据——比如要不要做缓存、要不要做权限拦截都是从这些非功能需求推导出来的。写功能需求时还有一个常见的认知误区把“读者可以借书”和“管理员可以办理借书登记”当成同一条需求。它们在用户需求层面确实对应同一件业务事但在系统需求层面前者是读者发起申请后者是管理员执行登记权限不同、数据校验逻辑不同、异常分支也不同。所以我的习惯是拆成两条 FR分属两个用例这样后面画顺序图时会自然分成两条消息链不会缠在一起。2.3 数据字典先行把“一本书”变成一个可建模的定义UML 类图之所以经常画得七零八落根子是数据字典没有先立住。“图书”在业务口语里是一个词但在系统里必须拆成书目Bibliographic Record和馆藏副本Copy/Item两个概念。书目描述的是这本书的固有属性——书名、作者、ISBN、分类号、出版社、出版日期馆藏副本描述的是这一本实体书在图书馆里的状态——馆藏编号、当前借出状态、当前位置、入库日期。这两个概念不分开类图里“图书”类就会既挂书名又挂借出状态而同一本书有三本副本时有副本被借走、有副本在架上的情况就完全表达不出来。数据字典的每一张表我通常至少定义这些字段字段名、数据类型、约束/取值范围、默认值、是否必填、所属实体。以馆藏副本为例几个关键字段的约束会直接影响类图多重性和状态图字段名数据类型约束/默认值说明copyIdString必填唯一每本实体书的馆藏编号bookIdString必填外键到书目关联书目主键statusEnumON_SHELF / BORROWED / RESERVED / LOST / DISCARDED馆藏状态机的全部状态locationString必填如“A区-3排-2架”物理位置borrowCountInteger默认 0累计借出次数用于热门书统计数据字典还有一个容易被忽略的规则说明借阅规则本身也是数据而不是写死在代码里的逻辑。比如“最大借阅册数 5 本”“借期 30 天”“续借次数最多 1 次”“超期罚金每天 0.1 元”这些要定义成参数表系统参数实体而不是散落在各个需求条目里。这样做的原因是规则一定会变——学校图书馆期末可能会临时把借期从 30 天改成 15 天如果规则在需求文档里写死下次改需求就要改代码如果建模成可配置参数只是改一条数据而已。这个细节在需求分析报告里体现出来是区分“画图员”和“需求分析师”的一个标志。3. 从用例到类图图书管理系统六种核心 UML 图的建模顺序与要点3.1 用例图参与者、用例关系与边界框的选择用例图是整个需求分析报告里最容易被低估的一张图。它表面上只是把参与者和用例连起来但实际上它是需求范围的“合同”——画进边界框里的功能才做框外的不做。图书管理系统的用例图参与者侧我建议只保留三类读者、图书管理员、系统时间触发器用于每日检查超期、自动发送催还通知。有些报告会把“系统管理员”也画进去理由是系统要维护用户权限。这在小型图书管理系统里其实可以合并进图书管理员——图书管理员设置其他管理员的账号和权限不需要单独一个参与者角色。用例的选择要和控制粒度较劲。我见过最典型的问题是把“登录”画成一个用例。严格来说登录是几乎全部用例的前置条件不是独立业务用例。图书管理系统真正的用例应该是检索图书、查看图书详情、借书读者发起申请、办理借书登记管理员执行、办理还书登记、续借、预约图书、取消预约、催还通知、罚金缴纳、书目维护、馆藏副本维护、读者信息维护、借阅规则参数维护。这些用例之间有几组关系要特别注意。“续借”和“借书”的关系是 extend——续借是在借书成功后的可选扩展它的前置条件是“当前有未还的借阅记录”。而“检索图书”和“查看图书详情”之间是 include 关系——查看详情必然要先检索到目标图书。include 和 extend 这两个关系是 UML 用例图里最容易被画反的地方评审时被问到“为什么这里是 extend 不是 include”答不上来很尴尬。简单记法include 是“每次都要做”extend 是“特定条件下才触发”。系统边界框的画法也有讲究。图书管理系统的用例图里我习惯把“调用校园一卡通认证接口”画在边界框外因为那是外部系统的职责图书管理系统只是它的调用方。边界框内画的是本系统必须自己实现的功能这个区分直接影响组件图里要不要画外部系统节点。3.2 类图实体类、边界类、控制类的划分与关系约束类图是需求分析报告里最重的一张图也是几乎所有报告写砸的重灾区。图书管理系统的类图我建议按“实体类—边界类—控制类”三层来组织而不是把所有类堆在一张图里。实体类对应数据字典里的表书目、馆藏副本、读者、借阅记录、预约记录、罚金记录、系统参数、通知记录。边界类是系统与外部交互的入口在图书管理系统里可以简化为读者界面、管理员界面、外部认证接口。控制类承载业务规则比如借书控制器、还书控制器、预约控制器、催还调度器。实体类之间的关系要精确到多重性这是报告分数或评审认可度的直接分水岭。书目的馆藏副本关系是 1 对 0..*——一本书目可以有零个或多个副本但一个副本必须属于一个书目。借阅记录关联读者和馆藏副本一位读者可以有多条借阅记录一个馆藏副本在时间轴上也可以有多条历史借阅记录但任意时刻只有一条“进行中”的记录。这里的多重性不写数据库的约束就无从谈起。类图里的关键属性要和第 2 章的数据字典对齐。借阅记录这个类至少要包含borrowId、readerId、copyId、borrowDate、dueDate、returnDate、status。其中 status 这个属性的取值集合不是随便枚举的它由后面的状态图来约束。我在类图里一般不写方法名只写属性因为需求分析阶段的类图关注的是数据结构而不是行为实现方法名留给设计阶段充实。如果你在需求分析报告里就把每个类的增删改查方法写全等于把需求分析报告写成了设计说明书层次就乱了。类图里经常被忽略的是约束Constraint的表达。借阅规则“同一读者同时借阅不超过 5 本”可以在类图里用约束标注在读者类和借阅记录类的关联上也可以配合 OCL 写一段约束表达式。很多教材不要求画 OCL但如果你能在需求分析报告里补一笔比如“context Reader inv: self.borrowRecords-select(r | r.status BORROWED)-size() 5”评审会明显感觉到你对建模的理解超过平均水平。不会 OCL 语法也没关系用自然语言把约束写在类图旁边效果比画一张没有约束的干图强得多。3.3 顺序图与活动图的取舍画哪些场景消息怎么命名顺序图和活动图的分工在一份报告里必须明确。顺序图回答的是“一个用例在某个具体场景下对象之间怎么交互”它适合表现单条时间线上的消息传递顺序活动图回答的是“一个业务流程里有哪些分支、并发和判断”它适合表现在借书流程里有多个条件判断时的全貌。图书管理系统里借书业务流程最适合用活动图因为它有“读者是否超期”“是否超过借阅上限”“图书是否可借”三个判断节点分支多而“读者发起借书申请被接受”这个具体场景则用顺序图来画消息链。顺序图画三条就够借书成功主场景、还书并缴纳罚金场景、预约后到馆取书场景。每一条都要画清楚参与者、系统边界、控制对象、实体对象四层。消息命名要用动词短语比如“submitBorrowRequest()”“checkReaderStatus()”“createBorrowRecord()”不要用“处理数据”这种空泛的词。消息后的返回消息也要体现比如“借书限额校验通过”“馆藏副本状态更新为 BORROWED”。画顺序图最常见的错误是跳层——从参与者直接发给数据库绕过了控制类。顺序图里参与者只能和边界类交互边界类调控制类控制类才访问实体类这个分层要保持。活动图方面借书流程用泳道图画三个泳道读者、系统、管理员可选。读者泳道发起申请系统泳道依次做三张判断卡第三张判断卡“图书是否可借”出来两个分支——可借则走借出分支不可借则判断是否允许预约预约又分支为进入预约队列或提示等待。活动图的判断节点必须都有明确的守卫条件比如“[读者超期]”“[借阅数量达到上限]”没有守卫条件的判断卡等于没画。合并节点也别漏分支后只有一条路径到达终点时合并节点是必需的否则图上的流程汇合点语义不完整。3.4 状态图与组件图馆藏副本的生命周期和系统部署边界馆藏副本状态图是图书管理系统里最值得画的一张状态图因为它的状态切换规则直接对应核心业务规则。馆藏副本的状态集合是 ON_SHELF、BORROWED、RESERVED、LOST、DISCARDED。状态迁移的事件要一一列清楚ON_SHELF 到 BORROWED 的触发事件是“管理员办理借出”BORROWED 到 ON_SHELF 的触发事件是“管理员办理还书且无预约在队”BORROWED 到 RESERVED 的触发事件是“当前借阅人还书且有预约在队”ON_SHELF 到 RESERVED 的触发事件是“读者预约成功副本被预留下来待取”。这里有一个极容易画错的地方RESERVED 的副本不再处于可借状态所以从 ON_SHELF 到 RESERVED 的迁移必须存在否则预约功能在状态模型里根本没有位置。LOST 状态也不能省。图书丢失在真实图书馆场景里不是小概率事件读者还书时发现书破损无法继续流通或者盘点时副本不在架都要有把副本置为 LOST 的路径。LOST 分支后面往往接一个补偿事件读者赔付后副本从馆藏中移除对应状态迁移到 DISCARDED。这个状态如果不建模还书和盘点的需求就缺了半边。组件图在需求分析报告里相对次要但画一张能体现部署边界。图书管理系统按最常见的单体分层来画表现层组件读者端 Web 页面、管理员端 Web 页面、业务逻辑层组件借阅服务、书目服务、预约服务、催还服务、数据访问层组件、数据库组件。组件之间的依赖关系画成带箭头的虚线依赖——表现层依赖业务层业务层依赖数据访问层。如果学校场景里还有校园一卡通的外部认证系统就在组件图里单独画一个外部组件用端口连接本系统的认证服务组件。组件图的粒度到服务级别就行不要再拆到类级别否则和类图职责重叠。4. 从 UML 模型到需求规格说明书把图翻译成可评审的文字4.1 需求规格说明书的组织方式与“用例描述”表格模板图全部画完之后下一步不是做 PPT而是把这些模型翻译成一份需求规格说明书SRS。没有文档支撑的 UML 图集在模块评审里只是过眼云烟。我组织一份图书管理系统 SRS 的方式是沿着“引言—总体描述—功能需求—非功能需求—数据需求—验收标准”的顺序走其中功能需求部分不使用长篇大论的文字而是用“用例描述表”一条一条贴住每一个用例。用例描述表的列我固定在八列左右用例编号、用例名称、参与者、前置条件、后置条件、主事件流、备选事件流、业务规则。以“办理借书登记”为例主事件流大概是管理员扫描读者证系统显示读者当前借阅状态管理员扫描馆藏副本编号系统校验副本状态与读者资格校验通过则创建借阅记录更新副本状态为 BORROWED计算应还日期系统返回借书成功结果。备选事件流要写清楚几个分支读者有超期未还记录时系统拒绝办理并提示副本状态不是 ON_SHELF 时系统提示不可借读者同时在借数量已达上限时系统拒绝。业务规则引用第 2 章定义过的规则编号比如 BR-001 借阅上限 5 本、BR-002 借期 30 天。这张表的价值在于它把所有图里的信息收敛到了同一个可读的载体上。顺序图画的是借书成功的场景用例描述表把失败分支补齐活动图画的是流程的全貌用例描述表把每个节点的业务规则落到编号。评审时评审人可能没时间细看每一张 UML 图但一定会翻这些表格——因为只有表格才能被逐条验证和讨论。4.2 可验证的验收标准把“系统应支持续借”写成能测试的语句需求条目写得能不能验收是文档质量的分水岭。“系统应支持续借”这句话没有任何验收价值它没有说续借的条件、时限和次数。图书管理系统里几条核心需求我建议按这个格式重写当用户满足“当前有未还借阅记录且该记录未超期、续借次数未超过 1 次、且在应还日期前 3 天内”时系统允许提交续借申请并将借阅记录的应还日期延后 30 天同时保留原借阅记录的历史。这个写法里每一个条件都是可以验证的。我习惯把验收标准列成一张表每条 FR 对应一条验收用例。例如 FR-003 办理借书登记的验收用例是预置读者 A 在借数量为 4借阅上限为 5系统应接受第 5 本副本的借出并创建借阅记录继续借第 6 本时系统拒绝并返回错误码 BORROW_LIMIT_EXCEEDED。预置条件、操作步骤、预期结果三列是必须的。这样做的好处是需求分析阶段就把测试用例的主干写出来了后面开发完成进入测试阶段时测试团队可以直接基于这张表扩展用例不用从零设计。验收标准还要覆盖非功能需求。NFR-001并发下检索响应时间平均不超过 2 秒的验收标准要写明压测工具、并发数、采样方式。这个在需求分析报告里不一定要写工具名但必须写清楚验证方法——是用脚本模拟 50 个并发请求统计平均响应时间与 95 分位响应时间。不可验证的非功能需求比如“系统要运行稳定”在评审时一定会被问“怎么测”答不上来就得当场改文档。4.3 需求追踪矩阵为什么它决定报告的上限需求追踪矩阵Requirements Traceability Matrix是很多报告缺失但专家评审必看的部分。它是一张三列表需求编号、对应 UML 图件、对应验收用例/测试用例。以 FR-004 办理还书登记为例追踪矩阵里这一行应该填需求条目 FR-004、UML 定位到“馆藏副本状态图 BORROWED 到 ON_SHELF 的迁移”加“借还书顺序图”、验收用例为 TC-004-01。追踪矩阵的价值有二。第一它能发现需求漏项——如果某一条 FR 在矩阵里找不到对应的 UML 图件说明这个需求没有被建模开发时大概率会被遗漏。第二它能发现多余工作——如果某一张 UML 图在矩阵里没有任何一条 FR 引用说明这张图画了没用是纯凑数。图书管理系统里最常见的“无用图”是部署图——如果报告里没有分布式或跨节点的需求部署图画出来纯粹是占篇幅删掉比留着好。矩阵条目保持在 30 到 40 行即可把每条核心需求都覆盖到不要为了撑篇幅塞入细枝末节的需求否则矩阵本身的重量会压垮文档的可读性。5. UML 建模与需求分析常见坑五条高频翻车记录5.1 图多字少用例图画了二十个需求条目只有五条现象报告交上来用例图密密麻麻画了二十多个用例但正文里功能需求只有五条每条还是一句话。评审问“这个用例对应的验收标准是什么”全场沉默。原因把画图当成了目的本身图没有从需求条目生长出来。用例是需求的视图不是需求本身需求条目没有定义清楚时用例只能是凭想象堆出来的。解决回到第 2 章的流程先把功能需求用 FR 编号一条条列出来确定每条可测试再为每条需求找到用例归属。一个用例可以承载多条相关需求但反过来一条需求必须能在至少一个用例里被明确执行。如果用例图和需求列表对不上以需求列表为准删改用例图而不是反过来。5.2 前置用例没有定义include 和 extend 乱用现象用例图里“续借”直接和“借书”平行摆放甚至用 include 把“登录”包含进每一个业务用例。评审问“续借和借书是什么关系”回答是“都是借还书”。原因混淆了用例之间的三种关系——include 表示每次执行目标用例时必然包含的公共步骤extend 表示特定条件下才追加的可选片段generalization 表示子用例继承父用例的行为。“续借”不是“借书”的子集也不总是在借书后发生它的主语是“已有借阅记录的读者”和“借书”完全不是一种触发条件。解决图书管理系统里把“读者身份验证”做成所有业务用例的公共前置条件不画成 include把“续借”标注为借书用例的 extend 扩展并写明扩展条件“当前持有未还借阅记录且该记录已临近应还日期”。考试或者面试被问到 UML 用例关系时这个例子是典型的答法。5.3 类图画成了 ER 图只有实体和关系没有行为边界现象类图只画了实体类和它们之间的连线所有类的属性跟数据字典里字段一字不差却没有控制类、没有边界类也没有任何约束标注。原因照着数据库设计反推类图。需求分析阶段的类图应该回答“系统中有哪些概念、谁依赖谁、规则是什么”而不是回答“数据库有哪些表”。只有实体类的图缺失了行为分配后续画顺序图时对象之间没有控制者交互链路会断。解决重画时按“实体类—边界类—控制类”分层让借阅记录、预约记录这些实体类只承载数据借书控制器、还书控制器承载规则判断读者界面和管理员界面承载交互入口。类图和顺序图用的是同一套类划分一致性立刻提升。类图与 ER 图的区别要能在报告里用一句话讲清ER 图是数据视角类图是对象视角对象同时有属性、行为和关联。5.4 顺序图只画主流程失败分支全部消失现象借书顺序图上只有一条直线从参与者到边界类到控制类到实体类一气呵成全图没有一条分支、没有一个异常返回。原因画图的人默认业务流程只有成功路径。但需求分析要关心的恰恰是失败路径——读者超期时校验如何返回、副本不在架上时流程在哪里终止、借阅上限到达时返回什么错误码这些才是系统设计真正需要的输入。解决顺序图至少为每个核心用例画一张“主成功场景”和一张“主要失败场景”。借书用例的失败场景画读者超期分支控制类调用校验服务返回 OVERDUE 结果流程在边界类处终止界面显示“存在超期未还记录请先处理”。把失败分支画出来类图的控制类职责才完整测试用例也从这里直接派生。5.5 需求描述不可验证形容词和数据缺失现象需求条目写着“系统应高效处理读者的检索请求”。评审问“高效怎么测”作者无法作答。原因用形容词代替了量化指标需求没有落到可测试的边界。解决重写为“系统在 50 个并发检索请求下平均响应时间不超过 2 秒95 分位不超过 4 秒”。所有需求条目按这个标准逐条过一遍凡是带“高效”“快速”“友好”“灵活”这类词的条目全部打回重写。图书管理系统的需求体量不大这个检查过程半天就能做完但这半天省下来的是开发阶段扯皮的时间。6. 报告复用与自查让这套 UML 建模流程在下一个项目里继续生效需求分析的能力不是从教科书里读出来的是从一份报告改到另一份报告的迭代里磨出来的。图书管理系统这个题目的价值在于它足够小你可以把完整的建模链路走通一遍然后把这条链路整体复用到更大的题目上——比如题库管理系统、实验室设备管理系统、社团活动管理系统。它们的实体不同但用例图的角色划分方法、类图的三层结构、状态图的迁移事件分析、用例描述表的模板全部可以直接平移。我自己的习惯是维护一份需求分析模板文档把图书管理系统里验证过的用例描述表结构、验收标准格式、追踪矩阵的表头存成固定模板新项目来了只换业务实体和规则不换文档骨架。动手写下一篇报告之前建议按下面这张五问自查表过一遍比反复通读全文效率高得多。第一问每条 FR 是否都有唯一的编号并且可测试第二问每一张 UML 图是否至少被一条需求引用没有“孤图”第三问状态图里的每个状态是否都有明确的进入和迁出事件第四问顺序图是否覆盖了每个核心用例至少一条失败分支第五问非功能需求是否每条都写了验证方法而不是形容词这五个问题全部通过文档大致就是一份能进入评审流程的需求基线而不是一本图集加一堆散文。最后说一个我踩过三次的教训在画用例图和类图之前一定要先写数据字典。前两次我都是图先画得差不多再回头补数据定义结果类图的多重性画错了两轮顺序图里的消息参数也跟着错。第三次老老实实先定“书目—馆藏副本”“读者—借阅记录”的字段与约束后面的图件一次性通过评审。画图只是把已经想清楚的东西表达出来想清楚靠的是需求分层和数据字典不是 UML 工具本身的拖拽操作。希望这份路径能帮你在自己的报告里少返一次工。本文还有配套的精品资源点击获取