前文基础：
1.软件工程学概述：软件工程学概述-CSDN博客
2.软件过程深度解析：软件过程深度解析-CSDN博客
3.软件工程之需求分析涉及的图与工具：软件工程之需求分析涉及的图与工具-CSDN博客
4.软件工程之形式化说明技术深度解析：https://lzm07.blog.csdn.net/article/details/147803429
5.软件工程之详细设计深度解析：https://blog.csdn.net/lzm12278828/article/details/147807034
一、面向对象分析的基本过程
（一）概述
面向对象分析（Object-Oriented Analysis, OOA）是通过抽象问题域中的实体及其关系，建立系统精确模型的过程。其核心思想是将现实世界中的事物映射为对象（Object），通过封装、继承、多态等机制描述系统行为。与传统结构化分析相比，OOA更贴近人类认知方式，能有效降低复杂系统的开发难度。
OOA的目标是形成软件需求规格说明书，主要由三个子模型构成：
（1）对象模型：描述系统静态结构（类、对象及其关系）。
（2）动态模型：描述系统动态行为（状态变化、事件交互）。
（3）功能模型：描述系统数据变换和处理逻辑。
实际分析过程需反复迭代，通常遵循“理解→表达→验证”的循环：
（1）理解需求：与用户、领域专家协作，明确系统边界和功能。
（2）建立模型：通过三个子模型逐步细化需求，形成可验证的规格说明。
（2）验证模型：检查模型的一致性、完整性和可实现性，确保符合用户需求。
（二）3 个子模型与 5 个层次
1. 三个子模型
（1）对象模型：
以类图为核心，描述系统中对象的静态结构。例如，在线购物系统中的“用户”“商品”“订单”等类，以及它们之间的关联（如“用户下单”“订单包含商品”）。对象模型是系统的基础，其他模型依赖其提供的类和关系。
（2）动态模型：
以状态图和事件跟踪图为工具，描述对象的状态变化和事件交互。例如，订单的状态从“已提交”变为“已支付”再到“已发货”，需通过状态图明确触发状态转换的事件（如“用户支付”“仓库发货”）。
（3）功能模型：
以数据流图（DFD）为核心，描述系统的数据处理逻辑。例如，在线购物系统的“订单处理”功能可分解为“验证库存”“计算总价”“生成发票”等子处理，通过数据流图展示数据流动和处理过程。
2. 五个层次
复杂系统的对象模型通常包含五个层次，形成逐层细化的结构：
（1）主题层：将系统划分为若干主题（如“用户管理”“订单管理”），便于理解大型模型。
（2）对象类层：识别系统中的类与对象（如“用户”“商品”）。
（3）结构层：定义类之间的关系（如继承、关联）。
（4）属性层：为类添加属性（如“用户”的姓名、邮箱）。
（5）服务层：定义类的操作（如“用户”的登录、注册）。
二、需求陈述
（一）书写要点
需求陈述是OOA的起点，需清晰、准确地描述系统功能和约束。关键要点包括：
（1）问题范围：明确系统边界，区分系统内外部实体。
（2）功能需求：列出系统必须完成的任务（如“用户可查询订单状态”）。
（3）性能需求：定义响应时间、吞吐量等指标（如“订单查询响应时间≤2 秒”）。
（4）应用环境：描述系统运行的软硬件环境（如“支持 Windows 和 macOS”）。
（5）假设条件：说明未经验证的前提（如“用户输入数据格式正确”）。
书写时应避免歧义，采用结构化语言（如“系统应允许用户……”），并优先使用动词短语描述功能。例如，“用户提交订单后，系统应发送确认邮件”比“系统要处理订单”更明确。
（二）例子：在线购物系统需求陈述
项目背景：
某电商平台需开发在线购物系统，支持用户浏览商品、下单、支付，以及管理员管理商品库存和订单。
需求陈述：
1.功能需求：
用户可注册、登录系统，浏览商品列表，查看商品详情。
用户可将商品加入购物车，修改购物车中商品的数量或删除商品。
用户提交订单后，系统应生成唯一订单号，并发送确认邮件。
管理员可添加、修改、删除商品信息，查看订单状态并更新物流信息。
2.性能需求：
商品搜索响应时间≤1 秒（数据量≤10 万条）。
订单处理吞吐量≥100 笔 / 分钟。
3.应用环境：
服务器端：Linux 操作系统，MySQL 数据库，Tomcat 应用服务器。
客户端：支持 Chrome、Firefox 等主流浏览器，移动端适配 iOS 和 Android。
4.假设条件：
用户已安装最新版本浏览器，网络连接稳定。
支付接口由第三方支付平台提供，系统无需处理支付安全问题。
三、建立对象模型
（一）确定类与对象
从需求陈述中提取名词短语，筛选出与问题域相关的类。例如，在线购物系统中的候选类包括“用户”“商品”“购物车”“订单”“支付”等。需排除冗余（如“系统”）、无关（如“网络”）或笼统（如“数据”）的类。
筛选原则：
（1）冗余类：重复表示同一概念的类（如“顾客”和“用户”）。
（2）无关类：与系统功能无关的类（如“操作系统”）。
（3）笼统类：过于抽象的类（如“实体”）。
（4）属性类：应作为属性而非类的概念（如“商品颜色”）。
（5）操作类：应作为方法而非类的概念（如“支付处理”）。
（二）确定关联
识别类之间的关系，如“用户下单”（用户与订单的关联）、“订单包含商品”（订单与商品的关联）。关联需明确重数（如“一个订单包含多个商品”）和方向（如“用户提交订单”）。
关联类型：
（1）普通关联：如“用户拥有购物车”。
（2）聚合关联：如“购物车由多个商品项组成”。
（3）继承关联：如“管理员是特殊用户”。
（三）划分主题
将类分组为主题，降低模型复杂度。例如，在线购物系统可划分为“用户管理”“商品管理”“订单管理”三个主题。主题应具有高内聚性，组内类关系紧密，组间耦合度低。
（四）确定属性
为类添加描述性属性。例如，“用户”类的属性包括姓名、邮箱、地址；“商品”类的属性包括名称、价格、库存。属性应满足原子性（不可再分）和完整性（无遗漏关键信息）。
常见错误：
（1）误把对象当属性：如将“地址”作为“用户”的属性，而非独立类。
（2）属性冗余：如“订单总价”可通过“商品价格 × 数量”计算，无需存储。
（3）属性不一致：如“商品价格”在不同类中单位不统一（元 / 美元）。
（五）识别继承关系
通过泛化 - 特化关系（继承）简化类结构。例如，“管理员”是“用户”的子类，继承“用户”的属性和方法，并添加“权限管理”等特有功能。继承可减少代码冗余，提高可维护性。
继承策略：
（1）自底向上：从具体类中提取公共属性和方法，形成父类。
（2）自顶向下：从抽象父类逐步细化为具体子类。
（六）反复修改
对象模型需多次迭代优化。例如，初始模型中“订单”和“支付”是独立类，后续发现“支付”可作为“订单”的一个状态，从而合并为“订单”类的属性或子状态。
优化方法：
（1）分解复杂类：如将“现金兑换卡”分解为“卡信息”和“交易记录”。
（2）合并冗余类：如“分行”和“分行计算机”可合并为“分行”类。
（3）调整关联关系：如将三元关联拆分为二元关联。
四、建立动态模型
（一）编写脚本
描述系统典型交互场景（如“用户下单流程”），明确事件顺序和参与者。脚本需覆盖正常流程和异常情况，例如：
用户下单脚本：
（1）用户登录系统，浏览商品列表。
（2）用户选择商品，添加到购物车。
（3）用户确认订单信息，提交订单。
（4）系统验证库存，若库存不足，提示用户；否则生成订单。
（5）用户选择支付方式，完成支付。
（6）系统更新订单状态为“已支付”，并发送确认邮件。
（二）设想用户界面
设计系统的交互界面，确定用户操作方式（如按钮、菜单）和反馈机制（如提示信息）。例如，订单提交后显示“订单已提交，预计 24 小时内发货”。
（三）画事件跟踪图
以竖线表示对象，箭头表示事件，展示对象间的交互顺序。例如，用户下单的事件跟踪图如下：
用户 → 购物车：添加商品
购物车 → 商品：查询库存
商品 → 购物车：返回库存信息
用户 → 系统：提交订单
系统 → 订单：生成订单
系统 → 支付接口：发起支付
支付接口 → 系统：返回支付结果
系统 → 用户：发送确认邮件
以下是一个示例：
（四）画状态图
为关键类绘制状态图，描述其状态转换。例如，“订单”类的状态图：
初始状态 → 已提交
已提交 → 已支付 [用户支付]
已支付 → 已发货 [管理员发货]
已发货 → 已完成 [用户确认收货]
已提交 → 已取消 [用户取消订单]
以上是一个示例：
（五）审查动态模型
检查状态图和事件跟踪图的一致性，确保事件触发的状态转换符合逻辑。例如，“已取消”状态不能直接转换为“已支付”，需通过“重新提交订单”事件触发。
五、建立功能模型
（一）画出基本系统模型图
用数据流图（DFD）描述系统与外部实体的交互。例如，在线购物系统的基本模型图：
外部实体：用户、管理员、支付平台
处理：订单处理
数据流：商品信息、订单请求、支付结果
数据存储：商品库、订单库
（二）画出功能及数据流图
逐层分解基本模型，细化处理逻辑。例如，“订单处理”可分解为“验证库存”“计算总价”“生成发票”等子处理，并用数据流连接各处理框。
0层数据流图：
用户 → 验证库存：商品ID、数量
验证库存 → 商品库：查询库存
商品库 → 验证库存：库存信息
验证库存 → 计算总价：商品价格、数量
计算总价 → 生成发票：订单金额
生成发票 → 订单库：保存订单
以下是数据流图的一个示例：
（三）描述处理框功能
用结构化语言或判定表详细说明每个处理框的逻辑。例如，“验证库存”处理框的逻辑：
IF 库存 ≥ 订单数量 THEN
返回“库存充足”
ELSE
返回“库存不足”
ENDIF
六、定义服务
（一）常规行为
为类定义通用操作，如“用户”类的“登录”“注册”，“订单”类的“提交”“取消”。这些操作直接对应动态模型中的事件和状态转换。
（二）从事件导出的操作
根据事件跟踪图中的交互，确定对象需提供的方法。例如，“用户添加商品到购物车”事件对应“购物车”类的“添加商品”方法。
（三）与数据流图对应
将数据流图中的处理框映射为对象的操作。例如，“计算总价”处理框对应“订单”类的“计算总价”方法，该方法调用“商品”类的“获取价格”方法。
（四）利用继承减少冗余
通过继承机制复用父类服务。例如，“管理员”类继承“用户”类的“登录”方法，并添加“修改商品信息”等特有方法。
java代码示例：
// 父类：用户 public class User {
private String name;
private String email;
public void login(String username, String password) {
// 登录逻辑
} }
// 子类：管理员 public class Admin extends User {
public void updateProduct(Product product) {
// 修改商品信息逻辑
} }
七、结语
面向对象分析通过三个子模型和五个层次，将用户需求转化为可执行的系统模型。实际应用中需注意：
（1）模型迭代：分析过程需反复优化，避免过早陷入细节。
（2）工具辅助：使用 UML 类图、状态图、DFD 等工具提高建模效率。
（3）跨模型关联：确保对象模型、动态模型、功能模型的一致性，例如对象的属性和操作需在数据流图中体现。
（4）领域知识：结合行业经验识别关键类和关系，例如金融系统需重点关注“账户”“交易”等类。
未来，随着AI辅助建模工具的发展，面向对象分析将更高效、智能化，进一步降低复杂系统的开发门槛。