企业官网建设流程全解析

1. 这门课到底在讲什么——OOA的定位与核心价值

1.1 为什么软件工程课程里绕不开"面向对象分析"

西安电子科技大学计科、软工专业的同学，看到"面向对象分析"这门课，第一反应往往是"到底背什么"或者"到底画什么图"。我当年复习的时候也是一头雾水，感觉教材翻到这一章，突然从一堆代码用例跳到了画图题，整章全是抽象的"模型""关系""实例"，背了半天还是不知道考试会怎么考。后来真正把这门课理顺了才明白，它并不是一门独立的"画图课"，而是整个软件工程课程里承上启下的核心方法：前面学了需求工程、结构化分析，后面会学面向对象设计、架构设计，OOA正好站在"需求"和"设计"的交界处，负责把用户那些口语化的、零散的诉求，翻译成一套规范、可验证、能被后续设计直接使用的"分析模型"。

说得直白一点，面向对象分析要解决的，是"别人说了个需求，你怎么把它变成大家都认可的文档和图纸"这个问题。很多人觉得写代码才是硬功夫，建模是花架子，但实际到了项目里，需求一变，代码全改，然后相互甩锅的情况，多半是前期没有一套足够清晰的分析模型。OOA的价值不在于图本身画得多漂亮，而在于它强迫你在写第一行代码之前，把"系统里有哪些对象、它们之间怎么协作、状态怎么变化"这三件事想清楚。这也是为什么国内外软件工程的教材里，无论怎么改版，面向对象分析都是必讲的重头戏。

1.2 从结构化到面向对象：分析思路的一次升级

学过结构化分析的同学应该清楚，传统思路是"功能分解"，先画数据流图，把系统按数据流动切成一个个加工过程。这套方法在业务流程很清晰、功能很稳定的场景下是有效的，但一旦需求频繁变化、系统复杂度升高，数据流图很容易被改得面目全非。面向对象分析换了个思路：抓住系统里"谁"在做"什么事"，把数据和操作绑定在一起形成对象，系统被理解成一组对象在互相协作。

这个转变带来的最大好处是"稳定性"。业务流程会变，但业务里面的核心对象相对稳定。拿图书馆管理系统举例，今天规定读者可以借5本书，明天改成借10本，结构化分析可能要把"借书"这个加工过程全改一遍；面向对象分析只需要调整Book对象和Reader对象的关联约束，两本图的改动量完全不同。OOA的基本策略就这样确立起来：先不管细节功能怎么排，先找对象，再分析对象之间的关系，最后用动态模型补充对象状态和交互过程。

1.3 OOA最终要产出一份什么样的"分析模型"

课上老师反复强调，面向对象分析要建立的不是一个图，而是一套"模型"，通常包含三大块：

• 用例模型：回答"系统为谁提供什么服务"，对应参与者和用例，是需求分析的外壳；
• 静态模型：回答"系统由哪些对象组成，它们之间的关系是什么"，对应类图和对象图，是整个分析模型的核心骨架；
• 动态模型：回答"对象在什么条件下做什么事、状态怎么跳转、对象之间怎么交互"，对应状态图、活动图、顺序图和协作图。

很多同学复习时把这三块割裂开，画用例图的时候只写参与者框框，画类图的时候又凭空捏属性方法，最后动态模型跟前面的类完全对不上。我实际复习了之后才意识到，OOA这套模型是一体的：用例描述给了你类和操作的线索，类的职责又决定了顺序图里谁先发消息，状态图里的触发事件反过来校验用例的扩展流程是否完整。所以"整理"这门课，本质上就是把这三大模型串联在一起串成一个完整故事。

2. 五块基石概念：不懂这几个词，后面全是浆糊

2.1 对象与类：别背定义，要去抓"边界"

面向对象分析里最基础的概念就是"对象"和"类"。考试常考名词解释，但我们不能只背"对象是客观世界中实体的抽象映射"这种抽象定义。我的理解是：对象是一个具体的、有状态、有行为的"东西"，类则是"同一类对象的模板"。比如"甲同学的学生证"是一个具体对象，而"学生证"这个类描述了所有学生证都应该有学号、姓名、照片这些数据，也拥有"查验有效期"这样的行为。

课程里强调的"对象三要素"非常关键：标识、状态、行为。标识就是"它是谁"（每个对象有身份，即使名字改成张三，状态变成了欠费，它仍然是那本被借走的小说）；状态是"它知道什么"（内部属性在某一个时刻的值）；行为是"它能做什么"（对外提供的服务）。判断一个候选"东西"能不能作为对象，就看它是不是同时具备这三样。考试里经常问"电话号码是不是一个对象""课程编号是不是一个对象"，答案往往取决于分析粒度，单拎一个字段一般不算对象，但如果你把它封装成"联系方式"类，包含区号、号码、类型，那就可以成为对象。

2.2 封装、继承与多态：从C++课里带过来的老朋友

这仨概念虽然C++、Java课都讲过，但面向对象分析里面它们的含义更偏"建模"层面。封装在分析阶段不是说"private修饰符"，而是说"对象内部细节对外隐藏，只暴露必要的服务"。分析模型里画出对象的属性和操作，但属性的具体数据结构、方法的具体算法一概不管，这本身就体现了封装思想——分析的目的是划清边界，不是实现细节。

继承在分析模型里体现为泛化关系，也就是"子类is-a父类"。比如"教师用户"和"学生用户"都是"系统用户"的子类，它们共享账号、姓名、角色，但教师有"布置作业"这个特有行为，学生有"选课"这个特有行为。考试里最容易扣分的点是：把该用聚合/组合的关系画成了继承，或者反过来。判断标准很简单——如果两句描述之间是"是一种"关系，用继承；如果是"包含一部分"关系，用聚合/组合。图书和图书馆是聚合（图书离开图书馆后依然存在），订单和订单项是组合（订单被删，订单项没有独立意义）。

多态在分析阶段不太好直接画出来，但它在顺序图和协作图里非常常见：同一消息发给不同类的对象，各自执行不同操作。比如"打印系统"，打印机接口有一个"print"，普通打印机实现的是A4打印，照片打印机实现的是高彩打印，发一条print消息，两种对象的行为完全不同。分析模型里只要在类图上体现了继承和重定义操作，多态已经隐含在其中了。考试不需要你写出多态实现的代码，但要能在类图和顺序图中识别出这种"同一个消息，不同对象有不同反应"的过程。

2.3 关联、聚合与组合：关系比属性更容易让人栽跟头

类图里最核心的就是关系。我复习的时候给关系分成了三个层级，帮助理解：第一层是依赖，最弱，代码里只是"用到过"；第二层是关联，表示结构上的连接，比如"读者"关联"借阅记录"，两者相对独立；第三层是聚合/组合，是更强的一种整体-部分关联。聚合是一般性的整体-部分，用空心菱形，组合则强调"同生共死"，用实心菱形，比如"窗口"和"按钮"通常认为是组合关系，窗口销毁按钮也没了。

考试中常给一个生活场景，让选择几种关系的组合。这种题不能想当然，要对着定义抠字眼。比如"班级由学生组成"，看上去像组合，但如果学生转学之后班级还存在，那就应该是聚合而非组合；反过来"文件夹由文件组成"，若文件允许被移动出文件夹后独立保存，也是聚合。很多同学挂在这种题目上，就是因为只看了语义像"部分-整体"，没去思考生命周期是否强约束。分析阶段不必在这个上面纠结到极致，毕竟实现时还会调整，但考试确实爱扣，把它当作一种"建模语言约束力"来理解会更舒服。

3. 三大模型怎么搭：网课常遗漏的逻辑主线

3.1 用例模型：需求的"门面"，也是OOA的入口

用例模型由三部分构成：参与者、用例、关系。参与者在模型里用小人图标表示，它不一定是"人"，也可以是外部系统、硬件设备。比如图书逾期催还系统，短信平台就是参与者，因为它从系统接收数据。识别参与者的诀窍是问两个问题：谁直接使用系统？谁从系统获取信息？凡是回答"是"的东西，大概率都要作为参与者画出来。

用例则是"参与者与系统交互完成的一件事"，语言上必须是一个动词短语，比如"借阅图书"、"查询馆藏"。很多同学画用例图时喜欢把"图书管理系统"框成一个整体，然后让读者连到"系统"，这等于没画——用例模型的粒度要按业务目标来切，而不是按模块来切。比如"借书"和"还书"就是两个用例，不要合成一个"图书流通管理"，后者太大，后面写用例描述会非常痛苦。

用例之间的关系主要有include、extend和泛化。include是包含关系：某个用例必然包含另一个用例，比如"借阅图书"总是包含"验证读者身份"；extend是扩展关系：某个用例在特定条件下会额外触发另一个用例，比如"借阅图书"在读者欠费超过额度时扩展出"处理欠费警告"。考试最喜欢让判断哪个方向画虚箭头：include从基础用例指向被包含用例，extend从扩展用例指向基础用例。这个方向我至少犯过三次错，建议直接在笔记里高亮标出。

除了用例图，还有用例描述，这是容易被忽略的得分点。用例描述不是把用例名抄一遍，而是要用文字完整讲述"主成功场景"和"扩展场景"。以"借书"为例，主场景是读者出示图书证、管理员扫描图书、系统验证读者有效、系统登记借出记录、读者带走书。扩展场景包括：读者证过期怎么办、图书状态是"已预约"怎么办。这部分是后面画顺序图和状态图的信息来源，不能偷懒只画图不写字。

3.2 领域模型：把所有对象和关系钉在纸上

静态模型主要画类图。OOA阶段画类图不追求完全覆盖所有实现细节，重点是把分析得到的"候选类"、属性、以及类间关系画清楚。类图里的矩形分三栏：类名、属性、操作。属性的写法在分析阶段通常是"可见性 属性名：类型"，可见性可以用+、-、#表示，但考试里有时为了简化，只写属性名和类型，也不扣分。

从哪儿找候选类？我总结了一个最实用的办法：先写下所有用例描述，标出里面的名词。比如"图书""读者""借阅记录""罚款""管理员"，这些名词里有一部分是参与者，有一部分是领域对象，有一部分只是属性。然后逐个筛：它有没有独立状态？有没有需要保存的数据？有没有可以被调用的行为？三个问题只要两三个回答"是"，就值得作为类保留。课程案例里常见的"登记日期""借阅期限"这类值对象，通常是属性而非独立类，但如果多个类都要复用一组信息，就要提升为类。

类图最重要的工作其实是画关系：关联的多重性、泛化、聚合组合。多重性（如1、0..、1..）表示一个类实例与另一个类实例之间的数量约束。拿图书馆系统举例，"读者"和"借阅记录"：一个读者可以拥有多条借阅记录，每条记录属于一个读者，所以读者端是1，记录端是*，写在图上就是"1 —— * 借阅记录"。这个方向在用数字标注时容易写反，我的口诀是：靠近哪个类，就表示"每一个这个类的对象"与对面类对象的数量关系，标注在对面类的旁边。

分析阶段的对象图则是类图的一个具体快照，考试有时会让画"某时刻系统的具体状态"。例如类图里有"读者"和"借阅记录"两个类，对象图就要画出"张三"这个实例，以及他名下两条具体记录的属性值。对象图不太常单独出大案例题，但作为理解类-实例关系的练习题，价值很高。

3.3 动态模型：别让对象"死"在类图里

类图描述的是"structure"，状态图和顺序图描述的才是"life"。分析阶段的动态建模有两个方向，一个是对象内部的"状态变化"，对象之间的"消息交互"。

状态图适合描绘单个对象的生命周期。图中必须有初态（实心圆）和终态（同心圆），中间是状态框，状态之间的连线标注"事件[条件]/动作"。比如"图书"对象的状态就有"可借"、"已借出"、"逾期"、"挂失"等，从"可借"到"已借出"的触发事件是"登记借出"，从"已借出"到"可借"的触发事件是"登记归还"。考试爱让你补充状态图，最容易丢分在两处：一是漏了初态和终态，二是漏了"边界事件"导致的异常状态分支。画状态图时我的习惯是回到用例描述的扩展场景里找触发条件，一个扩展场景往往对应一个状态转移分支。

活动图用于描述一个业务过程或用例实现的流程，有点类似流程图但更强调并行和对象划分。考试较少单独要求画复杂活动图，但如果案例里出现"验收"、"审批"这种并行操作时，活动图比状态图更贴切。例如图书预约流程中，读者提交预约和系统检查库存数量可以并行执行，但系统生成预约队列必须等待"读者有效"和"图书可预约"两个条件都满足，这是"汇合"节点的作用。

顺序图是动态模型里最常考、也是最有价值的一个图。它描述的是"一段时间内，一组对象的交互过程"，横轴是参与对象，竖轴是时间线，对象之间发消息用箭头表示，返回值用虚线箭头。顺序图画得好，能直观发现类图中的操作是否够用：如果类图里"读者"类没有任何"checkValid"操作，但顺序图里发了一条checkValid消息给读者对象，那就说明类图该补操作。考试案例里，顺序图往往和用例描述绑定出现，所以一定要练出来"从文字场景→对象生命线→消息箭头"的翻译能力。

协作图/通信图和顺序图描述的信息本质相同，只是表达方式不同，调整成网格状拓扑，强调对象之间的连接关系。考试里如果题目说"画出协作图"，记住格式不迷路即可，重点依然是对象角色、连接和消息编号。

4. 完整案例推演：从一段需求到四张核心图

4.1 案例需求：做一个图书预约与借阅模块

为了把前面内容串起来，我用一个实际案例走一遍完整流程，案例很适合考试练手，也贴近大家熟悉的场景：微信小程序里实现"图书预约与借阅"。

需求描述（模拟用户原话）：读者可以在小程序上检索图书、查看可借状态、提交预约；图书管理员可以处理预约请求、办理借出、办理归还；如果读者有逾期未还的图书，系统禁止再借新书；预约成功的书保留三天，三天内未到馆取阅则自动释放。

拿到这种需求，第一个动作不是急着画图，而是圈出参与者。能看出两个直接交互者：读者、管理员。如果把"微信小程序"也画成参与者，分析粒度就不太好，它只是交互界面，不是业务角色。系统本身也不应该是参与者，除非存在外部系统对接（比如短信通知服务），那可以作为参与者出现。这里为了简化，只有两个参与者。

4.2 第一步：用例图和用例描述

根据需求可以拆出以下用例：检索图书、查看图书状态、提交预约、处理预约、办理借出、办理归还、取消预约。再进一步识别，会发现"办理借出"无论是读者线下请求还是管理员操作，都包含"验证读者资格"这个公共环节，于是可以抽出一个被include的子用例"验证读者资格"。另一方面，"提交预约"在读者存在逾期记录时，会触发"阻止预约并提示"，这个可以作为extend用例"处理逾期拦截"。

画用例图时会用到几根关系箭头：参与者"读者"和"提交预约"之间是普通关联实线；"办理借出"和"验证读者资格"之间是include虚线，箭头指向"验证读者资格"；"提交预约"和"处理逾期拦截"之间是extend虚线，箭头指向"提交预约"。这里很多同学容易把箭头的方向搞反，不妨记住：include是"总是要用到"，extend是"偶尔才触发"，箭头的指向都是业务上更"底层"的那一侧。

用例描述以"提交预约"为例，主成功场景可以写成：

1. 读者在检索结果中选定一本图书；
2. 系统显示该图书的馆藏状态；
3. 读者点击"预约"；
4. 系统验证读者身份；
5. 系统验证读者没有逾期记录；
6. 系统生成预约记录，并将图书标记为"已预约"；
7. 系统向读者出示预约成功提示。

扩展场景则包括：4a. 读者身份失效，系统拒绝预约；5a. 读者有逾期记录，系统提示"存在未归还图书，暂不能预约"；6a. 预约数量超过上限，系统拒绝本次预约。练习时有同学只写主场景不写扩展场景，导致后面状态图没内容可画，这个坑我踩过。

4.3 第二步：识别类并画类图

从用例描述里挑名词，可以得到一批候选：图书、馆藏副本、预约记录、借阅记录、读者、读者证、管理员、系统提示。逐个筛选后，"系统提示"是系统输出，不应成为领域类；"馆藏副本"和"图书"在业务分析中常合并，但如果更精细建模，一本书可能对应多个副本，例如三本同名书，因此最好拆成"图书书目"和"图书副本"两个类，它们在现实中需求和馆藏管理经常拆开。于是初步类图包含：

• 图书书目（ISBN、书名、作者、出版社）
• 图书副本（副本号、馆藏位置、当前状态）
• 读者（读者号、姓名、联系电话、逾期次数）
• 预约记录（预约时间、取书截止时间、状态）
• 借阅记录（借出时间、应还时间、实际归还时间）

关系描述：图书书目和图书副本是1对多关联；读者和预约记录是1对多关联；图书副本和预约记录是1对多关联；读者和借阅记录是1对多关联。也许有人会把"图书副本——预约记录"这里画成多对多，觉得一个副本可以被多次预约，但注意预约成功后副本就变成已预约状态，下一次预约发生在归还之后，因此时间上每次预约对应一个副本，所以可以是1对1，但从"一个副本累计有多条预约记录"的角度，一对多是更稳妥的选择，关键看"当前预约"还是"历史预约"建模。我在复习时把这个地方反复推敲过，结论是：分析阶段如果没把握，可以写明细说明，老师不会因为你选了合理的粒度而扣分。

类图的另一项工作是确定操作。每个类先只写候选操作，后续画完顺序图再回头补。比如"读者"类要有"查询逾期状态"、"验证身份"，"图书副本"类要有"改变状态"，"预约记录"类要有"创建预约"、"取消预约"，"借阅记录"类要有"创建记录"、"登记归还"。紧凑地说，操作来源于用例描述中的动词短语。

4.4 第三步：对象图和状态图

对象图用于展示某具体时刻的快照。假设案例情境是"张三在预约一本《算法导论》的副本A"，对象图会画出"读者实例：张三"，标注读者号R001；"图书副本实例：副本A"，标注当前状态"已预约"；"预约记录实例：预2024001"，标注状态"等待取书"。连线上的多重性在这个具体场景里就体现为具体数量：张三当前关联一条预约记录。

状态图选"图书副本"来画，因为这类对象的状态变化最能体现业务规则。初态是"馆藏中"，发现预约后变成"已预约"；读者取书办理借出后变成"已借出"；若三天未取，预约记录被释放，状态从"已预约"回到"馆藏中"；归还图书后状态从"已借出"回到"馆藏中"；若借出超期，则变为"逾期"，归还时先处理逾期记录再回到"馆藏中"。这张图把业务规则中的"预约保留三天""有逾期不能借"彻底可视化出来，考试时候照这个思路画，不会漏关键分支。

4.4（续）第四步：顺序图把协作过程演一遍

现在用"读者提交预约"这一用例画顺序图。对象依次放：读者、图书副本、预约记录。先由读者发"预约请求"消息给图书副本，副本检查自身当前状态，如果"馆藏中"则返回"可预约"；然后读者对象发"创建预约"消息给预约记录，预约记录保存数据并向图书副本发"锁定状态"消息，把副本状态改为"已预约"；最后预约记录返回"预约成功"给读者。

画顺序图还有一个隐藏细节：验证读者资格、验证逾期次数，可以由"读者"对象自己完成，也可以引入一个"资格验证器"辅助类。如果为了考试简单，可以在类图中给读者加操作validateForReservation()，这样顺序图中消息发送方是读者，接收方是读者自己的生命线，也能表现"自我调用的递归消息"，用从生命线发出的箭头再指回该生命线即可。这种自我调用在考试里也是考点。

4.5 动态模型与静态模型的互相校验

许多同学画完顺序图就收工，从不回头校验类图，结果A图里面有"发送取消预约消息"，B图对应类却没有cancel()操作。实际上，顺序图中每一条从发送方指向接收方的消息箭头，接收方类都应该有对应的操作；类图中每一个复杂操作，也往往能在用例的场景里找到对应消息。复习时拿下我当年整理的一份"三角对照表"，贯穿整个OOA复习高效的狠：用例描述的步骤、顺序图的消息、类图中的操作，三个列表逐条对应，如果某一列对不上，说明模型存在缺口。这份对照尤其适合应对"完善下列类图"这类扣分题。

5. 考前自查与常见错误清单——a测前的血泪经验

5.1 判卷中最常见的四类错误

整理了过往几届同学a测错题和作业反馈之后，发现出错点非常集中，下面做成一张小表，考前十分钟过一遍：

其中箭头方向这个错误，说多了都是泪。include和extend考试频率很高，你甚至可以把这个口诀直接搬进答题备注里：include译为"必须包含"，箭头指向被包含的那个用例；extend译为"在某种情况下会额外扩展"，箭头指向原本的用例本体。写错了方向，阅卷老师一眼就能看出来，这一分丢得特别冤枉。

5.2 名词解释和大题的答题套路

名词解释在大题里占比不高，但常见词就那些：对象、类、封装、继承、多态、关联、聚合、用例、OOA。别背整段教材，我用"一句话定义+关键特征+一句话场景"的结构组织答案，比如多态的答法是："同一消息发送给不同对象时，各对象根据其类中重定义的行为做出不同响应；例如print消息发送给激光打印机和喷墨打印机。ES；两人计科a测前这样答，起码中规中矩拿到基本分。"

大题部分，题型一般给出一个系统场景，要求完成三个任务：画出用例图并写用例描述；画出类图并给出关键类的属性和操作；画出某个用例的状态图和顺序图。答题时的顺序建议是：先写参与者与用例列表，再画用例图；紧接着写一个核心用例描述，再从中抽取候选类，形成类图；然后挑选核心类补充状态图；最后画顺序图，并顺手检查类图操作是否齐备。每一步都用文字简述你的分析思路，不要只丢一张图，老师判卷时会因为你写了推导过程而多给"分析分"。

5.3 复习的节奏建议与工具推荐

如果距离a测还有几天，我没有太多神奇技巧，唯一的建议是不要按知识点顺序硬看，可以按"用例——类图——顺序图——状态图"这条线做两个完整案例。第一个案例照教材抄一遍，感受画图规范；第二个案例合上书自己做，然后对答案。这个过程能把"死知识"转成活技能，比反复读定义有用得多。

工具方面，画图我用过UMLet、PlantUML和draw.io。课堂作业和考试草稿上，手动画图最方便，不必强行用代码化工具。我自己复习时喜欢先用PlantUML生成一版图，再手动改版，因为它用文本描述对象和关系，写起来快，还能顺便暴露谁是谁的关联关系。不过考试真正动手画时，记得把每根线、每个箭头的语义都想清楚，毕竟工具画得再漂亮，语义错了照样扣分。

另外想提一个容易被忽略的小环节：标注。类图上的属性、操作，状态图上的事件名，顺序图上的消息名，都必须用准确的专业术语，别写"状态变化"这种模糊词，要写"copyReserved()"、"状态变为'已预约'"这类明确表达。阅卷时老师能从细节看出你是真正理解了这个模型，还是只是照着葫芦画瓢。

复查时建议自己对着五点自检：参与者和用例是否匹配；include/extend方向是否无误；多重性是否与业务规则一致；状态图是否有初态和终态；顺序图消息是否都有类图对应。这套自查来自我一次次改自己答案的教训，你要是能照着坚持两遍，考前心里就会很有底。

最后多说一句：面向对象分析这门课看起来满是画图规则，其实它炼的是"把一个乱糟糟的需求梳理成模型"的系统思维。哪怕以后工作里不画UML，这种"先理清参与者、再抽出实体、再模拟交互"的习惯，也是写高质量代码的前置功底。a测只是个节点，愿这个整理能帮你在复习的时候少走点弯路。