企业官网建设流程全解析

简介：面向计算机专业学生与软件工程入门者的UML建模需求分析文档，围绕图书管理系统展开完整建模流程，适合课程设计、实验报告与建模练习参考。内容从借书者、图书管理员、系统管理员三类角色切入，依次梳理用例模型、类图静态结构、顺序图与活动图等动态交互，以及构件图和部署图的实现视图，并给出Item、Title、Loan、Reservation、Borrower等核心类的职责划分思路。压缩包共1个doc文件，约265KB，体量轻便，便于打印或二次编辑成自己的报告框架。已有2496人学习下载，说明其在同类课程作业中具备一定参考价值。读者可据此掌握从需求描述到UML图落地的组织方式，理解角色—用例—类—交互—部署之间的衔接，也能借鉴报告章节安排与建模表达，减少从零搭建文档时的反复试错。

1. 课程设计答辩现场，最容易被问住的不是功能多不多，而是“你这个类图的箭头为什么指向这边”

拆过几份 UML建模 的图书管理系统需求分析报告，有个反直觉的现象：图越漂亮，越经不起追问。这份报告的价值不在图本身，而在它把借书者、图书管理员、系统管理员三条需求线，一路翻译成用例图、类图、顺序图、构件图的完整推演链条，中间没有断层。它适合正在做课程设计、需要交一份能自圆其说的需求分析文档的人，也适合想补一遍 UML建模 基本功的开发者——类图、用例图、顺序图这三张图，几乎每个管理系统都要画一遍。下面按图的顺序拆：角色怎么划边界、类怎么连多重性、消息怎么排时序、哪些地方最容易翻车。

2. 用例模型：三个角色划边界，用例粒度决定后面所有图的上限

2.1 角色识别：边界划错，后面的图全白画

用例模型的第一步不是画图，是确定 Actor。报告里把角色定为借书者、图书管理员、系统管理员三类，这个划分看着朴素，实际是有讲究的：三类角色的权限来源不同，借书者的权限来自借书证，图书管理员的权限来自岗位，系统管理员的权限来自系统内置账号。权限来源不同，意味着校验逻辑、数据可见范围、操作入口都不一样，必须在用例层就分开。

常见的误判是把“读者”当成一个角色。读者里既有能借书的，也有只能查目录的，混成一个角色，后面写用例描述时前置条件就没法写。报告用“借书者”这个词，指向的是“有借阅资格的人”，这个措辞比“读者”准确。如果系统对外开放匿名查询，可以再补一个只读角色，但报告没写，别自己加戏，加一个角色就要多一套权限校验，课程设计的篇幅撑不住。

图书管理员和系统管理员之间的边界也要说清楚。图书管理员是系统的主要使用者，负责借书处理和还书处理，读者预定的图书借出给预定者之后，还要取消这条预定记录——这三件事都是业务操作。系统管理员管的是读者信息、图书信息、系统状态维护，属于基础数据维护和运行保障。两者的区别在于：图书管理员动的是“业务流水”，系统管理员动的是“主数据”。这条边界一模糊，类图里就会出现“管理员类”一个类扛下所有操作的情况，后面拆顺序图时找不到该由谁接收消息。

这张表不是交付物的一部分，但它是我画用例图之前必写的一页草稿。角色边界定下来，用例图里的连线基本就自动出来了，剩下的只是取舍粒度。

2.2 用例粒度：借阅和借书处理必须拆成两个用例

用例命名的基本规则是“动词+名词”，但真正难的是粒度。报告里借书者一侧有五个用例：查询个人信息、查询图书信息、预定图书、借阅图书、归还图书；图书管理员一侧有借书处理、还书处理、取消预定。这里面最容易翻车的是“借阅图书”和“借书处理”这一对——很多人会把它俩合并成一个用例，理由是“都是借书”。

合并的后果在顺序图上立刻暴露：用例只有一个，但触发它的人有两个，一个是发起请求的借书者，一个是执行办理的管理员，顺序图里第一条消息该从哪条生命线发出？说不清。拆成两个用例之后，借书者的“借阅图书”是提交请求，图书管理员的“借书处理”是受理并落库，前者可以被后者包含，也可以独立触发（自助借还机场景），语义是干净的。

用例之间的关系，报告没有展开，但落地时至少要处理两种。include 用于提取公共子流程，比如“预定图书”“借阅图书”都要先“查询图书信息”，可以把查询抽成被包含用例，避免在多个用例描述里重复写查询逻辑。extend 用于可选扩展，比如“借阅图书”在图书已借出的情况下可以扩展出“预定图书”，扩展点是“图书不可借”。这两种关系的区别不在图上，在用例描述的文字里：include 是一定会执行的分支，extend 是满足条件才执行的分支。画反了，评审时一眼就能看出来。

2.3 用例描述表：把图落到可验收的文字

用例图画完只能说明“有哪些功能”，说明不了“功能怎么算完成”。报告里这块是薄弱环节，只列了用例没写描述。补一张用例描述表，成本很低，收益很大——后面写顺序图时，消息顺序直接从基本流里抄。

以“借阅图书”为例，描述表至少包含用例编号、参与者、前置条件、基本流、异常流、后置条件六项。前置条件是校验逻辑的来源：借书者身份有效、无超期未还、未达借阅上限。这三条直接对应类图里 Borrower 的属性和操作——状态字段、可借数量字段、校验资格方法。异常流是顺序图里分支消息的来源：身份被冻结走一条分支，图书已借出走另一条分支。

提示：异常流编号用“步骤号+字母”的写法（2a、3a），和基本流一一对应。这个约定在评审时很吃香，因为读的人能立刻定位到是哪一步出的问题。

3. 静态模型：Item、Title、Loan、Reservation、Borrower 五个类怎么连

3.1 五个核心类的职责划分

报告列出的核心类是 Item（条目）、Title（标题）、Loan（借出）、Reservation（预定）、Borrower（借书者信息）。这五个类不是随便挑的，它们对应了图书管理业务里两个最容易混淆的概念：书目和册。

Title 是书目，代表“这本书是什么”，属性是 ISBN、书名、作者、出版社、分类号、价格。Item 是册，代表“图书馆里有这一本实物”，属性是条码号、状态、馆藏位置。一本书目可以有多册，一册书可以被借多次。把这两个概念合成一个类，会出现什么后果？借出记录没法准确指向“哪一册被借走了”，只能指向“哪本书被借走了”，同一本书有五个副本时，归还时不知道销哪一条账。这是图书管理系统建模里最经典的一个分水岭。

Loan 是借出记录，属性包括借出编号、借出日期、应还日期、归还日期、状态。它是业务流水的载体，一条记录对应一次借还。Reservation 是预定记录，属性包括预定编号、预定日期、状态、通知标记。Borrower 是借书者信息，属性包括借书证号、姓名、类型（学生/教师/校外）、状态、可借数量。

属性的可见性也要标。借书证号这类主键用 private，配一个 public 的查询方法，不要图省事全设成 public。报告里的类图没标可见性，这是常见疏漏，评审老师问一句“你的封装体现在哪”就答不上来。

3.2 类之间的关系与多重性

五个类之间的关系，报告只说了“有关系”，没说是什么关系、几对几。这部分必须补，因为多重性是顺序图和建表脚本的共同依据。

Title 和 Item 之间是一对多：一个书目对应零到多册。注意是 0..* 不是 1..，新书入库前可能只登记了书目还没编目上架。Item 和 Loan 之间也是一对多，一册书历史上可以被借出多次，所以 Loan 端是 0..，新书可能一次都没借过。Borrower 和 Loan 之间是一对多，一个借书者可以有多条借出记录。Borrower 和 Reservation 之间是一对多。Reservation 和 Title 之间是多对一，一条预定指向一个书目，一个书目可以有多条预定排队。

关系类型上，Title 和 Item 用普通关联就够了，不要用组合。组合的语义是“整体不存在了，部分也不能独立存在”，但书目下架时，册还在馆藏里，册不能跟着删。用组合，后面写删除逻辑时会很难受。Loan 和 Item、Loan 和 Borrower 都用关联，因为借出记录是独立实体，不随某一方删除而消失——真要删，也是逻辑删除，改状态字段。

还有一条隐含约束值得写进类图注释：同一个 Item 在同一时刻最多只有一条状态为“借出中”的 Loan 记录。这是业务规则，UML 里可以用约束表达式标在关联线上，写成{同一 Item 的未归还 Loan 数 <= 1}。不写这条，后面并发借书时会出现同一册书被借给两个人。

3.3 从需求到类图的落地步骤

工具层面，报告指定的是 Rational Rose 2003，配 VB 语言。这套组合在课程设计里很常见，操作路径也固定。下面是我一般会走的顺序，每一步都有对应的检查点。

第一步，新建模型，选 Use Case 视图先画用例图，再切到 Logical View 画类图。不要在同一个图里混着画，Rose 的视图划分是有意义的，后面生成代码只认 Logical View 里的类。

第二步，逐个建类。类名用英文，和需求文档里的中文名对一张表，别直接用中文类名，生成代码时会出问题。类建好后在 Specification 里填 Documentation 字段，把职责用一句话写清楚，这比在图上加注释框管用。

第三步，加属性和操作。属性要设类型和可见性，操作要设参数和返回类型。VB 里字符串用 String，日期用 Date，金额用 Currency 或 Double 看精度要求。

第四步，连关系。Association 用实线，Aggregation 用空心菱形，Composition 用实心菱形。连完之后逐个双击设多重性，Rose 默认是 1 对 1，不手动改就全是错的。

第五步，加约束和注释。业务规则写成 Note 挂在关联线上，或者用约束表达式写在大括号里。

第六步，导出图。Rose 支持导出图片，导出前把字体调大，默认字号打印出来看不清。

注意：Rose 2003 的类图里，属性和操作默认不显示可见性符号。要在 Options 里勾上 Show Visibility，否则导出的图看不出封装设计。

4. 动态模型：借书顺序图里那十条消息，一条都不能少

4.1 顺序图的二维读法

顺序图是一个二维图：纵向是时间轴，时间从上往下流；横向是协作中独立对象的类元角色，每个角色一条生命线。对象存在时生命线是虚线，对象的过程处于激活状态时，生命线变成双道线，也就是激活条。消息从一个对象的生命线指向另一个对象的生命线，箭头表示方向，从上到下排列就是时间顺序。

这三种元素里，初学者最容易画错的是激活条。激活条表示“这个对象正在处理某件事”，不是“这个对象存在”。一个对象从头到尾都在图上，但它的激活条可能只有两段：一段是接收请求，一段是返回结果，中间在等别的对象，这时候激活条应该是断开的。把所有对象的激活条从头拉到尾，图看着整齐，但语义是错的——它表示所有对象全程都在忙。

消息类型也要分清。同步消息用实心箭头，表示发送方等待接收方处理完才继续；异步消息用开箭头，表示发出去就不管了；返回消息用虚线开箭头，表示处理结果回传。借书流程里，控制器调用 Borrower 校验资格是同步消息，Borrower 返回校验结果是返回消息，这两条要成对出现。只画去不画回，等于说这个调用没有结果，逻辑就断了。

4.2 借书模块的消息序列

报告里说借书模块的顺序图展示了借书者、图书管理员和系统之间的交互。按这个描述，我把参与者对象定为五个：借书者、借阅界面、借书控制器、Borrower、Item、Loan。图书管理员在自助场景下不出现，在柜台场景下作为触发者出现，可以画两条生命线，也可以把管理员并入界面，看你要表达什么。

消息序列按用例描述表的基本流展开，一条基本流步骤可能对应多条消息。校验借书者资格这一步，控制器要调 Borrower 的校验方法，Borrower 内部查状态字段和已借数量，再返回结果，所以至少两条消息。校验图书可借状态同理。生成借出记录这一步，控制器调 Loan 的创建方法，Loan 返回借出编号，也是两条。

这十条消息里，3 到 6 是校验，7 到 9 是落库。异常分支画在哪个位置也有讲究：资格校验失败，消息 4 返回 false，控制器直接跳到最后一条返回消息，中间的 5 到 9 全都不执行。顺序图里表达这种跳过，用一个大 Alt 组合片段框住两条分支，条件是[资格通过]和[资格不通过]。不画组合片段，读图的人会以为不管校验结果如何都会往下走。

图书已借出的分支更复杂一点，因为要转预定。这条分支在组合片段里写[不可借]，里面接一条控制器调 Reservation 的 create 消息。这就是用例图里“借阅图书可扩展预定图书”在顺序图上的落点，两张图对得上，报告才立得住。

4.3 活动图与协作图：什么场合用哪个

报告提到动态模型用顺序图、活动图和协作图从不同角度描述交互。这三种图不是随便挑一个画就行，各有各的适用面。

顺序图强调时间顺序和消息序列，适合画单个用例的详细交互，尤其是消息有明确先后依赖的场景，借书、还书都属于这类。缺点是对象一多图就横向撑爆，十几个对象排一排，打印出来看不清。

协作图强调对象之间的结构关系，用编号表示消息顺序，适合看“谁和谁有联系”。它和顺序图在语义上是等价的，Rose 里可以互相转换，所以课程设计里画一个就行，不必重复劳动。真要画，用在说明“借书控制器同时依赖 Borrower、Item、Loan 三个类”这种结构特征上比较合适。

活动图强调控制流，适合画跨用例的业务流程，比如“读者预定一本书，到书后通知，超期未取自动取消”这条链路，涉及预定、通知、取消三个用例，顺序图要画三张，活动图一张就能说清。它还能画泳道，把借书者、管理员、系统三方的动作分开，审阅时一目了然。

5. 避坑与排查：五个翻车现场，每一个我都见过不止一次

5.1 现象：用例图里出现“数据库”和“登录界面”当角色

图一打开，左边一排小人，除了三个真人角色，还站着“数据库”“登录界面”“打印机”。原因很简单：画图的人把“与系统交互的东西”直接等同于“人”。Actor 的定义确实是“提供或接收系统信息的人或系统”，但这个“系统”指的是外部系统，不是系统内部的组件。数据库、界面、打印机都是系统内部的实现细节，它们出现在用例图里，等于把设计阶段的元素提前塞进了需求阶段。

解决办法是回到需求文档做一次筛选：这个“角色”是不是由人来操作？是不是在系统边界之外？两个问题都是否，就删掉。数据库显然是边界内，删。登录界面是系统的一部分，删，登录这个动作可以作为一个用例挂在真实角色下面。真要和外部系统交互，比如对接校园一卡通认证，那才画成一个 Actor，并且注明是外部系统。

提示：用例图的边界框一定要画。不画边界框，看图的人分不清哪个是系统内、哪个是系统外，这类错误就特别容易混进来。

5.2 现象：类图画了一堆方框，连线全是光秃秃的实线

类图上有五个类，五条线，每条线两端都没有数字，也没有箭头。原因有两个：一是不知道多重性该填什么，索性不填；二是工具里设多重性要多点两下，图省事跳过了。后果在下一阶段才显现——写建表脚本时不知道外键该放哪边，写顺序图时不知道一个对象要遍历几个对象。

解决办法是把多重性当成必填项，画完一条关联立刻双击设。判断多重性的方法是从业务语义出发问两个问题：A 的一个实例能对应几个 B？B 的一个实例能对应几个 A？两个答案合起来就是多重性，顺序不能反。举例子，一个书目对应几册书？多册，0..。一册书对应几个书目？一个，1。所以是 Title 1 对 Item 0..。这个问答过程慢，但不会错。

还有一个细节：多重性要写 0..* 还是 1..，取决于新数据的状态。新书入库前只有书目没有册，所以 Item 端是 0..；如果业务规定必须先编目再上架，那可以写 1..*。这个区别在类图上只是一个字符，在代码里是一个空集合判断。

5.3 现象：顺序图里“借书者”和“借阅界面”画成同一条生命线

图上只有四条生命线：借书者、系统、数据库、管理员。借书者的箭头直接指到“系统”这条线上，中间没有界面，也没有控制器。原因是为了让图看起来简洁，把“人”和“人操作的界面”合并了。合并之后，消息的接收方变成一个抽象的大对象，后面无论怎么拆都拆不出控制器的职责。

解决办法是把边界对象、控制对象、实体对象分开画。边界对象是界面，负责收输入和显示；控制对象是控制器，负责编排流程；实体对象是 Borrower、Item、Loan，负责数据和业务规则。借书这条流程里，借书者只和界面交互，界面只和控制器交互，控制器才去调实体。三层分开，每条消息的接收方都是明确的类，图才有可执行性。

这个分法在 Rose 里对应的是 Boundary、Control、Entity 三种构造型，画的时候给类加上构造型标记，评审时一眼能看出层次。

5.4 现象：需求分析报告里混进了 VB 代码和数据库表结构

翻到第三章，突然出现一段CREATE TABLE t_loan (...)，再翻两页，贴了一段 VB 的按钮点击事件。原因是写报告的人把设计文档和需求文档合并成一份交了。需求分析报告回答的是“系统要做什么”，设计文档回答的是“系统怎么做”。表结构、代码、接口定义都属于后者，提前放进来会让文档的评审基准混乱——评审人不知道该按需求完整性打分，还是按设计合理性打分。

解决办法是划一条硬线：需求分析报告里只出现三类内容，用例、用例描述、领域类图。领域类图只写到属性和操作的名称，不写类型和可见性；顺序图只画概念层的交互，不画方法签名。实现模型（构件图、部署图）放在最后一章，明确标注“实现视图”，和前面的需求视图分开。

真要在报告里体现技术选型，用一句话带过就行，比如“实现阶段选用 VB 语言，由建模工具生成类框架”，不要贴代码。

5.5 现象：Rose 生成代码时导出一堆空壳，方法体全是空的

点了生成代码，VB 文件出来了，打开一看，类声明、属性声明、空方法都在，但没有一行业务逻辑，连数据库连接都没有。原因有两层：第一层是认知问题，Rose 这类工具生成的是框架，不是实现，它只能把类图的静态结构翻译成代码结构，翻译不了业务逻辑；第二层是配置问题，生成前没有在 Project Specification 里设定默认语言、默认属性类型、代码目录，生成出来的东西类型全是 Variant。

解决办法分两步。生成前，打开 Tools 菜单下的项目配置，把语言设为 VB，把默认属性类型设成 String 或具体类型，指定输出目录。生成后，把生成的框架当成骨架用，保留类声明和属性，方法体自己补。补的时候按顺序图的消息序列写，控制器里那几条消息对应几个方法调用，一条一条填。

注意：Rose 2003 生成 VB 代码时，对中文注释的支持不稳定。类文档里写中文，生成出来可能是乱码。稳妥做法是类文档用英文短句，业务注释在生成后手工补。

6. 构件图到 VB 骨架：交付前我会跑一遍的五项核对

实现模型这部分，报告给的信息不多，只说构件图显示软件构件的分布和依赖关系，部署图描述运行时特性，Rose 2003 能依据构件图生成代码框架，语言选 VB。落到实操，构件图我一般划四个：借阅构件（借书、还书、续借）、查询构件（书目检索、借阅历史）、管理构件（读者管理、图书管理）、数据访问构件。前三个依赖第四个，第四个依赖数据库驱动，依赖箭头从使用者指向被使用者，别画反。

部署图三个节点：客户端、应用服务器、数据库服务器。客户端跑界面，应用服务器跑业务构件，数据库服务器存数据。节点之间的连接标注协议，客户端到应用服务器标 HTTP，应用服务器到数据库标驱动连接。这两条连线不标，部署图就只是一张方框图。

代码生成本身没什么玄学，配置对了就是几分钟的事。生成出来的 VB 类骨架长这样，属性来自类图，方法体是空的，要自己填：

' Rose 2003 依据类图生成的 VB 类框架（节选，业务注释为后补） ' 类名：Loan 对应类图中的借出类，映射表 t_loan Option Explicit ' 借出编号，主键，由编号规则生成 Public LoanId As String ' 借出日期，办理借书时写入 Public BorrowDate As Date ' 应还日期，默认借出日期加 30 天，可在系统参数里改 Public DueDate As Date ' 归还日期，未归还时为空，用 Variant 承载 Null Public ReturnDate As Variant ' 状态：1 借出中 2 已归还 3 逾期 Public Status As Integer ' 创建借出记录，入参为借书证号与图书条码号 Public Function Create(ByVal borrowerId As String, ByVal itemId As String) As Boolean ' 资格校验与可借校验在控制器层完成，此处只组装记录 Me.LoanId = NewId() Me.BorrowDate = Now Me.DueDate = DateAdd("d", 30, Me.BorrowDate) Me.ReturnDate = Null Me.Status = 1 Create = True End Function

这段骨架里，属性声明和范围声明是工具给的，Create的方法体是手写的。参数说明两句：borrowerId和itemId都是字符串，因为借书证号和条码号可能带前导零，用数值类型会丢零；DueDate用DateAdd算，不要在代码里写死 30，应还天数要读系统参数，不然改规则就得改代码。

交付前我会跑一遍五项核对：角色是不是都在系统边界外、每个用例有没有对应的用例描述表、类图的每条关联有没有多重性、顺序图的消息接收方是不是具体类、构件图的依赖箭头方向对不对。这五项里任何一项过不了，报告就先别交。从那以后我每次交建模文档前，都会拿一份用例描述表去反查类图和顺序图，能对上的才留下，对不上的要么删图要么补描述。希望帮到你。

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