简介面向计算机专业学生与软件工程入门者的UML建模需求分析文档围绕图书管理系统展开完整建模流程适合课程设计、实验报告与建模练习参考。内容从借书者、图书管理员、系统管理员三类角色切入依次梳理用例模型、类图静态结构、顺序图与活动图等动态交互以及构件图和部署图的实现视图并给出Item、Title、Loan、Reservation、Borrower等核心类的职责划分思路。压缩包共1个doc文件约265KB体量轻便便于打印或二次编辑成自己的报告框架。已有2496人学习下载说明其在同类课程作业中具备一定参考价值。读者可据此掌握从需求描述到UML图落地的组织方式理解角色—用例—类—交互—部署之间的衔接也能借鉴报告章节安排与建模表达减少从零搭建文档时的反复试错。1. 课程设计答辩现场最容易被问住的不是功能多不多而是“你这个类图的箭头为什么指向这边”拆过几份 UML建模 的图书管理系统需求分析报告有个反直觉的现象图越漂亮越经不起追问。这份报告的价值不在图本身而在它把借书者、图书管理员、系统管理员三条需求线一路翻译成用例图、类图、顺序图、构件图的完整推演链条中间没有断层。它适合正在做课程设计、需要交一份能自圆其说的需求分析文档的人也适合想补一遍 UML建模 基本功的开发者——类图、用例图、顺序图这三张图几乎每个管理系统都要画一遍。下面按图的顺序拆角色怎么划边界、类怎么连多重性、消息怎么排时序、哪些地方最容易翻车。2. 用例模型三个角色划边界用例粒度决定后面所有图的上限2.1 角色识别边界划错后面的图全白画用例模型的第一步不是画图是确定 Actor。报告里把角色定为借书者、图书管理员、系统管理员三类这个划分看着朴素实际是有讲究的三类角色的权限来源不同借书者的权限来自借书证图书管理员的权限来自岗位系统管理员的权限来自系统内置账号。权限来源不同意味着校验逻辑、数据可见范围、操作入口都不一样必须在用例层就分开。常见的误判是把“读者”当成一个角色。读者里既有能借书的也有只能查目录的混成一个角色后面写用例描述时前置条件就没法写。报告用“借书者”这个词指向的是“有借阅资格的人”这个措辞比“读者”准确。如果系统对外开放匿名查询可以再补一个只读角色但报告没写别自己加戏加一个角色就要多一套权限校验课程设计的篇幅撑不住。图书管理员和系统管理员之间的边界也要说清楚。图书管理员是系统的主要使用者负责借书处理和还书处理读者预定的图书借出给预定者之后还要取消这条预定记录——这三件事都是业务操作。系统管理员管的是读者信息、图书信息、系统状态维护属于基础数据维护和运行保障。两者的区别在于图书管理员动的是“业务流水”系统管理员动的是“主数据”。这条边界一模糊类图里就会出现“管理员类”一个类扛下所有操作的情况后面拆顺序图时找不到该由谁接收消息。角色权限来源核心职责不该做的事借书者借书证查个人信息、查图书、预定、借阅、归还修改图书信息、冻结账号图书管理员岗位借书处理、还书处理、取消预定增删读者账号、改系统参数系统管理员系统内置账号读者信息管理、图书信息管理、系统状态维护代替管理员办理借还这张表不是交付物的一部分但它是我画用例图之前必写的一页草稿。角色边界定下来用例图里的连线基本就自动出来了剩下的只是取舍粒度。2.2 用例粒度借阅和借书处理必须拆成两个用例用例命名的基本规则是“动词名词”但真正难的是粒度。报告里借书者一侧有五个用例查询个人信息、查询图书信息、预定图书、借阅图书、归还图书图书管理员一侧有借书处理、还书处理、取消预定。这里面最容易翻车的是“借阅图书”和“借书处理”这一对——很多人会把它俩合并成一个用例理由是“都是借书”。合并的后果在顺序图上立刻暴露用例只有一个但触发它的人有两个一个是发起请求的借书者一个是执行办理的管理员顺序图里第一条消息该从哪条生命线发出说不清。拆成两个用例之后借书者的“借阅图书”是提交请求图书管理员的“借书处理”是受理并落库前者可以被后者包含也可以独立触发自助借还机场景语义是干净的。用例之间的关系报告没有展开但落地时至少要处理两种。include 用于提取公共子流程比如“预定图书”“借阅图书”都要先“查询图书信息”可以把查询抽成被包含用例避免在多个用例描述里重复写查询逻辑。extend 用于可选扩展比如“借阅图书”在图书已借出的情况下可以扩展出“预定图书”扩展点是“图书不可借”。这两种关系的区别不在图上在用例描述的文字里include 是一定会执行的分支extend 是满足条件才执行的分支。画反了评审时一眼就能看出来。用例编号用例名主参与者关系UC-01查询个人信息借书者—UC-02查询图书信息借书者被 UC-03、UC-04 包含UC-03预定图书借书者include UC-02UC-04借阅图书借书者include UC-02可扩展 UC-03UC-05归还图书借书者—UC-06借书处理图书管理员受理 UC-04UC-07还书处理图书管理员受理 UC-05UC-08取消预定图书管理员图书借出给预定者后触发2.3 用例描述表把图落到可验收的文字用例图画完只能说明“有哪些功能”说明不了“功能怎么算完成”。报告里这块是薄弱环节只列了用例没写描述。补一张用例描述表成本很低收益很大——后面写顺序图时消息顺序直接从基本流里抄。以“借阅图书”为例描述表至少包含用例编号、参与者、前置条件、基本流、异常流、后置条件六项。前置条件是校验逻辑的来源借书者身份有效、无超期未还、未达借阅上限。这三条直接对应类图里 Borrower 的属性和操作——状态字段、可借数量字段、校验资格方法。异常流是顺序图里分支消息的来源身份被冻结走一条分支图书已借出走另一条分支。项内容用例编号UC-04用例名称借阅图书参与者借书者主、图书管理员辅前置条件借书证有效无超期未还记录当前借阅数未达上限基本流1 借书者提交借书证号与图书条码 2 系统校验借书者资格 3 系统校验图书可借状态 4 系统生成借出记录 5 系统更新图书状态 6 返回借阅成功异常流2a 资格校验失败提示原因并终止3a 图书已借出提示可预定并转 UC-03后置条件生成一条借出记录状态为借出中图书条目状态置为已借出提示异常流编号用“步骤号字母”的写法2a、3a和基本流一一对应。这个约定在评审时很吃香因为读的人能立刻定位到是哪一步出的问题。3. 静态模型Item、Title、Loan、Reservation、Borrower 五个类怎么连3.1 五个核心类的职责划分报告列出的核心类是 Item条目、Title标题、Loan借出、Reservation预定、Borrower借书者信息。这五个类不是随便挑的它们对应了图书管理业务里两个最容易混淆的概念书目和册。Title 是书目代表“这本书是什么”属性是 ISBN、书名、作者、出版社、分类号、价格。Item 是册代表“图书馆里有这一本实物”属性是条码号、状态、馆藏位置。一本书目可以有多册一册书可以被借多次。把这两个概念合成一个类会出现什么后果借出记录没法准确指向“哪一册被借走了”只能指向“哪本书被借走了”同一本书有五个副本时归还时不知道销哪一条账。这是图书管理系统建模里最经典的一个分水岭。Loan 是借出记录属性包括借出编号、借出日期、应还日期、归还日期、状态。它是业务流水的载体一条记录对应一次借还。Reservation 是预定记录属性包括预定编号、预定日期、状态、通知标记。Borrower 是借书者信息属性包括借书证号、姓名、类型学生/教师/校外、状态、可借数量。类核心属性核心操作TitleISBN、书名、作者、出版社、分类号、价格新增书目、修改书目、按条件查询Item条码号、状态、馆藏位置借出、归还、报废Borrower借书证号、姓名、类型、状态、可借数量校验资格、冻结、解冻Loan借出编号、借出日期、应还日期、归还日期、状态创建、续借、归还Reservation预定编号、预定日期、状态创建、取消、到期提醒属性的可见性也要标。借书证号这类主键用 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 都用关联因为借出记录是独立实体不随某一方删除而消失——真要删也是逻辑删除改状态字段。关系多重性类型说明Title — Item1 : 0..*关联一个书目多册新书可能未编目Item — Loan1 : 0..*关联一册书多次借出保留历史Borrower — Loan1 : 0..*关联一个借书者多条借出记录Borrower — Reservation1 : 0..*关联一个借书者多条预定Reservation — Title* : 1关联同一书目可排队预定还有一条隐含约束值得写进类图注释同一个 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 返回借出编号也是两条。序号发送方接收方消息说明1借书者借阅界面提交借书证号、图书条码同步2借阅界面借书控制器borrow(borrowerId, itemId)同步3借书控制器BorrowercheckQualify()同步4Borrower借书控制器返回资格结果返回5借书控制器ItemisAvailable()同步6Item借书控制器返回可借标志返回7借书控制器Loancreate(borrowerId, itemId)同步8Loan借书控制器返回 loanId返回9借书控制器ItemsetStatus(BORROWED)同步10借书控制器借阅界面返回借阅结果返回这十条消息里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 的一个实例能对应几个 BB 的一个实例能对应几个 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应还天数要读系统参数不然改规则就得改代码。交付前我会跑一遍五项核对角色是不是都在系统边界外、每个用例有没有对应的用例描述表、类图的每条关联有没有多重性、顺序图的消息接收方是不是具体类、构件图的依赖箭头方向对不对。这五项里任何一项过不了报告就先别交。从那以后我每次交建模文档前都会拿一份用例描述表去反查类图和顺序图能对上的才留下对不上的要么删图要么补描述。希望帮到你。本文还有配套的精品资源点击获取
