【软件架构师-综合题（3）】软件工程知识点

软件工程这一章围绕一个核心问题展开软件不是靠灵感写出来的而是要经过需求、设计、实现、验证、演化这一整条工程链路被稳定地组织起来。顺着这条链路去整理第三章更适合分成六个层次来看先看开发方法和开发模型再看需求与分析然后看软件设计与设计原则接着看 UML 与建模表达再看软件测试最后看遗留系统、逆向工程与维护演化。这样分不是为了形式整齐而是因为这些知识点本来就在软件生命周期里前后相扣。一、开发方法与开发模型先决定软件按什么方式被开发出来软件工程最先要解决的不是“先写哪一行代码”而是“整个开发过程按什么组织”。不同开发模型背后体现的是不同的复用思路、风险控制思路和过程组织方式。1. 构件组装与 CBSE软件可以被组装而不必总是从零开始随着软件复用思想的发展软件开发越来越强调“搭积木”而不是“从头造”。构件组装模型就是这种思想的典型体现。它的一般开发顺序是设计构件组装、建立构件库、构建应用软件、测试与发布。这个顺序背后的逻辑非常自然先规划系统由哪些构件组成、构件之间怎么协作再把可复用的构件沉淀进构件库然后基于这些构件构建应用最后进入测试与发布阶段。题目里最容易错的地方是把“建立构件库”和“设计构件组装”顺序颠倒或者把“构件的修改与维护”混入标准主流程。真正要抓住的是“先设计组装再建库再构建应用最后发布”。基于构件的软件工程也就是 CBSE则更进一步强调软件开发是一条基于可复用构件的工程路径。题目里常考“构件应该具备什么特征”。标准答案通常包括可组装性、可部署性、文档化、独立性、标准化。反过来说不可替代性不是构件应具备的特征因为构件的价值本来就在于它应该尽量标准、可替换、可独立部署而不是和特定环境死绑定。这一部分真正要理解的不只是几个名词而是一个工程思想软件开发不总是重新造轮子而是尽量把共性能力沉淀为标准构件再通过组装提高效率和质量。2. 敏捷方法强调适应变化而不是预设一切敏捷方法是软件工程里非常高频的一类题。它的核心思想可以压缩成三点第一敏捷方法是适应型的而不是强预测型的第二它是迭代增量式的开发过程第三它强调以人为本而不是以僵硬流程为本。因此题目如果问“哪项不属于敏捷方法的核心思想”像“强调以过程为本”“强调预设性”这类说法就不是敏捷的核心。敏捷并不是不要过程而是不把过程僵化到压过人和变化它也不是完全不做计划而是不迷信一开始就能把所有细节预测得精确无误。换句话说敏捷要解决的问题是需求常变、反馈很快、软件必须尽早交付的场景。3. 螺旋模型与 RUP都强调迭代但管理重点不同螺旋模型和统一过程 RUP 都带有明显的迭代特征但它们的关注点不一样。螺旋模型是把瀑布模型与快速原型模型结合起来形成的一种风险驱动型生命周期模型。它把整个开发过程分成多个阶段而每个阶段都由四个部分组成目标设定、风险分析、开发和有效性验证、评审。螺旋模型的关键不在于“转几圈”而在于“每转一圈都先看风险再做开发再评估是否继续”。RUP 也是迭代开发模型但它的组织方式更工程化。从时间维度看RUP 把统一过程划分为四个阶段从工作内容看它包含 9 个核心工作流其中 6 个是核心过程工作流3 个是核心支持工作流。题目里最常见的考点是项目管理工作流不属于核心过程工作流而属于支持工作流。也就是说需求、分析设计、实现、测试、部署、商业建模这些更偏“直接产出软件”的工作流属于核心过程工作流而项目管理、环境、配置与变更管理等更偏支撑性质的工作流属于支持工作流。把这一层收起来看构件组装和 CBSE 强调复用敏捷强调适应变化螺旋模型强调风险驱动RUP 强调迭代中的过程组织。这几类模型虽然名字不同但都在回答同一个问题软件开发过程到底该怎么组织才更稳、更快、更可控。二、需求与分析软件工程的起点不是代码而是把问题说清楚很多软件问题并不是出在编码阶段而是出在一开始需求没有说清楚、分析没有做扎实。所以这一层虽然看起来抽象实际上是整个软件工程的地基。1. 需求工程与需求变更先把变更讲清楚再谈实现代价需求工程里最常考的一类题是需求变更管理。变更管理不是用户一提要求就直接修改而是有明确步骤的。题目中“哪个环节是确保变更建议被详细分析并转化为明确需求变更提议的关键步骤”答案是问题分析和变更描述。这一步的价值在于把一个模糊的“我想改一下”变成一个可以被分析、被评估、被决策的正式变更项。这一步常常会和后面的“变更分析和成本计算”混淆。其实两者是前后关系先把问题分析清楚并描述为明确的变更提议然后才进入影响分析、成本估算和决策。如果连变更本身是什么都没说清楚就不可能准确地讨论代价和实现范围。2. 结构化分析模型很多但核心在数据字典结构化分析通常建立三类模型数据模型、功能模型和行为模型。题目里如果问“这些模型的核心是什么”答案是数据字典。很多人会被实体联系图、状态转换图、流程图这些图形工具吸引误以为“图”就是核心但真正把这些模型统一起来、让对象含义精确定义下来的是数据字典。为什么说数据字典是核心因为数据模型、功能模型和行为模型里都会出现大量数据对象、数据流、数据存储和控制信息。如果这些对象没有统一定义那么再漂亮的图也可能只是“各说各话”。所以结构化分析的本质不是单纯画图而是在建立一套关于“数据是什么、怎么流动、如何被处理”的清晰语言。3. 面向对象分析先分清实体类、边界类和控制类面向对象分析常见的考法是给一个场景让你判断某个对象属于实体类、边界类还是控制类。比如在在线教育平台中“学员类”和“课程类”应设计为实体类“窗口”应设计为边界类。判断的关键在于它的职责。实体类主要用于保存和更新系统中的核心业务信息边界类位于系统与外部环境的交界处负责交互控制类则负责业务逻辑和流程控制。最实用的判断方法是问自己三个问题这个对象主要是存业务数据的吗如果是偏实体类这个对象主要是与外部交互的吗如果是偏边界类这个对象主要是协调流程和逻辑的吗如果是偏控制类。这一层真正想让你建立的是一个意识需求与分析阶段的核心任务不是急着实现而是把问题边界、数据含义、对象职责和变更影响先讲清楚。三、软件设计与设计原则从“需求说明”走向“可实现结构”当需求和分析清楚之后软件工程接下来要做的就是设计。设计阶段回答的问题比“怎么写代码”更前一步系统怎么分、数据怎么组织、界面怎么交互、过程怎么展开、对象怎么解耦。1. 软件设计的四项活动数据、结构、界面、过程软件设计通常包括四项既独立又互相关联的活动数据设计、软件结构设计、人机界面设计和过程设计。这类题常把其中一项挖空让你补齐。这四项活动分工很清楚。数据设计负责把分析阶段得到的数据模型转成适合实现的数据结构软件结构设计负责定义系统主要部件及其关系人机界面设计本质上就是接口设计中面向用户交互的部分关注系统如何和人沟通过程设计则负责把结构部件进一步细化成算法、处理步骤和内部逻辑。这里最容易混的是“接口设计”和“人机界面设计”。考试里有时把人机界面设计单列出来其实它可以看作接口设计面向用户的一部分。做题时抓住标准表述即可数据设计、结构设计、人机界面设计、过程设计。2. 模块设计耦合越低越好高内聚低耦合是基本追求软件设计中的另一个经典考点是模块耦合。耦合表示模块之间联系的强弱通常耦合越低越好因为模块越独立系统越容易维护、修改和复用。题目里常考“七种耦合从低到高排序中的某一位是什么”。在你给出的题里考的是从低到高排第四位对应的是控制耦合。理解这类题最关键的不是背孤立答案而是建立梯度感前面是联系较弱的耦合形式比如非直接耦合、数据耦合、标记耦合越往后模块之间共享的控制、公共环境甚至内部内容越多耦合就越高。控制耦合之所以比数据耦合更强是因为模块之间传递的不只是数据还包含了对内部逻辑的控制信息。这一部分真正考的是软件设计质量意识。考试形式虽然常是排序题但背后逻辑始终是高内聚、低耦合系统才更容易维护和演化。3. 设计模式与面向对象原则系统不仅要能工作还要容易扩展设计模式常考两类内容一类是模式分类一类是面向对象原则。先说模式分类。设计模式通常分为三大类创建型模式、结构型模式和行为型模式。创建型模式关注对象如何创建目的是把“对象的创建”和“对象的使用”分离开结构型模式关注类和对象如何组织成更大的结构行为型模式关注对象之间如何协作完成任务。因此题目里如果描述“是对对象实例化过程的抽象通过抽象类定义接口封装系统中对象如何创建、组合等信息”答案就是创建型模式。而在具体模式里抽象工厂模式也属于创建型模式适配器模式属于结构型模式观察者模式和状态模式属于行为型模式。做题时判断标准很简单它是在解决“怎么创建对象”还是“怎么组织结构”还是“怎么组织行为”。再说面向对象原则。你这批题里出现的两个高频点分别是开闭原则和依赖倒置原则。开闭原则强调“对扩展开放、对修改关闭”也就是尽量在不修改已有代码的前提下为系统增加新行为依赖倒置原则强调“尽量针对接口编程而不是针对实现编程”高层模块不应该依赖低层模块的具体实现而应该依赖抽象。这两个原则经常被放在一起考因为它们共同体现了一个设计方向系统要容易扩展同时要减少具体实现之间的硬绑定。你只要记住提到“扩展已有系统并提供新行为”优先想到开闭原则提到“针对接口编程而不是针对实现”优先想到依赖倒置原则。四、UML 与建模表达把设计想法变成可交流的模型软件设计不仅要想明白还要表达清楚。UML 就是这一层最重要的工具。它考的不是你会不会画图而是你知不知道不同建模元素、不同关系和不同图分别用来表达什么。1. UML 事物与关系先分清“是什么”和“怎么连”UML 中的“事物”也叫建模元素主要包括结构事物、行为事物、分组事物和注释事物。题目里如果问“UML 模型中的动态部分代表时间和空间上的动作属于哪一类事物”答案就是行为事物。这里不要把“动态”和“图的种类”混在一起。UML 的分类是在说模型元素的性质结构事物偏静态行为事物偏动态分组事物负责组织注释事物负责解释。再进一步UML 中两种主要的行为事物通常是交互和状态机。理解这一点以后再看顺序图、状态图这些具体图就更容易知道它们在表达什么。UML 关系也常考。比如在用例图中参与者之间可以存在继承关系。很多人容易把用例与用例之间常见的包含、扩展关系和参与者之间的关系混在一起。判断时要记住包含和扩展是用例与用例之间的关系参与者和参与者之间的泛化本质上就是继承关系。2. UML 图不同图解决不同表达问题UML 2.0 有多种图但考试不会要求你把所有图都展开记只会抓一些高频用途。例如制品图描述计算机中一个系统的物理结构通常与部署图一起使用。部署图描述的是运行时节点和其中构件的配置制品图描述的是文件、数据库等物理制品。题目如果特别强调“物理结构并通常与部署图一起使用”答案就是制品图。再如在用户界面设计过程中可以分别使用 UML 的类图和顺序图来表示用户界面元素以及界面的跳转关系。类图更适合表达界面元素及其静态关系顺序图更适合表达界面切换、交互顺序和跳转过程。很多人会误选用例图或活动图因为它们也能表达用户行为但题目强调的是“界面元素”与“界面跳转”对应的恰好是类图和顺序图。这一层真正要建立的不是记住所有图而是学会“先看题目到底在问静态结构、动态交互、物理部署还是界面跳转”再去匹配图的类型。五、软件测试不是只会测而是知道不同测试在验证什么软件测试是第三章里分量很重的一块。这部分最容易被做成“名词堆”但它其实特别适合从“测试在看什么”来理解。1. 静态测试与动态测试一个看程序运行前一个看程序运行时测试首先可以分成静态测试和动态测试。动态测试是通过运行程序来发现问题黑盒测试和白盒测试大都属于这一类静态测试则不运行程序而是通过人工或工具对程序和文档进行分析例如桌前检查、代码走查、代码审查。所以题目如果问“以下哪种属于静态测试方法”答案是桌前检查。而边界值分析、错误推测法、逻辑覆盖测试都属于动态测试中的典型方法。这里最稳的判断方式就是看要不要运行程序。要运行多半是动态测试不运行偏静态测试。2. 白盒测试覆盖标准路径覆盖最强白盒测试常考覆盖强度。常见覆盖标准有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。题目里如果问“测试强度最高的是哪一种”答案是路径覆盖。之所以是路径覆盖最强是因为它要求程序中每条可能执行到的路径都至少经过一次。相比之下语句覆盖只要求每条语句执行一次判定覆盖要求每个判定结果都出现过一次条件覆盖关注每个条件取值都出现过条件组合覆盖虽然更强但仍不等于所有路径都覆盖到。路径覆盖在逻辑完整性上最强因此常被视为最高强度。理解这部分时不要只记“谁最强”还要建立层级感语句覆盖最弱往上一步步增强到路径覆盖最强。3. 自动化测试与 Web 测试关注脚本类型和测试重点自动化测试里一个高频点是测试脚本的类型。题目中“通过录制用户操作直接生成的脚本”对应的是线性脚本。因为线性脚本本质上就是把人工操作过程录下来然后回放执行。相对地结构化脚本更强调逻辑结构和复用共享脚本强调多个用例共用数据驱动脚本则把测试数据从脚本中分离出来。Web 测试则常考“测试重点”和“典型说法判断”。例如链接测试需要保证 Web 应用系统上没有孤立页面这个说法是正确的。这里的逻辑是链接测试不只是点开链接看能不能跳还要确认页面之间的连接关系是完整的不存在用户无法通过正常导航到达、也无法从系统路径中返回的孤立页面。另外Web 测试和其他系统测试并不是“内容完全不同”而是总体测试思想基本相同只是在测试重点上更强调链接、表单、页面跳转、兼容性等内容。类似地AB 测试也不是“金丝雀测试”。AB 测试更偏多版本并行比较收集用户反馈金丝雀发布则是逐步扩大新版本流量范围两者不是一回事。4. 测试与调试发现问题和定位修复问题不是一回事测试和调试也常被放在一起考。最核心的结论是调试是测试之后的活动测试和调试在目标、方法和思路上都有所不同。测试的目标是尽可能发现软件中存在的错误它通常从一个已知条件开始按预先设计好的过程执行并且结果是否符合预期是可以事先判断的调试则是在测试发现问题之后进一步定位错误原因、分析缺陷位置并修改程序它更像一个探索和追踪过程结束时间和具体路径往往难以预先精确描述。很多人会把“找错误”看成调试的目的但更准确地说测试负责暴露问题调试负责定位和修复问题。这也是两者最大的分工差异。六、遗留系统、逆向工程与维护演化软件不是做完就结束软件工程最后一层常被忽视但很有“工程现实感”因为现实里的软件往往不是从零开始也不是上线后就一劳永逸。旧系统要不要改、怎么迁移、怎么恢复设计、怎么维护这些都属于软件工程必须面对的长期问题。1. 遗留系统演化不是一刀切而是看技术价值和业务价值遗留系统的演化策略一般包括淘汰策略、继承策略、改造策略和集成策略。不同策略背后的判断标准主要看遗留系统的技术含量、业务价值和剩余生命力。如果一个遗留系统技术含量较高本身还有很大的生命力而且系统具有较高的业务价值基本上还能满足企业业务运作和决策支持的需要那么更适合采用的是改造策略。这里的关键词是“系统本体还值得继续投入”也就是说不需要立刻全面替换而是在原有系统基础上进行增强和调整。而如果在开发新系统时需要完全兼容遗留系统的功能模型和数据模型为了保证业务连续性新老系统还必须并行运行一段时间再逐渐切换到新系统这种情形对应的是继承策略。它不是单纯“保留旧系统”而是在过渡期里保持兼容和连续让业务平稳迁移。2. 逆向工程从已有系统里把设计信息倒推出来逆向工程常被定义为设计的恢复过程。它并不是简单地读代码而是试图从现有系统中导出不同抽象层次上的信息。常见的抽象层级包括实现级、结构级、功能级和领域级。其中领域级反映的是程序分量或程序诸实体与应用领域概念之间对应关系的信息因此它最接近“这个系统在业务上到底表达了什么”。题目里如果直接问“哪个层级反映程序实体与应用领域概念之间的对应关系”答案就是领域级。进一步逆向工程的方法和层级之间也常被对应起来。用户指导下的搜索与变换方法主要用于导出实现级和结构级信息变换式方法可以导出实现级、结构级和功能级基于领域知识的方法主要用于导出功能级和领域级信息铅板恢复法则主要用于导出实现级和结构级。这里最值得记的是如果题目问“哪种方法用于导出功能级和领域级信息”优先想到基于领域知识的方法。3. 系统转换与软件维护系统上线以后工程工作并没有结束系统转换方式里若想把新旧系统切换风险降到最低最合适的是并行转换。因为并行转换意味着新旧系统同时运行一段时间可以边跑边验证安全性最高代价是成本更高。直接转换最省事但风险最大分段转换则是折中的混合方式。做题时凡是问“风险最低”优先想到并行转换凡是问“成本最低或最快”才可能考虑直接转换。软件维护则要分清类型。识别和纠正软件错误、缺陷属于正确性维护让软件适应环境变化属于适应性维护增加功能、改善性能属于完善性维护为了面向未来变化提前做准备属于预防性维护。这里最容易混的是“修复错误”和“功能增强”前者是正确性维护后者是完善性维护。这一部分的意义在于提醒你软件工程不是开发结束就结束真正的系统生命周期里迁移、维护、改造和恢复设计信息都是必须长期面对的工程工作。最后把这一章压缩成一条适合复习的主线可以这样理解软件工程先要选择合适的开发组织方式所以会考构件组装、CBSE、敏捷、螺旋模型和 RUP接着要把需求和对象分析清楚所以会考需求变更管理、结构化分析、面向对象分析然后进入软件设计阶段所以会考软件设计四项活动、模块耦合、设计模式和面向对象原则为了把设计清楚表达出来又会考 UML 的事物、关系和图之后为了验证系统是否正确又会考静态测试、动态测试、白盒覆盖、自动化测试、Web 测试以及测试与调试的区别最后再回到工程现实思考遗留系统如何演化、逆向工程如何恢复设计信息、系统怎样转换、软件如何维护。七、考前速记如果考前速记可以抓住这些高频点构件组装模型顺序是设计构件组装、建立构件库、构建应用软件、测试与发布CBSE 构件具有可组装性、可部署性、文档化、独立性、标准化不包括不可替代性敏捷方法强调适应型、迭代增量、以人为本不强调以过程为本和预设性螺旋模型每阶段四部分是目标设定、风险分析、开发和有效性验证、评审RUP 中项目管理工作流属于支持工作流不属于核心过程工作流需求变更中问题分析和变更描述是把建议转成明确变更提议的关键步骤结构化分析模型的核心是数据字典在线教育场景里学员类和课程类是实体类窗口是边界类软件设计四项活动是数据设计、结构设计、人机界面设计和过程设计UML 中动态部分对应行为事物参与者之间可有继承关系制品图描述物理结构类图和顺序图可用于用户界面建模创建型模式解决对象创建问题抽象工厂模式属于创建型模式开闭原则强调扩展开放、修改关闭依赖倒置原则强调针对接口编程白盒测试中路径覆盖最强静态测试包括桌前检查、代码走查、代码审查录制生成的测试脚本是线性脚本Web 链接测试要保证没有孤立页面测试负责发现错误调试负责定位并修复错误遗留系统技术含量高、业务价值高、生命力强时适合改造策略而需要兼容旧系统并平滑迁移时适合继承策略逆向工程中领域级对应应用领域概念功能级和领域级信息可由基于领域知识的方法导出系统转换想把风险降到最低用并行转换识别和纠正软件错误属于正确性维护模块耦合从低到高记住控制耦合位于中间偏上位置比数据耦合和标记耦合更强。