第二章信息系统与软件工程 · 系统架构设计师

🏢

信息系统类型

概念辨析

📊五类信息系统

类型	全称	服务对象	功能特点	典型示例
TPS	事务处理系统	基层操作人员	处理日常业务事务，结构化程度高，数据量大	银行交易、订单处理、考勤系统
MIS	管理信息系统	中层管理者	提供定期报告，辅助日常管理决策，基于TPS数据	财务报表系统、库存管理系统
DSS	决策支持系统	高层管理者	支持半结构化/非结构化决策，数据驱动+模型驱动	投资分析系统、市场预测系统
ES	专家系统	各专业领域	模拟人类专家决策，基于知识库+推理机	医疗诊断系统、故障排查系统
OAS	办公自动化系统	全体员工	提高办公效率，文档管理、流程审批、协同办公	OA系统、邮件系统、视频会议

💡

层次关系：TPS是基础，为MIS提供数据；MIS汇总TPS数据，为DSS提供支撑。决策复杂度从TPS到DSS递增，结构化程度递减。

信息系统层次关系图

DSS 决策支持系统 — 高层战略决策
MIS 管理信息系统 — 中层管理控制
TPS 事务处理系统 — 基层业务操作

数据流向：TPS → MIS → DSS｜结构化程度递减

🏗️

企业架构框架

常考

📐主流框架对比

框架	核心特点	关键概念	适用场景
TOGAF	最流行的企业架构框架	ADM（架构开发方法）：预备→架构愿景→业务架构→信息系统架构→技术架构→机会与解决方案→迁移规划→实施治理→架构变更管理	企业级架构规划
Zachman	二维分类矩阵框架	6×6矩阵：行（数据/功能/网络/人员/时间/动机）×列（范围/业务模型/系统模型/技术模型/组件/运行系统）	架构分类与描述
FEAF	美国联邦政府架构框架	五参考模型：绩效、业务、服务、数据、技术	政府/公共部门
DoDAF	美国国防部架构框架	八视图：全视图、能力视图、作战视图、服务视图、标准视图、系统视图、项目视图、数据视图	国防/军事

🎯TOGAF四大架构域

业务架构（BA）：定义企业的业务战略、治理、组织和关键业务流程

数据架构（DA）：描述企业的逻辑和物理数据资产及数据管理资源结构

应用架构（AA）：定义需要部署的单个应用系统蓝图及其交互关系

技术架构（TA）：描述支撑应用部署所需的硬件、网络、中间件等技术基础设施

⚠️

常考辨析：TOGAF的核心是ADM（Architecture Development Method），是一个循环迭代的过程。Zachman是分类框架（不是方法论），描述"什么"而不是"怎么做"。

🔧

软件开发模型

★★★★★

📋传统开发模型

模型	特点	优点	缺点	适用场景
瀑布模型	线性顺序，阶段间有明确界限	文档驱动、管理简单	不灵活、需求变更成本高	需求明确且稳定的项目
增量模型	分批次交付，每个增量是完整子集	早期可用、风险分散	需良好架构设计	需求大致明确，可分批交付
原型模型	快速构建原型验证需求	降低需求风险、用户参与度高	原型可能被误用为最终产品	需求不明确、用户参与度高
螺旋模型	瀑布+迭代+风险分析	风险驱动、适合大型项目	复杂、成本高、需要风险评估经验	大型、高风险、复杂项目
喷泉模型	面向对象，迭代且无间隙	适合OOP、阶段重叠	管理复杂	面向对象的软件开发

⚡敏捷与DevOps

Scrum：Sprint（2-4周迭代）、Product Backlog、Sprint Backlog、每日站会、评审会、回顾会。角色：Product Owner、Scrum Master、开发团队

XP（极限编程）：结对编程、测试驱动开发（TDD）、持续集成、重构、小步发布、集体代码所有权

Kanban（看板）：可视化工作流、限制在制品（WIP）、拉动式生产、持续交付

DevOps：开发（Dev）+运维（Ops）一体化。核心实践：CI/CD、基础设施即代码（IaC）、自动化测试、持续监控

⚠️

公式记忆：螺旋模型 = 瀑布模型 + 迭代开发 + 风险分析。XP强调"技术实践"，Scrum强调"管理框架"。瀑布模型需求变更成本随时间推移呈指数增长。

V模型 — 开发阶段与测试阶段对应关系

开发阶段（左侧）

需求分析
概要设计
详细设计
编码实现

⇅

一一对应

测试阶段（右侧）

单元测试 ← 详细设计
集成测试 ← 概要设计
系统测试 ← 需求分析
验收测试 ← 用户需求

📝

需求工程

高频

🔄需求工程四阶段

需求获取：访谈、问卷调查、观察、原型、头脑风暴、联合应用设计（JAD）、用户故事

需求分析：功能需求（系统做什么）+ 非功能需求（性能、安全、可用性等）。工具：DFD（数据流图）、数据字典（DD）、状态转换图、ER图

需求定义：输出SRS（软件需求规格说明书）。应具ite、无歧义、可验证、可追溯

需求验证：需求评审（正式评审/走查）、原型验证、检查表。确保需求的正确性、完整性、一致性

📊DFD（数据流图）元素

元素	符号	说明	示例
外部实体	矩形/方框	数据来源或去向，在系统外部	用户、外部系统
加工/处理	圆/圆角矩形	对数据进行变换处理	计算工资、验证用户
数据存储	开口矩形/双横线	数据的静态存储	数据库、文件
数据流	箭头	数据在系统中的流动方向	订单信息、查询结果

💡

DFD规则：①加工必须有输入和输出 ②数据流必须从加工流出或流入加工（外部实体↔存储不能直接连接） ③父子图必须平衡（子图输入输出流与父图加工一致）

🎨

软件设计

★★★★★

🔗耦合与内聚

类型	耦合程度	说明
内容耦合	最高（最差）	一个模块直接修改或依赖另一个模块的内部数据
公共耦合	高	多个模块共享同一个全局数据区
外部耦合	较高	多个模块共享同一个外部环境（如文件格式）
控制耦合	中等	一个模块向另一个模块传递控制信号（如flag）
标记耦合	较低	传递数据结构的一部分（通过参数引用）
数据耦合	最低（最好）	仅通过参数传递简单数据项
非直接耦合	无	两个模块之间没有任何联系

🎯内聚类型排序

类型	内聚程度	说明
偶然内聚	最低（最差）	模块内各部分之间毫无关联，只是凑在一起
逻辑内聚	很低	模块执行逻辑上相关的多个功能，由参数决定执行哪个
时间内聚	较低	模块内任务在同一时间段内执行（如初始化模块）
过程内聚	中等	模块内任务按特定顺序执行（前一个输出是后一个输入）
通信内聚	较高	模块内所有操作处理同一数据集
顺序内聚	高	模块内前一处理的输出是后一处理的输入
功能内聚	最高（最好）	模块所有部分共同完成单一功能

📐设计原则

开闭原则（OCP）：对扩展开放，对修改关闭。核心原则

单一职责（SRP）：一个类/模块只负责一项职责

里氏替换（LSP）：子类对象可以替换父类对象而不影响程序正确性

依赖倒置（DIP）：高层模块不应依赖低层模块，两者都应依赖抽象

接口隔离（ISP）：客户端不应依赖它不需要的接口

迪米特法则：最少知识原则，对象应尽可能少地了解其他对象

合成复用原则：优先使用组合而非继承来复用代码

⚠️

设计目标：追求"高内聚、低耦合"。耦合程度从低到高：无→数据→标记→控制→外部→公共→内容。内聚程度从低到高：偶然→逻辑→时间→过程→通信→顺序→功能。考试中常给出代码场景让判断耦合/内聚类型。

耦合程度对比（从低到高）

非直接耦合

无联系

数据耦合

传简单数据

标记耦合

传数据结构

控制耦合

传控制信号

外部耦合

共享外部环境

公共耦合

共享全局数据

内容耦合

直接访问内部

目标：低耦合（绿色区域）｜避免：高耦合（红色区域）

🧪

软件测试

高频

📊测试级别与V模型

单元测试：测试单个模块/函数。白盒为主。对应详细设计

集成测试：测试模块间集成。关注接口。对应概要设计

系统测试：测试整个系统是否满足需求。黑盒为主。对应需求规格

验收测试：用户验证是否满足业务需求。Alpha（开发方场所）/Beta（用户场所）

🔍黑盒 vs 白盒测试

对比项	黑盒测试	白盒测试
视角	外部行为（功能）	内部结构（代码逻辑）
依据	需求规格说明	源代码
常用方法	等价类划分、边界值分析、因果图、判定表、状态迁移、场景法	语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖（基本路径测试）
覆盖率	功能覆盖率	代码覆盖率
谁执行	测试人员/用户	开发人员

⚡白盒覆盖强度排序

语句覆盖（最弱）：每条语句至少执行一次

判定覆盖：每个判定的真假分支各执行一次

条件覆盖：每个条件的真假各执行一次

判定/条件覆盖：同时满足判定覆盖和条件覆盖

条件组合覆盖：每个条件的所有可能组合各执行一次

路径覆盖（最强）：每条可能路径至少执行一次

📈性能测试类型

负载测试：在预期负载下测试系统性能表现

压力测试：超过正常负载，测试系统极限和崩溃点

稳定性测试：长时间运行，检测内存泄漏等问题

并发测试：模拟多用户同时操作，检测死锁和竞争条件

⚠️

V模型对应关系：需求分析→验收测试、概要设计→系统测试、详细设计→集成测试、编码→单元测试。注意对应方向是"镜像"的。路径覆盖最强但通常不可实现（路径数可能无穷），语句覆盖最弱。

🔧

软件维护

常考

🛠️四种维护类型

类型	占比	说明	示例
完善性维护	~50%（最大）	为满足用户新需求或改进性能而修改	新增功能、提升响应速度
改正性维护	~25%	修复发现的缺陷/bug	修复崩溃、逻辑错误
适应性维护	~20%	为适应外部环境变化而修改	操作系统升级、数据库迁移
预防性维护	~5%（最小）	为提高可维护性/可靠性而主动修改	重构代码、优化文档

💡

记忆口诀："完改适预"——完善性最多（用户总想要新功能），预防性最少（没人愿意主动改没坏的东西）。考试常考判断场景属于哪种维护类型。

📦

软件复用与构件

常考

🧩CBSE（基于构件的软件工程）

构件特征：可复用、独立部署、接口标准化、自包含

构件标准：COM/DCOM（微软Windows）、CORBA（OMG，跨平台，IDL定义接口）、EJB（Java企业版）

构件获取：从现有代码提取、商业购买、自主开发、开源社区

🎭设计模式分类

分类	目的	常见模式
创建型	对象的创建方式	单例（Singleton）、工厂方法（Factory Method）、抽象工厂（Abstract Factory）、建造者（Builder）、原型（Prototype）
结构型	类/对象的组合方式	适配器（Adapter）、装饰器（Decorator）、代理（Proxy）、外观（Facade）、桥接（Bridge）、组合（Composite）、享元（Flyweight）
行为型	类/对象间的职责分配	观察者（Observer）、策略（Strategy）、模板方法（Template Method）、命令（Command）、状态（State）、责任链（Chain of Responsibility）、访问者（Visitor）

💡

复用层次：代码级复用（函数/类）→ 构件级复用（模块/组件）→ 架构级复用（框架/模式）→ 领域级复用（DSSA特定领域软件架构）。层次越高复用粒度越大、价值越高。

📝

章节练习

自测

📝 本章练习题正在加载...