备考软考 系统分析师的宝子们，是不是都卡在同一个坎上？

案例分析背了又忘，答题时脑子一片空白，明明记得知识点，却写不出来得分点；论文更是头疼，核心理论记不牢，模板套得再熟练，没有干货支撑也拿不到高分；每天花好几个小时死磕背诵，结果合上书就忘，越背越焦虑，越焦虑越背不进去😭

其实软考系分的案例与论文背诵，从来不是“死记硬背”，而是“抓核心、找规律、会应用”。毕竟系分作为软考高级，考的是你的分析和应用能力，不是单纯的记忆能力——那些让你背了就忘的，大概率是没找对核心，做了无用功。

今天这篇推文，结合我备考积累的经验，就给大家整理了「案例+论文核心知识点背诵攻略」，帮你跳出死记硬背的误区，精准抓分、高效记忆，少走很多弯路，轻松拿捏案例和论文的关键得分点！

二、系统分析

2.1快速开发方法（FAST）

1.范围定义

2.问题分析

3.需求分析

4.逻辑设计

5.决策分析

6.物理设计和集成

7.构造和测试

8.安装和发布

补充：快速开发方法建立在业务、流程熟悉的基础上，基于组件式开发，按“搭积木”思想快速交付，可复用性高；但不适应新技术、技术风险较高的项目。核心思想包括用户主动参与、多方人员协同、迭代构建、提前展示可运行系统。

2.2系统约束条件

系统改进目标受四大约束调节：进度、成本、技术、政策。

2.3结构化分析（SA）

通过功能分解将系统功能拆分到各个模块，分析结果以数据流图（DFD）和实体关系图（ERD）呈现。

2.3.1数据流图（DFD）组成

• ▪▪ ▪ 数据流：由固定数据组成，标识数据流向，有明确名称。
• ▪▪ ▪ 加工：描述输入数据流到输出数据流的变换，有名称和编号。
• ▪▪ ▪ 数据存储：用于存储数据，有明确名称标识。
• ▪▪ ▪ 外部实体：系统之外的人员或组织，是数据的发源地和归宿地，有明确名称标识。

2.3.2数据流图绘制步骤

• ▪▪ ▪ 画系统输入和输出：在图的边缘标出，确定研究内容和系统范围。
• ▪▪ ▪ 画DFD内部：用一系列加工连接输入与输出数据流。
• ▪▪ ▪ 为数据流命名：避免空洞名称，保证可理解性。

2.3.3 DFD常见错误

• ▪▪ ▪ 加工只有输入没有输出，或只有输出没有输入。
• ▪▪ ▪ 数据流没有方向箭头或没有名称。
• ▪▪ ▪ 从一个数据存储直接流向另一个数据存储。

2.4 面向对象分析（OOA）

运用面向对象方法理解问题域，识别类和对象，定义其属性、职责及关系，最终生成需求模型和分析模型两大成果。

2.4.1 需求模型

用用例图建立，为分析工作提供依据，构建流程包括：识别参与者→合并需求获得用例→细化用例描述→调整用例模型（前三个阶段为必需）。

2.4.2 分析模型

用类图建立，构建流程包括：定义概念类→确定类之间的关系→为类添加职责→建立交互图（顺序图、协作图等）。

2.4.3 类之间的关系

2.4.4 核心设计原则（OOD）

• ▪▪ ▪ 开放封闭原则：对扩展开放，对内部修改关闭。
• ▪▪ ▪ 单一职责原则：一个类、方法、接口仅负责一项功能。
• ▪▪ ▪ 里氏替换原则：子类可扩展父类功能，但不能修改父类原有方法，子类可替代父类使用。
• ▪▪ ▪ 迪米特原则：类之间尽量减少直接依赖，通过中介类交互，降低耦合。
• ▪▪ ▪ 接口分离原则：拆分大而全的接口，避免用户调用不必要的功能。
• ▪▪ ▪ 依赖倒置原则：高层模块依赖抽象（接口），不依赖底层具体实现。
• ▪▪ ▪ 组合/聚合原则：优先使用组合/聚合关系，减少继承，降低耦合。

三、需求获取与评审

3.1需求获取技术

补充：其他方法包括实地观察、收集现有资料等。

3.2 需求评审内容

• ▪▪ ▪ SRS（需求规格说明书）正确描述预期的系统行为和特征，符合项目干系人需求。
• ▪▪ ▪ 软件需求从系统需求、业务规格等来源正确推导而来。
• ▪▪ ▪ 需求完整、高质量，无描述不完整、模糊不清的情况。
• ▪▪ ▪ 需求为系统设计、实现和测试提供足够基础。

四、系统架构设计

4.1 面向服务的架构（SOA）

SOA是一种设计、开发、部署和管理离散逻辑单元（服务）的模型，服务设计原则包括：明确定义的接口、自包含和模块化、粗粒度、松耦合、互操作性。

核心相关技术（以XML为基础）

4.2 微服务架构

将单体应用拆分为一组小型服务，每个服务运行在独立进程，通过轻量级通信机制（通常是HTTP/JSON）协作，围绕业务能力构建，可独立部署。

4.2.1 优势

• ▪▪ ▪ 分解单体应用复杂性，降低维护难度。
• ▪▪ ▪ 服务可独立开发，开发者可自由选择技术栈。
• ▪▪ ▪ 独立部署，加快交付速度，减少相互影响。
• ▪▪ ▪ 可根据服务需求独立扩展，适配不同资源需求。

4.2.2 挑战

• ▪▪ ▪ 并非所有系统都适合拆分微服务。
• ▪▪ ▪ 部署复杂度高，需借助容器技术解决。
• ▪▪ ▪ 服务间通信存在延迟或调用出错风险，影响性能。
• ▪▪ ▪ 分布式部署下，数据一致性难以保障。

4.3 C/S架构

4.3.1 二层C/S架构缺点

• ▪▪ ▪ 服务器负荷重，难以管理大量客户机，性能易下降。
• ▪▪ ▪ 数据安全性差，客户端可直接访问数据库，易被非法访问。
• ▪▪ ▪ 难以扩展至大型广域网或Internet，软硬件集成能力有限。

4.3.2 三层C/S架构（表示层、功能层、数据层）优点

• ▪▪ ▪ 三层功能逻辑独立，结构清晰，可维护性和可扩展性提升。
• ▪▪ ▪ 可灵活选用平台和硬件，各层可独立升级，开放性好。
• ▪▪ ▪ 各层可并行开发，选用合适开发语言，提升开发效率和性价比。
• ▪▪ ▪ 功能层隔离表示层与数据层，提升数据安全性。

4.4 B/S架构

三层C/S架构的一种实现方式，结构为“浏览器/Web服务器/数据库服务器”，利用WWW浏览器技术，结合脚本语言，降低开发成本，实现强大功能。

4.5 常用架构模式

4.5.1 MVC模式

• ▪▪ ▪ 模型（Model）：执行业务流程，存储业务数据，不依赖视图和控制器。
• ▪▪ ▪ 视图（View）：展示模型数据，依赖模型，同一份数据可多视图展示。
• ▪▪ ▪ 控制器（Controller）：将用户输入和事件转化为模型方法调用，解释用户行为。

优点：支持多用户界面扩展、易于维护、可构建强大用户界面。

4.5.2 MVP模式

核心优点：模型与视图完全分离，低耦合；Presenter可复用，适配多个视图；可脱离用户接口测试逻辑，可测试性好。

4.5.3 MVVM模式

由MVP进化而来，将Presenter改为ViewModel，支持数据双向绑定，Model变化时ViewModel和View自动更新，保证数据一致性，适合逻辑复杂的前端项目（如管理系统）。

4.6 轻量级架构

• ▪▪ ▪ SSH：Struts2（前端控制器）+ Spring（组件管理）+ Hibernate（持久化层）。
• ▪▪ ▪ SSM：SpringMVC（前端控制器）+ Spring（组件管理）+ Mybatis（持久化层）。

Hibernate与Mybatis区别

• ▪▪ ▪ 开发方面：Hibernate封装SQL，Mybatis为半自动化，需手工编写SQL。
• ▪▪ ▪ SQL优化：Mybatis更便于复杂查询的人工调优。
• ▪▪ ▪ 可移植性：Hibernate自动生成SQL，移植性好；Mybatis手工SQL需适配不同数据库。

4.7 基于架构的软件开发方法（ABSD）

自顶向下、递归细化的方法，核心流程：需求获取→需求评审→架构需求设计→架构需求评审→体系结构设计→架构设计评审→架构文档化→架构复审→架构实现→架构变化（适配需求变化）。

五、系统设计

5.1 面向对象设计（OOD）

5.1.1 分析类图与设计类图区别

• ▪▪ ▪ 分析类图：需求分析阶段，描述应用领域中的概念，从用户角度出发，源于需求。
• ▪▪ ▪ 设计类图：设计阶段，描述软件接口部分，从系统角度出发，在分析类图基础上细化改进。

5.1.2 设计类类型

5.2 常用UML图区别

5.2.1 静态图（描述系统结构，不涉及时间维度）

1. 类图（Class Diagram）

核心用途：描述系统中类的定义、属性、方法，以及类与类之间的关系，是面向对象分析与设计（OOA/OOD）的核心图，也是软考案例分析题高频考点。

• ▪▪ ▪ 类的三要素：属性（成员变量）、方法（成员函数）、可见性（public/private/protected）。
• ▪▪ ▪ 类与类的6种核心关系（优先级：泛化>实现>组合>聚合>关联>依赖），需能区分每种关系的定义、图形标识及实例（如组合：汽车与发动机；聚合：图书馆与书）。

• ▪▪ ▪ 分析类图与设计类图的区别（软考易混淆点）：分析类图面向用户需求，描述业务概念；设计类图面向系统实现，细化为实体类、边界类、控制类。 泛化图（抽象，概化） 实现图（具体） 组合图（整体与部分关系，具有相同生命周期（强关联）） 聚合图（整体与部分关系，各自具有不同生命周期（弱关联）） 关联图（两个类需关联才能表示完整信息）

分析类图与设计类图的区别（软考易混淆点）：分析类图面向用户需求，描述业务概念；设计类图面向系统实现，细化为实体类、边界类、控制类。

组合图（整体与部分关系，具有相同生命周期（强关联））

聚合图（整体与部分关系，各自具有不同生命周期（弱关联））

关联图（两个类需关联才能表示完整信息）

• ▪▪ ▪ 依赖图（car依赖发动机驱动，驱动坏了car也会根据受影响 ）

2. 对象图（Object Diagram）

核心用途：类图的实例化，描述某一时刻系统中具体对象的状态及对象间的关系，是类图的补充。

3. 包图（Package Diagram）

核心用途：用于组织系统中的类、接口、组件等元素，划分系统模块，体现系统的分层结构（如业务层、数据层、接口层）。

4. 接口图（Interface Diagram）

核心用途：描述系统中接口的定义（接口名、方法），以及类与接口的“实现”关系，体现“面向接口编程”思想。

5. 部署图（Deployment Diagram）

核心用途：描述系统硬件设备、软件组件的部署关系，以及设备之间的通信路径，体现系统的物理架构。

5.2.2 动态图（描述系统行为，涉及时间维度）

1. 用例图（Use Case Diagram）

核心用途：描述系统的功能需求，展示参与者（用户、外部系统）与用例（系统功能）之间的交互关系，是需求分析阶段的核心图。

• ▪▪ ▪ 核心元素：参与者（Actor）、用例（Use Case，椭圆表示）、关联关系、包含关系、扩展关系、泛化关系。
• ▪▪ ▪ 用例图的绘制步骤：识别参与者→提取用例→梳理用例关系→完善用例描述。

2. 序列图（Sequence Diagram）

核心用途：描述对象之间的交互过程，按时间顺序展示消息的发送与接收，体现“何时交互”，是动态图中考查频率最高的图。

3. 协作图（Collaboration Diagram）

核心用途：与序列图功能一致，描述 对象之间的交互关系 ，但侧重“空间结构”（对象的组织关系），而非时间顺序。

4. 状态图（State Diagram）

核心用途：描述单个对象的所有可能状态，以及状态之间的转移条件（如“订单”的状态：待支付→已支付→待发货→已发货→已完成）。

5. 活动图（Activity Diagram）

核心用途：描述系统的活动流程（如业务流程、用例执行流程），展示活动的先后顺序、分支、并发，是流程类案例题的核心工具。

5.2.3流程图与活动图比较

• ▪▪ ▪ 流程图：面向过程， 着重描述处理过程，控制结构为顺序、分支、循环，无并发支持 。
• ▪▪ ▪ 活动图：面向对象，着重描述系统行为和活动顺序，支持并发，可展示控制流和数据流。

5.2.4状态图与活动图比较

5.2.5序列图与协作图比较

• ▪▪ ▪ 序列图：强调对象交互的时间次序。
• ▪▪ ▪ 协作图：强调对象交互的空间结构。

5.3 Web设计常见技术

5.4软件产品线

由一组共享公共可管理特征集的产品组成，适配特定领域需求，能提高软件生产率和质量、缩短开发时间、降低总开发成本，适合专业开发组织。

六、数据库设计与优化

6.1数据库设计流程

6.2数据库规范化（范式）

6.3数据库安全性技术

补充：视图是虚拟表，由SELECT查询定义，优点包括：视点集中、简化操作、定制数据、合并分割数据、保证安全性。

6.4数据库完整性技术

6.4.1存储过程

一组完成特定功能的SQL语句集，存储在数据库中，一次编译永久有效。从安全性角度，可避免向第三方暴露表结构，通过调用存储过程更新数据，保障数据安全。

6.4.2触发器

特殊的存储过程，当数据发生变化时自动触发动作，有助于保持数据完整性。

6.5数据库性能优化

6.5.1集中式数据库优化

• ▪▪ ▪ 硬件升级：处理器、内存、磁盘子系统、网络。
• ▪▪ ▪ 数据库设计：反规范化技术（逻辑）、数据库分区（物理）。
• ▪▪ ▪ 索引优化：选择经常查询、不常更新的属性建立索引，数据量小的字段不设索引。
• ▪▪ ▪ 查询优化：建立物化视图，减少多表查询。

6.5.2反规范化技术

6.5.3数据库分区技术

6.5.4分布式数据库优化

• ▪▪ ▪ 主从复制、读写分离：主服务器负责写操作，从服务器负责读操作，避免单点故障，提升查询效率。
• ▪▪ ▪ 数据库分片（分表、分库）：拆分数据，提升处理效率。
• ▪▪ ▪ 分布式缓存技术：将常用数据放入内存，减轻数据库压力。

6.5.5主从复制类型

6.5.6分布式缓存读写流程

• ▪▪ ▪ 读数据：根据key读缓存→读取成功直接返回→缓存未命中则读数据库→读取成功后写缓存→返回结果。
• ▪▪ ▪ 写数据：根据key写数据库→成功后更新缓存key→返回结果。

6.6分布式数据库

数据分布在网络不同计算机上，每个节点具有场地自治能力，可执行局部和全局应用。核心优化技术包括：数据分片、读写分离、负载均衡、分布式缓存。

6.7关系型数据库与NoSQL数据库区别

6.8数据库备份

七、可靠性分析与设计

7.1负载均衡技术分类

八、安全系统设计

8.1网络安全方面

核心目标是防范网络层面的非法入侵、病毒渗透，保障网络传输与设备安全，核心措施包括以下几点

• ▪▪ ▪ 网络隔离：通过物理或逻辑方式划分网络区域，隔离不同安全等级的设备与数据，防止跨区域非法访问，减少安全风险扩散。
• ▪▪ ▪ 路由安全配置：规范路由策略，关闭不必要的路由端口，限制路由访问范围，防范路由欺骗、路由劫持等攻击，保障路由转发的安全性与稳定性。
• ▪▪ ▪ 防火墙与DMZ隔离区：部署硬件防火墙，划分DMZ（隔离区），将对外提供服务的服务器（如Web服务器）放置在DMZ区域，通过防火墙规则限制DMZ与内网、外网的通信，减少内网暴露面。
• ▪▪ ▪ 病毒防护与访问控制：定期更新防火墙及终端病毒库，及时防范新型病毒、恶意代码渗透；采用反向代理模式，仅暴露服务器虚拟IP，隐藏真实服务器地址；配置MAC地址白名单，仅允许白名单内设备接入网络，杜绝非法设备访问。

8.2 应用层面安全

聚焦应用程序的访问安全、数据传输安全，防范应用层攻击，核心措施包括以下几点

• ▪▪ ▪ 多因素登录验证：用户登录时，需完成多重验证，包括用户名+密码验证、图形验证码验证、手机短信验证码验证，多重防护杜绝暴力破解、盗号登录等风险。
• ▪▪ ▪ Token验证机制：根据用户ID、当前时间、用户登录密码生成唯一Token，明确Token生效时间（如2小时），将Token存储在Redis中便于快速校验；用户与服务器端进行交互时，需先校验Token是否失效、是否匹配，校验通过后方可进行后续操作，防范非法请求。
• ▪▪ ▪ 格式压缩与加解密：对应用传输的数据进行格式压缩，减少传输带宽占用，同时对敏感数据（如用户密码、交易信息）进行加密处理，传输过程中采用加密协议，接收端进行解密后再处理，防止数据被窃取、篡改。

8.3 数据层面安全

核心是保障数据的机密性、完整性、可用性，防止数据泄露、篡改、丢失，核心措施包括以下几点

• ▪▪ ▪ 存取权限控制：明确不同角色的存取权限，按最小权限原则分配权限，区分访问权限、写权限、删除权限等，例如普通用户仅拥有数据访问权限，管理员拥有写权限和删除权限，杜绝越权操作。
• ▪▪ ▪ 审计机制：建立完善的数据操作审计体系，自动记录用户对数据的所有操作（如查询、修改、删除），包括操作人、操作时间、操作内容，便于后续安全追溯、违规排查。
• ▪▪ ▪ 容灾备份技术：定期对数据进行备份（包括冷备份、热备份），明确备份周期与备份存储位置，建立容灾恢复机制，当数据发生丢失、损坏时，可快速恢复数据，保障数据可用性；同时对备份数据进行加密保护，防止备份数据泄露。

软考系分的案例与论文，从来不是“背得越多，得分越高”，而是“背得越准，得分越高”。备考时间有限，与其死记硬背所有知识点，不如精准抓核心、找规律、会应用，把时间花在刀刃上。

记住：案例背诵的核心是“框架+考点+真题”，论文背诵的核心是“理论+素材+模板”，避开背诵误区，坚持每天30分钟，重复复盘，你会发现，案例和论文其实没有那么难，甚至可以成为你的提分强项。

距离考试越来越近，愿每一位备考系分的宝子，都能高效背诵、轻松应考，一次性通关，拿下属于自己的软考高级证书✨