企业官网建设流程全解析

简介：这是一份UML面向对象分析与设计课程的大作业资料，围绕“简易教学管理系统”开展完整建模，面向计算机、软件工程等专业学生，适合用于课程设计或期末项目参考。文档从需求陈述入手，覆盖选课管理和成绩管理两大业务，细化课程表录入、学生选课注册、课程与师生信息查询、成绩录入统计与报表生成等场景，并逐步绘制顶层用例图、选课管理用例图、成绩管理用例图、顺序图、课程管理对象类图、人事信息对象类图、学生选课登记状态图、活动图、组件图和部署图，同时介绍Rational Rose建模工具的使用与正向工程思路。资源包为单个docx文件，压缩后约3.44MB，包含建模步骤、任务分解和模型图例，便于修改复用。目前已有185人学习下载，是UML实践与课程设计的实用参考。通过仿照其中的模型，读者可以理解UML主要图型的应用场景，掌握用Rational Rose完成需求建模、架构建模及设计文档撰写的方法。

1. 为什么说UML文档不是画图，而是让设计矛盾提前暴露

项目评审会上最常见的翻车现场，不是你代码写得不行，而是你拿着用例图和类图讲设计，开发问了一句「这个虚线箭头到底是不是 new 了一个对象」，你答不上来。更常见的情况是，图很好看，评审也过了，代码写了一个月后发现两个模块的依赖关系完全不是当初画的那样，返工成本直接翻倍。UML面向对象分析与设计这份文档，解决的就是这个问题：在动手写代码之前，把类之间的关系、对象之间的协作、状态之间的迁移用标准化的图形语言固定下来，让设计矛盾在评审阶段就暴露，而不是等代码跑起来才爆雷。

这份文档适合三类人：一类是被要求补交设计文档、之前靠脑子硬记代码结构的开发者；一类是准备软考中级、需要系统掌握UML建模规则的考生；还有一类是需要在项目中做设计评审、却总被无休止的讨论拖垮的架构师。核心不是学会画几种图，而是搞清楚每种图回答什么问题、画到什么粒度、什么时候不值得画。

2. UML静态结构建模：类图、包图与对象图的高频用法和判读标准

2.1 类图箭头含义：先把六种关系一次性分清

类图是UML里出镜率最高、评审时被追问最多的一种图。很多项目文档里画了一堆类图，但箭头全是乱的，实线虚线混用，菱形箭头乱飞。类图的关系有六种，每种对应明确的代码语义，搞混了评审必被怼。

判读关系最简单的办法不是看图形，而是问两个问题。第一个问题：如果A类删掉了，B类还能不能用？能，是依赖或聚合；不能，是组合。第二个问题：这个关系是临时的还是长期的？方法参数里用了一下，是依赖；作为类的字段持有，是关联。这两个问题答完，画出来的类图基本不会犯大错。

实际项目里最常见的错误是把依赖画成关联。比如一个OrderService调用了EmailSender的静态方法，只是发送一封邮件，这明显是依赖关系，虚线箭头就够了。但很多人习惯性地画成实线关联，导致评审时被问「OrderService 为什么要持有 EmailSender 这个字段」——它根本不持有，只是临时调用。

2.2 包图：模块边界画清楚，依赖方向才可控

类图画到几十个的时候，评审已经没法看了。这时候需要用包图把类的归属和依赖方向理清楚。包图本质上是类图的高层聚合视图，但不是把类图缩小，而是用包作为组织单元，表达包与包之间的依赖关系。

画包图有一个硬性要求：不允许循环依赖。A包依赖B包，B包依赖C包，C包又依赖A包，这样的模块结构在代码评审时一定会被挑战。我一般画包图之前先列一张依赖方向表，把「谁依赖谁」写成文字，确认没有环再落图。画包图时还要注意一个粒度问题：包下面要不要继续展示类？展示到什么深度？

常见做法是包内部只显示核心类，也就是被外部引用的那些类，实现细节类不画出来。比如用户模块的包图，只画UserService、UserRepository这个层次的对外接口类，UserValidator这种内部工具类不要出现在包图里，否则图面信息过载，失去抽象的意义。

2.3 对象图：什么时候值得画，什么时候是浪费时间

对象图是类图的实例快照，展示某一时刻各个对象的具体状态和关系。它在文档里的地位有点尴尬——画了显得专业，但实际价值有限。对象图真正有价值的使用场景只有两个：一个是描述复杂数据结构在运行时的形态，比如订单系统里订单、订单项、商品三者关联关系的瞬间快照；另一个是配合时序图说明某个关键场景下的对象协作关系。

其他情况下画对象图，基本是在凑篇幅。评审专家看对象图时关注的是「这个快照和类图的定义是否一致」，如果类图里定义的是聚合关系，对象图里画成了独立的两个对象，而且没有归属连线，那就是自相矛盾。所以在交付文档里，对象图应该出现在类图之后，作为类图关系的实例验证，而不是单独成章。画对象图时注意：对象名要带下划线，格式是对象名:类名，类名可以省略，但连线上要标注具体的属性值，这样才能表达「快照」语义。

3. UML动态行为建模：用例图、时序图与状态图怎么选怎么画

3.1 用例图不是流程图：边界和参与者才是核心

用例图是动态行为建模的入口，但它也最容易被画错。很多人把用例图画成了流程图，把「用户点击登录按钮→系统校验密码→跳转主页」这种操作步骤画进去，这是概念性错误。用例图回答的问题是「谁可以用系统做什么」，不是「系统内部怎么做」。

画用例图的第一步是圈系统边界。一个方框代表系统，方框外是参与者（Actor），方框内是用例（椭圆）。这一步看起来简单，但边界画在哪里直接决定用例粒度。比如一个电商后台，参与者和用例的关系是：顾客使用下订单、支付、查询订单；运营人员使用商品上架、订单审核、数据导出。如果把「支付」拆成「发起支付」「支付回调」「支付结果查询」三个用例，粒度就太细了，评审时会被告知这是功能点列表，不是用例图。

判断用例粒度是否合适的标准：一个用例能否给参与者带来可观测的、完整的业务价值。不能带来完整价值的，不要画成用例。用例图里还包括include和extend两种关系，include表示一个用例一定会包含另一个用例，比如「下订单」一定会包含「校验库存」；extend表示条件触发的扩展，比如「下订单」在库存不足时扩展出「触发缺货登记」。这两种关系实际画的时候要克制，能用文字说明的不要强行用箭头表达。

3.2 UML中的动态结构图有哪些：时序图、通信图、状态图、活动图

热搜词「uml中的动态结构图包括」对应的答案，在UML规范里是指交互图和行为图这个大分支。具体拆开，动态结构图包括时序图（顺序图）、通信图（协作图）、状态图、活动图，这四种图分别回答不同的问题。时序图强调消息的时间顺序，通信图强调对象间的连接关系，状态图强调单个对象的状态迁移，活动图强调业务流程的流转。

实际项目文档里，时序图的使用频率远高于其他三种。原因很简单：评审时讨论「先做什么后做什么」「谁调用谁」最直观的表达方式就是时序图。活动图在业务流程需要跨角色、带分支判断时才有价值，比如审批流、异常处理流。通信图由于时序图已经覆盖了大部分场景，现在项目文档里很少单独出现，如果要用，也是在时序图之外需要强调对象间的静态连接关系时。

状态图是最容易被忽视但最能救命的一种图。它适用于单个对象状态较多的场景，最典型的是订单状态机：待支付、已支付、已发货、已完成、已取消、退款中、已退款。这种图不画，代码里就是一堆散落的状态判断，评审时没人能看出状态迁移是否完整。而活动图，我一般只在用例的流程分支复杂时附带补充，交互流程简单时直接用文字描述就够了。

3.3 时序图画到什么粒度：消息是协作的对象间传递，不是函数调用清单

时序图画错最多的地方，是把时序图画成了接口调用顺序表。一个箭头一个接口方法，每个方法回调都画出来，结果一张A4纸挤了几十个箭头，评审时没人看得下去。正确的画法是：消息代表对象之间的协作行为，不是函数签名。同一模块内部的私有方法调用、字段赋值这类细节，不该出现在时序图上。

画时序图我习惯遵循三个原则。第一个原则：只画跨越对象边界、有业务含义的消息。比如OrderService调用InventoryClient的checkStock，这是跨对象协作，值得画；但OrderService内部先调this.validate()再调this.calculatePrice()，这是内部逻辑，不值得画。第二个原则：激活条要画对。每个对象接收消息后，处理期间画一条竖线的激活条，消息箭头必须指向激活条的顶端，返回消息用虚线箭头，可省略返回值但调用关系必须清晰。第三个原则：能用片段（alt、opt、loop）表达的不要拆成多条分支。比如登录成功和失败两种返回，用alt片段框起来，比画两条完整路径清晰得多。

时序图里还有一个常被忽略的细节：生命线的命名。生命线框里的格式是「对象名:类名」，对象名可以省略，但类名不能错。评审时被指出「这个生命线叫userService，但类名写成了UserService的大小写不一致」虽然是小问题，但暴露了文档不严谨。

3.4 状态图的边界：状态多才需要画，别给简单对象设计状态机

判断要不要画状态图，我有个简单的量化标准：一个对象在业务生命周期内是否有超过五个不同的状态，且状态之间存在依赖顺序。订单、支付单、审批单这种对象必须画；而一个User对象只有「正常」和「停用」两个状态，画状态图纯属浪费。

画状态图要注意三个点。第一，初始状态用一个实心圆表示，终止状态用实心圆外加一个圆环，这两个标记不能漏。第二，迁移弧线上标注「事件[守卫条件]/动作」，比如「支付成功[金额已校验]/更新订单状态」，这是状态图的规范写法。第三，状态图要能回答「状态是否会出现死循环」「是否存在不可达状态」这两个问题，评审时这两个问题几乎必问。

4. 把设计落成代码：从图到代码骨架的映射路径与文档组织

4.1 用PlantUML快速生成可评审的类图和时序图

实际项目中画UML图，我不建议用Visio或 ProcessOn 一笔一笔画。效率太低，而且改版时维护成本高。我更推荐用PlantUML这种文本化建模工具，图是代码生成的，改代码就改图，特别适合评审前快速迭代。

一份可运行的PlantUML类图代码如下所示：

@startuml ' 定义类的属性与方法 class Order { - orderNo : String - totalAmount : BigDecimal - status : OrderStatus + createOrder(items : List<OrderItem>) : Order + cancel() : boolean } class OrderItem { - skuId : String - quantity : int - price : BigDecimal } class User { - userId : String - name : String } ' 组合关系：Order 销毁时 OrderItem 一并销毁 Order *-- OrderItem ' 关联关系：Order 持有 User 引用，User 可独立存在 Order --> User ' 依赖关系：Order 在方法中使用 OrderStatus Order ..> OrderStatus @enduml

这段代码里，*--表示组合关系，-->表示关联关系，..>表示依赖关系。-开头的是私有属性，+开头的是公有方法。运行 PlantUML 生成PNG或SVG的命令很简单：

plantuml -tsvg order_class.puml -output ../docs/

生成后的SVG文件缩放不失真，可以直接放进Word文档。PlantUML的图形语法和UML规范并不是完全一一对应，使用前最好确认一下你用的符号生成出来的图形是否正确，特别是箭头类型。这条命令会输出一个order_class.svg到docs目录，时间约1～2秒。改类名、加属性、换关系类型，改完重新执行一次即可，这是文本化建模最大的节省。

4.2 从类图到Java代码骨架的三个映射规则

类图评审通过后，下一步是把它变成代码骨架。这个过程有三个映射规则。第一个规则：类图中的属性和方法一对一映射为Java的字段和方法签名，关系映射到成员引用或方法参数。第二个规则：组合关系*--在代码里体现为直接new字段，并在构造函数里初始化，容器销毁时内容对象没有外部引用来维持生命周期。第三个规则：依赖关系不落字段，只出现在方法参数、局部变量或静态调用里。

以Order和OrderItem为例，映射后的Java骨架代码是：

public class Order { private String orderNo; private BigDecimal totalAmount; private OrderStatus status; // 组合关系：Order 创建 OrderItem，同生命周期 private List<OrderItem> items = new ArrayList<>(); public void addOrderItem(OrderItem item) { this.items.add(item); } } public class OrderItem { private String skuId; private int quantity; private BigDecimal price; }

这里Order直接持有List<OrderItem>并在自身初始化，体现组合关系。如果改成聚合关系，OrderItem应该由外部创建后通过构造函数传入，而不是在Order内部new。这个区别在代码审查时一眼就能看出来。评审阶段如果发现代码和类图不一致，通常不是代码写错，而是当初类图的箭头画错了。所以拿到代码后反向核对类图，也是验证设计质量的一种手段。

4.3 文档怎么组织：docx里每个图都要配设计说明，而不是光堆图

一份合格的UML设计文档不是图集。每张图都必须在图前有一段文字，说明这张图解决什么问题、核心设计决策是什么、有哪些备选方案为什么没选。图后要附一段说明，解释图里容易误解的地方。比如类图画了组合关系，就要说明「为什么OrderItem不能独立存在，如果将来要支持单独管理赠品，这个组合关系是否要改成聚合关系」。这种设计说明比图本身更有评审价值。

我一般组织一份UML设计文档的结构如下表：

这个结构里最关键的是第五部分。很多文档把约束藏在代码里，但评审专家明确要求把约束写出来。比如「订单模块不得直接访问用户模块的数据库表」「消息发送必须走MQ不允许同步调用」，这类约束写在文档里，代码评审时才有依据。

5. UML建模常踩的6个坑：图是对的，评审照样翻车

5.1 用例图画成了业务流程，被质疑「这不是用例」

现象：用例图里画了一个大椭圆，里面写了一串操作步骤「用户输入账号密码→系统校验→系统返回结果」，评审专家直接说这不是用例图，这是流程图。

原因：把用例当成了功能步骤，忘了用例是参与者与系统交互的一个完整目标。「登录」才是用例，「输入账号密码」是登录的基本流，不是用例本身。

解决：用例图只画椭圆和参与者连线，操作步骤写进用例描述表的「基本流」里。如果一个用例的基本流超过四步，考虑拆分子用例或用活动图表达流程。

5.2 类图箭头全是关联，依赖和关联傻傻分不清

现象：整个类图二十几个类，所有关系都是实线箭头，评审时被问「A和B之间到底是长期持有还是临时使用」，答不上来。

原因：画图时图省事，统一用实线箭头，没有区分瞬时依赖和长期关联。这种图在代码落地的指导价值很低，因为依赖关系映射为方法参数，关联关系映射为字段，两者生成的代码完全不同。

解决：画完类图后做一次自检，逐个关系回答「这个类是对方的字段，还是只在方法里用了对方」这个判断。答案不明确的关系，说明类的职责边界还不清晰，先改设计再改图。

5.3 时序图画成方法调用清单，一张图全是激活条

现象：时序图里几十条消息，每个setter方法都画一个箭头，整个人物生命线上密密麻麻全是激活条，评审时超时也没讲完。

原因：没有取舍消息的粒度，把代码实现细节当成了对象协作消息。评审专家关心的不是方法名，而是业务步骤和对象职责边界。

解决：删除所有内部方法调用消息。输出评审版时序图时，用alt、loop片段压缩分支和循环。如果删完后一张图能控制在十二三条消息以内，说明粒度合适，超过就再拆一张。

5.4 状态图状态太多，每个状态都是「已XX」，没有迁移条件

现象：订单状态图里画了十来个状态，但每条迁移弧线上只有事件名，没有守卫条件和动作。

原因：把数据库里的状态字段直接搬到了图上，没有做抽象。实际代码里的状态迁移往往依赖前置条件，比如「已发货」能不能迁到「已完成」要满足「买家已确认收货」这个条件。

解决：每种状态迁移至少标注「事件 + 守卫条件 + 动作」三元组。如果守卫条件过于复杂，考虑把条件提取成业务规则对象，避免状态图变成代码逻辑的复读机。

5.5 文档只有图没有字，评审全靠作者现场讲

现象：交付的docx文档里全是图，每张图下面没有文字说明，其他成员离线评审时根本看不懂，只能拉着作者讲。

原因：写文档的人默认读者跟自己一样了解上下文，省了设计说明。但一份设计文档的寿命往往比作者在项目组的时间长，半年后新来的开发要能靠文档上手，文字说明比图更关键。

解决：每张图配一段设计说明，至少三百字，写清楚为什么这么设计、有哪些取舍、如果需求变化这张图哪里要改。没有说明文字的图，在评审时会被直接驳回。

5.6 不按UML规范画图，符号全靠个人习惯

现象：类图里的依赖箭头和关联箭头混用，组合菱形画成了聚合，状态图的初始状态点画成了圆圈，评审专家指出符号不规范，文档被要求返工。

原因：工具的限制或个人的随意习惯导致不规范的标注。很多画图工具的UML符号库不全，有人就用近似符号代替，结果图面意思完全变了。

解决：用PlantUML这类文本化工具时，符号等价关系是明确定义的，不会出现手动画图时「画得不太像」的问题。同时，交付前用UML规范对照表自查一遍，确认不需要的细节，不要凭记忆去画箭头。

6. 文档交付前的自检与验收：三遍读图法一个实用动作

评审前我习惯做三遍检查，每遍只看一类内容，不混合检查，效率最高。第一遍只看关系：所有类图的箭头方向、依赖方向、包图的依赖是否形成环。第二遍只看时序：所有时序图的消息顺序是否和用例的基本流一致，有没有漏掉备选流的分支。第三遍只对照代码：挑三个核心场景，跟着代码执行路径反向核对时序图和类图，如果代码和数据文件不一致，这可能是唯一的发现问题的入口。

文档交付前还有一个实用动作：把核心几类图都导出SVG而不是PNG。SVG格式在Word里缩放不模糊，投屏评审时清晰度好，任何一个细节放大都能看清。PlantUML 默认导出PNG，加-tsvg参数即可输出SVG。这个习惯让我在评审现场免过好几次尴尬——被要求放大看某个关联关系的箭头时，SVG放大后依然清晰，PNG早就糊成一片了。

最后提醒一个原则：UML文档的价值在于设计决策的显性化。代码解决的是「怎么实现」，UML文档解决的是「为什么这么实现」以及「哪些方案被否定了」。画图前先想清楚这两点——这套设计有哪些取舍、有什么明显的不能做的约束，然后才落笔。把「不能做什么」写清楚，比干巴巴贴一堆图更能帮到下一个接手代码的人。希望帮到你。

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