北京大学研究生课程《软件工程》

北京大学研究生课程《软件工程》国家级一流本科课程·系统掌握软件开发与维护的工程化方法学Contents课程知识体系总览北京大学研究生课程《软件工程》五大核心模块，从基础理论到工程实践的完整知识脉络。01软件工程概论与基本框架02软件过程与需求工程03结构化分析与设计方法04面向对象技术与UML建模05敏捷开发、测试与编码实现CHAPTER01软件工程概论与基本框架从软件本质出发，理解工程化方法的核心价值与学科框架SOFTWAREENGINEERING·基础概念软件的定义与核心特点软件是程序、数据与文档的完整集合，作为逻辑实体而非物理实体存在。其无形性、不磨损性、高开发低成本复制等特征，决定了软件质量管理和项目管理面临独特挑战，也是软件工程学科产生的根本原因。01三元构成—软件由程序、数据和文档三部分构成，不仅指可执行代码，还包括需求规格、设计文档、用户手册等全套工程产出物。02逻辑实体—软件无法通过感官直接检验质量，必须依赖评审、测试、度量等间接手段保障品质。03不磨损但退化—软件不会像硬件那样物理磨损，但会因需求变更和环境迁移而退化，维护成本往往超过初始开发。04高智力密集—复制成本趋近于零，但开发过程需要大量人力和时间投入，项目失败风险显著。北京大学信息科学技术学院·教学环境SOFTWAREENGINEERING·ORIGINS软件危机与软件工程的起源20世纪60年代的"软件危机"——项目超期、预算失控、质量低下——直接催生了软件工程学科。1968年NATO会议首次提出"软件工程"概念，标志着软件开发从个人手工作坊模式向系统化工程方法的根本转变。01规模膨胀，方法缺失——20世纪60年代软件规模急剧膨胀，但开发仍依赖个人编程技巧，缺乏系统化方法论，导致项目超期率超过60%、预算超支成为常态。60%+OVERRUN02质量危机常态化——已交付软件中约50%存在严重缺陷，维护成本占软件总成本的55%以上，"开发完就废弃"的现象普遍存在。55%MAINTENANCE03学科正式诞生——1968年北约（NATO）软件工程会议在德国召开，首次正式提出"SoftwareEngineering"概念，倡导用工程化原则指导软件开发。1968NATO04核心方法论确立——将系统化、规范化、可度量的方法应用于软件开发、运行和维护的全过程，实现从手工作坊到工程化的范式转变。ENGINEERINGFUNDAMENTALS软件开发的本质与基本手段软件开发的本质是将现实世界的问题域映射到计算机世界的解域，核心活动包括问题理解（需求分析）与解法构造（设计实现）。软件工程通过过程、方法和工具三大手段的协同，使这一映射过程从不可控的艺术创作转变为可控的工程实践。核心挑战软件开发的核心挑战在于"从问题空间到解空间的映射"，即将模糊的现实需求转化为精确的计算机可执行方案映射过程过程定义软件开发的阶段、活动和里程碑，为团队提供统一的协作框架和质量保障机制协作框架方法方法提供每个阶段的具体技术手段，如结构化分析、面向对象设计、形式化验证等分析与设计方法设计方法工具工具通过CASE环境实现自动化支撑，覆盖需求管理、代码生成、测试执行、配置管理等全生命周期全生命周期SoftwareEngineeringFramework软件工程的三维框架体系软件工程知识体系可从过程、方法、工具三个维度理解：过程维度定义开发活动的时序与规范，方法维度提供各阶段的技术手段，工具维度实现自动化支撑。三者协同构成完整的工程化方法论，缺一不可。过程维度定义软件从构思到退役的全生命周期阶段划分，包括瀑布、迭代、敏捷等不同过程模型规定各阶段的输入、输出、评审准则和质量门禁，确保开发活动的有序性和可追溯性生命周期方法维度涵盖结构化方法与面向对象方法两大主流范式，分别适用于不同复杂度的系统开发包含需求工程、架构设计、详细设计、编码实现、测试验证、维护演化等全链路技术方法全链路工具维度CASE工具覆盖需求管理、建模、代码生成、测试自动化等环节集成开发环境与版本控制系统构成现代软件开发的基础设施，支撑团队协作与持续交付自动化CHAPTER02软件过程与需求工程选择合适的过程模型规划开发节奏，运用系统化方法捕获和规约用户需求SoftwareEngineering软件生存周期过程软件生存周期描述了软件从概念提出到最终退役的完整演进过程，通常包含可行性研究、需求分析、设计、编码、测试、运行维护六大阶段。其中运行维护阶段持续时间最长、成本占比最高，是软件工程中不可忽视的关键环节。01可行性研究与计划评估项目的技术可行性、经济合理性和资源可得性，分析投资回报率与风险因素，决定是否正式启动项目📋项目启动决策02需求分析通过用户访谈、场景分析、用例建模等手段，将模糊的业务需求转化为结构化的需求规格说明书📝需求规格说明书03系统设计分为概要设计和详细设计两个层次，前者定义系统架构和模块划分，后者细化每个模块的内部逻辑与接口🏗️概要+详细设计04编码实现将设计文档转化为可执行的程序代码，遵循编码规范，进行代码审查，确保实现与设计的一致性💻代码开发与审查05测试验证通过单元测试、集成测试、系统测试和验收测试，发现并修复缺陷，验证软件是否满足需求规格🔍多层级测试体系06运行维护持续软件全生命周期的60%–80%时间，包括纠错性、适应性、完善性和预防性维护四类核心活动🔄60%–80%时间占比LIFECYCLEMODELS常见软件生存周期模型对比软件过程模型定义了开发活动的组织方式和阶段衔接逻辑。瀑布模型适合需求明确的场景，增量与螺旋模型应对需求不确定性，原型模型侧重需求验证。模型选择的本质是根据项目特征匹配最合适的管理策略。SECTION01传统线性模型瀑布模型按需求→设计→编码→测试→维护严格顺序推进，阶段间有明确评审门禁，适合需求稳定且充分理解的项目V模型强调开发阶段与测试阶段的对应关系，每个开发阶段都有对应的验证活动，突出质量保证的前置性SECTION02演进迭代模型增量模型将系统功能分批交付，每个增量都是可运行的完整子系统，降低交付风险并加速价值实现螺旋模型在每个迭代周期中加入风险分析环节，特别适合高风险、大规模、需求不确定的复杂项目原型模型通过快速构建可交互原型来验证和细化需求，有效降低需求不确定性带来的返工成本瀑布模型经典教学场景团队敏捷迭代协作场景REQUIREMENTSENGINEERING需求工程：定义、分类与发现方法需求是软件开发的基石，超过50%的软件缺陷可追溯至需求阶段的问题。需求分为功能需求、非功能需求和设计约束三类。需求发现的核心挑战在于从用户的表面表述中挖掘出真实、完整、一致的需求，这需要系统化的方法和丰富的领域经验。01功能需求定义系统必须提供的服务和行为，如"用户可以按姓名或学号查询成绩"；非功能需求约束质量属性，如响应时间、并发用户数、安全等级。功能需求关注"做什么"，非功能需求关注"做得怎样"，二者共同构成完整的需求规格。02需求发现的主要手段包括用户访谈、问卷调查、现场观察、文档分析、原型演示等，多种方法组合使用效果最佳。访谈适合深度挖掘，问卷适合大规模收集，观察适合发现隐性需求，原型适合快速验证。03需求规约(SRS)是需求分析阶段的最终产出，需遵循IEEE830标准格式，确保完整性、一致性、可验证性和可追溯性。良好的需求规约是开发、测试、验收的共同基准，也是项目变更管理的重要依据。04需求验证通过评审和原型测试确认需求的正确性，需求变更管理则通过变更控制委员会(CCB)流程控制变更影响。验证确保需求质量，变更管理确保需求演化可控，二者保障项目按计划推进。RequirementsEngineering软件需求规格说明书(SRS)的规范与编写软件需求规格说明书(SRS)是需求工程的正式产出物，遵循IEEE830标准，充当用户、开发方和测试方之间的"契约"。标准结构包括引言、总体描述、具体需求三大部分，具体需求涵盖功能、接口、性能与质量属性。采用模板化编写方式，确保各章节逻辑清晰、内容完整。IEEE830完整性所有利益相关方需求均须识别并记录，遗漏将导致后期返工成本成倍增加。建立需求检查清单，逐项验证功能点与约束条件的覆盖程度。100%覆盖一致性不同需求间不存在逻辑矛盾，如响应时间与全表扫描的隐含冲突须提前排查。定期进行需求评审与交叉验证，消除术语歧义与业务规则冲突。0冲突可追溯性通过追踪矩阵确保每条需求从来源到设计、代码、测试用例双向可追溯。唯一标识符贯穿全生命周期，支持变更影响分析与版本回溯。双向追踪Chapter03结构化分析与设计方法掌握自顶向下、逐步求精的经典方法论，构建模块化软件设计的基础能力STRUCTUREDANALYSIS结构化分析方法：数据流图与逐层分解结构化分析(SA)采用"自顶向下、逐层分解"策略，将复杂系统分解为可管理的数据处理层次。数据流图(DFD)是其核心建模工具。北京大学软件工程课程教学场景数据流图(DFD)：用图形化方式描述系统中数据的来源、去向、存储和处理过程，分为顶层图、0层图和各层细化图数据字典(DD)：精确定义DFD中所有数据流、数据存储和数据项的名称、组成结构和取值约束，是分析模型的"词典"自顶向下分解：先确定系统边界和外部接口，再逐层分解内部加工，直到每个加工足够简单可以直接描述加工说明(PSPEC)：用结构化语言、判定表或判定树描述每个底层加工的处理逻辑，确保需求描述的完整性和无歧义性SoftwareDesign结构化设计：从数据流到模块结构结构化设计(SD)将分析阶段的DFD转化为软件的模块化结构，分为概要设计和详细设计两个阶段。概要设计通过变换分析或事务分析策略生成初始模块结构图，再依据高内聚低耦合原则进行精化；详细设计则用流程图、伪代码等工具描述每个模块的内部算法逻辑。01概要设计映射通过变换分析（适用于线性数据流）或事务分析（适用于分发型数据流）将DFD映射为初始模块结构图02模块精化规则遵循七条启发式规则：模块规模适度、深度宽度合理、单入口单出口、功能内聚、数据耦合优先等原则03详细设计工具使用流程图、N-S盒图、PAD图和伪代码(PDL)等工具，精确描述每个模块的算法逻辑和数据结构04接口与数据设计接口设计定义模块间调用关系和数据传递，数据设计确定全局数据结构和数据库模式，两者共同构成系统骨架SoftwareEngineering·ModuleDesign模块化设计核心：内聚与耦合高内聚低耦合是软件模块化设计的最高原则。内聚度越高，模块职责越单一明确；耦合度越低，模块间依赖越松散。追求功能内聚和数据耦合是设计的理想目标，可显著提升系统的可维护性、可复用性和可测试性。内聚类型（低→高）CohesionLevels01巧合内聚(最低)→逻辑内聚→时间内聚→过程内聚→通信内聚→顺序内聚→功能内聚(最高)，设计目标是追求功能内聚02功能内聚的模块只完成一个明确定义的功能，易于理解、测试和复用，是模块化设计的理想状态03高内聚模块职责边界清晰，修改影响范围可控，代码可读性强，便于团队协作与长期维护功能内聚耦合类型（低→高）CouplingLevels01数据耦合(最低)→标记耦合→控制耦合→外部耦合→公共耦合→内容耦合(最高)，设计目标是保持数据耦合、避免公共和内容耦合02数据耦合的模块间仅通过参数传递简单数据项，接口清晰且影响范围可控，是模块间交互的最佳方式03低耦合设计降低模块间依赖，局部变更不会引发连锁反应，系统架构更加灵活稳定数据耦合CHAPTER04面向对象技术与UML建模掌握面向对象的核心概念与UML统一建模语言，建立从分析到设计的完整建模能力CoreConcepts面向对象五大核心概念面向对象方法以类与对象为基础单元，通过封装实现信息隐藏、继承实现代码复用与层次分类、多态实现灵活的行为扩展、消息传递实现对象间协作。这五个核心概念共同构成面向对象编程与设计的理论基础。类与对象类(Class)是对具有相同属性和行为的一组对象的抽象模板，对象(Object)是类的具体运行时实例，二者构成面向对象系统的基本单元，是构建软件模型的起点Class/Object封装封装(Encapsulation)将数据与操作绑定为一个整体并隐藏内部实现细节，外部只能通过预定义接口访问对象，有效降低系统各部分之间的耦合度Encapsulation继承继承(Inheritance)允许子类复用父类的属性和方法并可扩展或覆盖，建立类之间的层次关系，是实现代码复用和构建类层次结构的核心机制Inheritance多态多态(Polymorphism)使同一操作在不同对象上表现出不同行为，结合动态绑定实现灵活的运行时行为分派，显著增强系统的可扩展性和可维护性Polymorphism消息传递消息传递(MessagePassing)是对象间通信的唯一方式，对象通过发送消息请求其他对象执行操作，实现对象间的协作与交互，是系统动态行为的基础MessagePassingSoftwareEngineering·Chapter03UML统一建模语言：概述与图分类UML是OMG标准化的可视化建模语言，涵盖结构图与行为图两大类14种图形，其中类图、用例图、顺序图、状态图为工程实践核心。结构图Structural描述系统的静态组成与层次关系，包括类图、对象图、包图、组件图、部署图、复合结构图和轮廓图共7种图形，用于展现系统的结构特征与静态架构7种图形行为图Behavioral描述系统的动态行为与交互过程，包括用例图、活动图、状态机图、顺序图、通信图、交互概览图和时序图共7种图形，用于展现系统的行为特征与动态流程7种图形课程重点重点讲授类图（静态建模核心）、用例图（需求建模）、顺序图（交互建模）、状态图（生命周期建模）四种高频图形，掌握这4种核心图形即可应对大多数软件建模场景4种核心互补关系类图描述"系统有什么"，用例图描述"系统能做什么"，顺序图描述"系统内部如何协作完成功能"，三者从不同维度刻画系统，形成完整的建模视角3维视角ClassDiagramUML类图：类的表示与关系类型类图是UML静态建模的核心工具，通过类名、属性和操作三栏结构描述类的内部组成，通过关联、聚合、组合、泛化和依赖五种关系描述类之间的结构联系。01三栏矩形结构类名栏（必须）位于顶部，属性栏记录名称、类型及默认值，操作栏定义方法签名与返回类型。ClassName-attr:Type+method():ReturnThree-Compartment02可见性标记通过前缀符号精确控制类成员的访问范围，实现封装与信息隐藏的设计原则。+public公有访问−private私有访问#protected受保护Visibility03关联与聚合关联描述类之间的结构连接，可标注多重性；聚合表示整体与部分的弱拥有关系，部分可独立存在。

空心菱形：聚合1..*——0..*Aggregation04组合与泛化组合是强生命周期依赖的强拥有关系；泛化通过继承实现代码复用与多态扩展。◆实心菱形：组合▷空心三角：泛化Composition05依赖关系虚线箭头表示操作中的临时使用关系，是最弱的关系类型，常见于参数传递、局部变量或静态调用。⤑虚线箭头：依赖use→usedDependencyUML·UseCaseDiagramUML用例图：需求视角的功能建模用例图从用户视角描述系统的功能需求，通过参与者、用例和关系三要素构建系统的功能全景。用例图是需求分析阶段与客户沟通的核心工具，也是后续设计阶段识别类和交互的重要输入。01参与者（Actor）是与系统交互的外部实体，可以是人类用户、外部系统或硬件设备，每个参与者代表一种角色而非具体个人。Actor02用例（UseCase）描述系统为参与者提供的一项完整、有价值的功能，命名应使用"动词+宾语"格式，如"提交订单""查询成绩"。动词+宾语03包含（include）关系表示基础用例必须执行被包含用例，用于提取公共行为；扩展（extend）关系在特定条件下可选地增强基础用例。include/extend04编写原则：每个用例应对参与者有独立价值，粒度适中（通常对应一个完整的用户目标），避免过度细化或过度笼统。独立价值大学图书馆自助服务场景·用例图教学案例参考UMLDynamicModelingUML动态建模：顺序图与状态图顺序图和状态图是UML动态建模的两大核心工具，两者互补构成完整的动态行为模型。顺序图SequenceDiagram生命线交互：以对象的生命线为纵轴、时间为横轴，展示对象间消息传递的时间顺序，适合描述用例的具体实现场景消息类型：同步消息(实线实心箭头)、异步消息(实线空心箭头)和返回消息(虚线)，可标注条件约束和循环片段开发团队协作讨论交互设计状态图StateMachineDiagram状态转换：描述单个对象在生命周期内的所有可能状态及其转换条件，由事件触发状态迁移，可附带动作和守卫条件业务建模：复杂对象如订单、审批流程等适合用状态图建模，帮助团队理清业务规则并发现遗漏的异常处理路径电商订单处理业务场景OOAMethodology面向对象分析(OOA)：从用例到类模型面向对象分析(OOA)从问题域中识别类、属性、操作和关系，建立系统的概念模型。OOA以用例图为起点，通过名词提取法识别候选类，再经过筛选精化、属性操作识别和关系建模，最终形成完整的分析类图，为后续设计阶段奠定基础。01候选类识别采用名词提取法：从需求描述和用例文本中提取所有名词和名词短语，作为候选类的初始清单02类筛选准则遵循五项准则：保留独立存在的实体、去除实现细节、合并同义概念、排除超出范围的概念、区分属性与类03属性与操作识别属性识别确定每个类的关键数据特征，操作识别定义类对外提供的服务和内部行为，二者共同构成类的完整定义04关系建模确定类间的关联（含多重性）、聚合/组合和泛化关系，形成完整的分析类图，反映问题域的概念结构OODFRAMEWORK面向对象设计(OOD)：四维设计框架面向对象设计(OOD)在分析模型基础上，从问题域优化、人机交互、控制驱动和数据管理四个维度完善系统设计。01·PROBLEMDOMAIN问题域设计在OOA类图基础上优化类层次、引入设计模式(观察者、策略、工厂等)，定义子系统边界和模块接口类层次·设计模式02·HUMANINTERACTION人机交互设计定义用户界面层次结构、导航逻辑与交互反馈机制，采用MVC或MVP模式分离界面与业务逻辑MVC/MVP03·CONTROLDRIVEN控制驱动设计识别主动对象和并发任务，定义任务间同步与通信机制，构建系统的并发架构并发架构04·DATAMANAGEMENT数据管理设计选择持久化方案(关系数据库、NoSQL或文件存储)，定义ORM策略和数据访问层接口ORM策略CHAPTER05敏捷开发、测试与编码实现掌握敏捷开发理念与主流框架，运用系统化测试方法保障质量，实践高质量编码规范METHODOLOGY敏捷开发：核心价值观与方法论本质敏捷开发以《敏捷宣言》为标志，本质是经验主义过程控制——通过短周期迭代与持续反馈应对需求不确定性。四大价值观强调"人"高于"流程"、"可用产品"高于"文档"、"协作"高于"合同"、"适应"高于"计划"，体现以人为本的工程哲学。以人为本12条原则进一步细化实践要求，涵盖频繁交付、面对面沟通、持续技术卓越、拥抱需求变化与简洁设计等指导方针。12条经验主义控制通过"透明—检视—适应"循环运作，每个迭代产出可演示增量产品，获取用户反馈后及时调整方向。2–4周过程纪律性敏捷并非无纪律的随意开发，而是通过严格迭代节奏、每日站会、评审与回顾会议确保过程可见性。每日站会AGILEFRAMEWORKScrum框架：角色、仪式与工件Scrum是最广泛使用的敏捷框架，通过三个角色(PO、SM、开发团队)、五个仪式(规划、站会、评审、回顾、精化)和三个工件(产品待办列表、Sprint待办列表、增量)构建轻量但纪律严明的迭代管理结构，适用于需求快速变化的产品开发场景。三大角色与核心工件三大角色：产品负责人(PO)管理产品待办列表优先级并对产品价值负责，ScrumMaster保障流程纪律并移除障碍，开发团队(5-9人)自组织完成交付三大工件：产品待办列表(ProductBacklog)按优先级排序，Sprint待办列表是当次迭代任务集合，增量是可交付产品Scrum团队使用看板进行每日站会敏捷团队进行Sprint评审会议五大仪式(会议)规划与站会：Sprint规划会(2-4小时)选取高优先级项组成Sprint目标，每日站会(15分钟)同步进展与障碍评审回顾精化：评审会演示增量获取反馈，回顾会反思改进点，精化会持续梳理细化需求项EXTREMEPROGRAMMING极限编程(XP)：工程实践的极致化极限编程(XP)由KentBeck提出，将优秀软件工程实践推向极致。XP通过结对编程、测试驱动开发、持续集成、重构和简单设计等核心实践，在高频迭代中维持代码质量的持续高水平，特别适合需求变化频繁且质量要求严格的小型团队项目。结对编程——驾驶员与领航员的实时协作01测试驱动开发(TDD)遵循"红-绿-重构"循环：先写失败测试，再写最少代码使其通过，然后重构优化代码结构。Red→Green→Refactor02结对编程(PairProgramming)两人共用一台电脑，"驾驶员"写代码、"领航员"实时审查，有效提升代码质量并促进知识共享。Driver+Navigator03持续集成(ContinuousIntegration)每天多次合并代码到主干，每次合并自动触发编译、测试和代码质量检查，尽早发现集成问题。DailyMulti-Merge04简单设计四原则通过所有测试、不包含重复代码、清晰表达意图、包含最少的类和方法，拒绝过度设计。4RulesofSimplicityFUNDAMENTALS软件测试：概念、目的与基本原则软件测试的根本目的是发现缺陷而非证明正确——好的测试用例是最可能发现未知错误的用例。测试应尽早介入、追溯到需求、基于风险选择用例，并由独立人员执行。穷举测试不可行，因此测试策略的设计本质上是一个基于风险的优先级决策过程。测试的定义：发现缺陷为了发现错误而执行程序的过程（GlenfordMyers）；测试成功意味着发现了缺陷，未发现缺陷的测试不等于"通过"。GlenfordMyers·1979尽早介入原则缺陷在需求阶段引入但在测试阶段才发现，修复成本是需求阶段修复的百倍——Boehm成本曲线揭示了延迟发现的代价。100×修复成本倍数穷举测试不可能一个包含10个分支的程序有1014条可能路径，即使每秒执行1000个测试也需要数百万年才能完成。1014条可能路径V模型阶段对应单元测试对应详细设计、集成测试对应概要设计、系统测试对应需求分析、验收测试对应用户需求。4层开发-测试对应SoftwareTestingMethodology白盒测试与黑盒测试核心技术白盒测试基于程序内部逻辑结构设计用例，黑盒测试基于功能需求和输入输出设计用例，两种方法互补，实际项目中应结合使用。白盒测试结构测试逻辑覆盖从弱到强分为：语句覆盖→判定覆盖→条件覆盖→判定/条件覆盖→组合条件覆盖→路径覆盖。语句覆盖确保每行代码至少执行一次，判定覆盖关注分支真假，条件覆盖细化到布尔条件，路径覆盖则遍历所有可能的执行路径，覆盖强度逐级递增。语句→判定→条件→路径基本路径测试通过计算圈复杂度确定最少测试用例数，是白盒测试中最实用的系统化方法。圈复杂度反映程序控制流的复杂程度，数值越高表示测试工作量越大，需要设计的独立路径越多。V(G)=P+1黑盒测试功能测试等价类划分将输入域分为有效和无效等价类，选取代表性数据作为测试用例，大幅减少测试数据量同时保证覆盖率。有效等价类验证正常功能，无效等价类检验异常处理，是黑盒测试的基础设计技术。有效类+无效类边界值&因果图边界值分析针对等价类边界设计用例，因为大量