在系统架构设计师的考试体系中“设计方法”是决定软件系统质量与可维护性的关键内容。当前主流的两种设计方法——结构化分析与设计、面向对象的分析设计分别代表了不同时代、不同场景下的工程化思维。理解并掌握它们是架构师必备的能力。一、结构化分析与设计以控制结构为核心结构化设计的理论基础是“结构程序设计”。其核心思想是将系统的控制流程限定在三种基本构件之内顺序、分支和循环。这种约束看似简单却极大地提升了程序的可读性与可验证性。顺序结构保证任务按线性方式执行分支结构如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根据用例设计实现方案UML2设计技术支撑设施非功能性公共支持件3设计用户界面类图我们来逐一拆解并给出实际例子。Step 1根据用例设计实现方案 → 画 UML 交互图输入用例描述比如“用户下单”输出序列图或协作图做什么确定有哪些对象、按什么顺序发消息举个栗子下单用例参与者顾客、订单控制器、库存服务、支付服务序列图流程顾客 → 订单控制器→订单控制器 → 库存服务→库存服务 → 订单控制器→订单控制器 → 支付服务…Step 2设计技术支撑设施非功能性公共支持件这部分容易被忽略但考试常考“哪些属于技术支撑设施”。包括但不限于日志记录组件缓存服务事务管理器安全/权限控制异常处理框架消息队列基础设施设计要点它们通常是横切关注点应设计为公共组件而不是和业务代码耦合在一起。Step 3设计用户界面类图你可能会问“UI 为什么用类图画”其实这里的“类图”是指界面类、控制器类、实体类之间的关系典型的是 MVC 模式中的 View 和 Controller。示例类图关系LoginView—关联→LoginControllerLoginController—依赖→UserService这样可以避免把业务逻辑写在界面代码里。四、结构化和面向对象到底选哪个对比维度结构化面向对象基本单元模块 / 函数对象 / 类数据与操作分离封装在一起变更适应能力弱强继承多态适合场景算法密集、流程固定业务复杂、需求多变典型语言C, Pascal, ShellJava, C, Python考试小技巧如果题目描述提到“需求频繁变化”“需要代码复用”“大规模系统”优先选面向对象如果提到“实时性要求极高”“硬件驱动”“数据流清晰”结构化也不差。五、写在最后给考生的建议别死记硬背图的名字要理解每张图的输入、输出和作用。结合案例随便拿一个“图书馆借书系统”或“电商下单”自己画用例图、类图、序列图。关注“从分析到设计”的转换步骤这是下午案例题的常见考点。1
