在系统架构设计师的考试体系中，“设计方法”是决定软件系统质量与可维护性的关键内容。当前主流的两种设计方法——结构化分析与设计、面向对象的分析设计，分别代表了不同时代、不同场景下的工程化思维。理解并掌握它们，是架构师必备的能力。
一、结构化分析与设计：以控制结构为核心
结构化设计的理论基础是“结构程序设计”。其核心思想是将系统的控制流程限定在三种基本构件之内：顺序、分支和循环。这种约束看似简单，却极大地提升了程序的可读性与可验证性。
- 顺序结构保证任务按线性方式执行；
- 分支结构（如if-else）支持条件判断；
- 循环结构（如for、while）解决重复处理问题。
通过这三种结构的组合，任何复杂逻辑都可以被清晰、无跳转地表达出来，从而避免“面条式代码”。
在系统架构层面，结构化方法强调自顶向下、逐步细化，将系统逐层分解为功能模块，并用数据流图、结构图等工具进行建模。它适合处理逻辑明确、功能稳定、变化较少的系统，如传统管理信息系统或嵌入式控制软件。
二、面向对象的分析设计（OOAD）：以抽象与复用为宗旨
随着业务复杂度和变更频率的上升，结构化方法在应对需求波动、代码复用、系统扩展等方面逐渐暴露出不足。面向对象方法应运而生，它将世界抽象为“对象”与“关系”，更贴近人类认知方式。
根据考试资料，面向对象的分析模型包含三个核心构件：
- 顶层架构图— 描述系统在高层次上的整体划分与交互；
- 用例与用例图— 从用户视角捕获功能需求；
- 领域概念模型— 识别业务中的关键概念及其关系。
而面向对象的设计模型则更加具体，包括：
- 软件体系结构图：划分子系统或层；
- 用例实现图（通常为交互图或序列图）：细化用例的动态协作；
- 类图、状态图、活动图：分别描述静态结构、生命周期行为及工作流逻辑。
三、从分析到设计的三个关键步骤
资料中明确指出，从分析转向设计应遵循以下步骤：
根据用例设计实现方案（UML）
以用例为驱动，绘制序列图或协作图，确定哪些对象参与、如何协作完成业务逻辑。这一步是连接需求与实现的桥梁。设计技术支撑设施
关注非功能性需求，如安全、日志、缓存、事务、并发控制等。这些通常被封装为“公共支持件”，以服务或组件形式被上层调用，避免横切关注点的代码散落。设计用户界面（类图）
将界面视为系统的一部分，通过类图定义界面组件、控制器与领域对象之间的关联。这有助于保持交互逻辑与业务逻辑的分离，提升可维护性。
四、两种方法的选择与融合
结构化方法在实时系统、数据处理管道等流程主导的场景中依然高效；而面向对象方法则在业务复杂、需求多变的企业级系统中占据主流。实际工程中，架构师也可以采用混合策略：高层用面向对象组织模块，模块内部对关键算法用结构化风格实现。
总之，无论是结构化还是面向对象，它们都不是互相排斥的，而是相互补充的设计工具。深入理解其原理与适用边界，才能在系统架构设计中做出合理决策，真正写出“可读、可拓、可维护”的系统。
好的，以下是一篇适合发布在 CSDN 上的技术博客风格文章，语言更轻松、结构更清晰，带有一点“备考笔记 + 实战体会”的味道。
【系统架构设计师】一篇文章吃透“设计方法”：结构化 vs 面向对象（附备考笔记）
还在分不清结构化分析与设计、面向对象分析设计？
面试常考、软考必考的设计方法论，今天一次讲清楚。
前言
在系统架构设计师考试中，4.4 设计方法是绝对的重点板块。很多同学看到“顶层架构图”“用例实现图”“状态图”就直接懵了，其实里面的逻辑非常清晰。
今天就结合考试官方教材的内容，帮大家彻底搞懂两大设计方法的核心区别与从分析到设计的标准步骤。建议收藏 + 在纸上画一遍图。
一、结构化分析与设计：三种控制结构打天下
关键词：顺序、分支、循环、自顶向下、功能分解
结构化设计源于结构程序设计理论。它的核心思想其实特别简单：不管多复杂的程序，只要用好下面三种基本控制结构，就能写清楚。
| 结构 | 作用 | 常见形式 |
|---|---|---|
| 顺序 | 一步一步执行 | 语句1; 语句2; |
| 分支 | 条件判断 | if…else…, switch |
| 循环 | 重复执行 | for, while, do…while |
优势：
- 逻辑清晰，容易验证（没有 goto 那种乱跳）
- 适合功能明确、流程稳定的系统（比如报表处理、简单嵌入式）
局限性：
- 应对变化较弱，需求一变，数据流图几乎要重画
- 与真实世界的“对象”思维有差距，代码复用度低
考试常考：
结构程序设计允许使用的控制结构不包括哪一项？（答：goto 或 无条件转移）
二、面向对象的分析设计（OOAD）：向现实世界靠拢
关键词：对象、类、用例驱动、UML
面向对象方法把系统看成一组相互协作的对象，每个对象有自己的数据和可以提供的服务。
根据考试资料，面向对象的设计分为分析模型和设计模型。
2.1 面向对象的分析模型（做什么）
| 构件 | 说明 |
|---|---|
| 顶层架构图 | 系统的宏观划分（子系统/模块） |
| 用例与用例图 | 从用户角度描述功能需求 |
| 领域概念模型 | 识别核心业务概念及其关系（如：学生-课程-选课） |
这一阶段的产出不涉及具体技术实现，重点是“理解业务”。
2.2 面向对象的设计模型（怎么做）
| 图/模型 | 用途 |
|---|---|
| 软件体系结构图 | 分层/分模块（如 MVC、微服务划分） |
| 用例实现图 | 常用序列图，展示对象如何配合完成用例 |
| 类图 | 定义类的属性、方法、关系（继承/关联/依赖） |
| 状态图 | 描述对象的状态转换（适合订单、工作流） |
| 活动图 | 类似流程图，描述业务过程或算法 |
典型误区提醒：
很多同学把“用例图”和“类图”混为一谈。记住：用例图是分析阶段的，类图既可用于分析也可用于设计，但设计阶段的类图会更具体（会包含方法参数、依赖注入等）。
三、从分析到设计：标准三步走（考试原话整理）
考试资料中明确给出了从分析到设计的步骤，原文如下：
1）根据用例设计实现方案（UML）
2）设计技术支撑设施（非功能性公共支持件）
3）设计用户界面（类图）
我们来逐一拆解，并给出实际例子。
Step 1：根据用例设计实现方案 → 画 UML 交互图
- 输入：用例描述（比如“用户下单”）
- 输出：序列图（或协作图）
- 做什么：确定有哪些对象、按什么顺序发消息
举个栗子（下单用例）：
- 参与者：顾客、订单控制器、库存服务、支付服务
- 序列图流程：
顾客 → 订单控制器→订单控制器 → 库存服务→库存服务 → 订单控制器→订单控制器 → 支付服务…
Step 2：设计技术支撑设施（非功能性公共支持件）
这部分容易被忽略，但考试常考“哪些属于技术支撑设施”。
包括但不限于：
- 日志记录组件
- 缓存服务
- 事务管理器
- 安全/权限控制
- 异常处理框架
- 消息队列基础设施
设计要点：它们通常是横切关注点，应设计为公共组件，而不是和业务代码耦合在一起。
Step 3：设计用户界面（类图）
你可能会问：“UI 为什么用类图画？”
其实这里的“类图”是指：界面类、控制器类、实体类之间的关系（典型的是 MVC 模式中的 View 和 Controller）。
示例类图关系：
LoginView—关联→LoginControllerLoginController—依赖→UserService
这样可以避免把业务逻辑写在界面代码里。
四、结构化和面向对象，到底选哪个？
| 对比维度 | 结构化 | 面向对象 |
|---|---|---|
| 基本单元 | 模块 / 函数 | 对象 / 类 |
| 数据与操作 | 分离 | 封装在一起 |
| 变更适应能力 | 弱 | 强（继承+多态） |
| 适合场景 | 算法密集、流程固定 | 业务复杂、需求多变 |
| 典型语言 | C, Pascal, Shell | Java, C++, Python |
考试小技巧：
如果题目描述提到“需求频繁变化”“需要代码复用”“大规模系统”，优先选面向对象；
如果提到“实时性要求极高”“硬件驱动”“数据流清晰”，结构化也不差。
五、写在最后（给考生的建议）
- 别死记硬背图的名字，要理解每张图的输入、输出和作用。
- 结合案例：随便拿一个“图书馆借书系统”或“电商下单”，自己画用例图、类图、序列图。
- 关注“从分析到设计”的转换步骤，这是下午案例题的常见考点。
1
