软件工程课程笔记

第一章 软件的概念软件工程是研究如何用系统化、规范化、可度量的方法去开发、运行和维护软件的学科。本章从软件是什么这一最朴素的问题出发依次展开软件的特性、分类、软件危机的来龙去脉以及软件工程的基本方法学为后续各章奠定概念基础。1.1 软件的定义软件Software是计算机系统中与硬件相互依存的另一部分它是程序、数据以及相关文档的完整集合。这三者缺一不可程序Program按照预先设计的功能与性能要求用某种程序设计语言编写的、能够在计算机上执行的指令序列。数据Data使程序得以正常处理信息所必需的数据结构以及其中包含的具体数据。离开了数据程序便无从运行。文档Document与软件开发、维护和使用相关的文字材料例如需求规格说明、设计说明书、用户手册、测试报告等。文档是开发者、管理者与用户之间的沟通桥梁。这里必须强调一点软件不等于程序。只交付一段能跑的代码而缺少配套的数据与文档不能算作完整的软件。这一区分看似简单却是理解后面软件危机与软件工程两节的关键——许多危机恰恰源于人们把软件误当成了程序。1.2 软件的特性与硬件相比软件在形态、生产方式、质量形成等方面都有本质不同。可以从以下十个方面来理解软件的特性① 形态特性软件是一种逻辑实体而非物理实体。它无形、无重、看不见也摸不着必须依附于存储介质或运行环境才能被感知。这一特性使得软件难以像硬件那样被直接度量和检验。② 智能特性软件是人类智力活动的产物是知识、算法与解决问题思路的载体。同一台硬件之所以能完成千差万别的工作靠的正是其中运行的软件所蕴含的智能。③ 开发特性硬件是制造出来的软件却是开发设计出来的。软件不会像工业产品那样经历批量生产的物理过程每一行代码都需要人的创造性劳动。④ 质量特性软件的质量是在开发过程中逐步构建出来的而不是在成品阶段检验出来的。代码一旦写就缺陷便已埋下因此质量保障必须贯穿需求、设计、编码、测试的全过程。⑤ 生产特性软件产品的获得极其廉价——核心成本集中在前期开发一旦开发完成复制拷贝、部署的边际成本几乎为零。这与硬件每生产一件都要消耗物料形成鲜明对比。⑥ 管理特性随着规模增大软件开发早已不是单打独斗而是多人协作的工程活动。进度、成本、人员、风险都需要系统化的项目管理否则极易失控。⑦ 环境特性软件无法独立运行必须依赖特定的硬件平台、操作系统、网络与中间件环境。环境的差异直接决定软件的可用性与可移植性。⑧ 维护特性软件交付后需要持续的维护纠错、适应、完善且维护成本往往占据软件生命周期总成本的绝大部分。与硬件用久会磨损不同软件本身不会磨损却会因频繁修改而逐渐退化。⑨ 废弃特性硬件会因物理损耗而被淘汰软件却往往因运行环境变化或需求演变而过时——它不是用坏的而是不再适用的。这决定了软件具有相对较短的有效生命周期。⑩ 应用特性软件的应用领域极为广泛从航天控制到日常办公几乎没有行业能脱离软件。不同领域的软件在规模、实时性、可靠性等要求上差异巨大。1.3 软件的分类按照功能与用途软件大致可分为以下几类类别说明典型例子① 系统软件管理计算机硬件与基础资源为其他软件提供运行平台操作系统、编译程序、设备驱动程序② 支撑软件工具软件辅助软件开发、测试、维护的工具与环境集成开发环境IDE、数据库管理系统、调试器、版本控制工具③ 应用软件面向具体业务需求直接为用户解决特定问题文字处理、浏览器、企业管理ERP系统、游戏④ 可复用软件可供多个程序重复调用的标准化构件各种标准函数库如数学库、标准模板库 STL1.4 软件危机软件危机Software Crisis是指计算机软件在开发和维护过程中所遇到的一系列严重问题。它最直接的表现就是软件的发展速度远远滞后于硬件的发展速度。具体症状包括软件开发周期长远不能满足日益增长的需求开发成本高且经常严重超出预算软件质量差频繁出现错误与故障维护困难修改一处往往引发新的问题。造成软件危机的根本原因在于计算机能力的飞速提升使软件的规模与复杂度急剧膨胀而当时的开发方式仍停留在个人手艺层面缺乏系统化、工程化的方法与工具。硬件遵循摩尔定律高速迭代软件却跟不上脚步供需之间的鸿沟由此形成。软件危机的提出正是催生软件工程这一学科的直接动因。1.5 软件工程的基本方法什么是软件开发软件开发Software Development是指开发、运行、维护和修复软件的系统化方法。它强调用工程化的思路而非零散的技巧去对待软件的整个生命过程。软件工程方法实践中主要有两类方法传统方法结构化方法以功能分解和数据流为核心自顶向下、逐步求精面向对象方法OO 方法以对象、类、继承、消息通信为核心更贴近人类认知事物的方式。软件工程方法学的三要素任何一门软件工程方法学都离不开三个基本要素方法Method完成软件开发各项任务的技术路线回答怎么做工具Tool为方法提供自动化或半自动化支持的软件与环境用以提高效率与质量过程Process将方法与工具有机结合、规定任务顺序与里程碑的框架回答按什么步骤做。软件工具CASE的分类计算机辅助软件工程CASE, Computer-Aided Software Engineering工具可按所支持的活动划分为①支持软件开发过程的工具如需求分析工具、设计工具、编码与调试工具 ②支持软件维护过程的工具如版本管理、逆向工程、再工程工具 ③支持软件管理过程与支撑过程的工具如项目管理、配置管理、质量管理工具。本章小结软件是程序、数据与文档的统一体具有区别于硬件的十大特性。软件危机揭示了凭经验开发的困境而软件工程则以方法、工具、过程三要素为支柱借助 CASE 工具将软件开发引向系统化、工程化的道路。理解了这些基本概念我们才能在后续章节中从容地讨论生存期模型、需求分析、设计与测试。第二章 软件生存期模型上一章我们界定了软件是什么。这一章要解决的是软件怎么造——也就是软件从设想到退役要经历哪些阶段、以什么顺序组织。把这套阶段与顺序固定下来的框架就叫作软件生存期模型也称过程模型。2.1 软件生存期与模型的概念**软件生存期Software Life Cycle**指软件从提出开发设想开始历经需求、设计、编码、测试、运行直到最终被淘汰退役的全过程。为了驾驭这一漫长过程人们把它划分为若干相对独立的阶段每一阶段都有明确的任务、交付物与里程碑。软件生存期模型则是对这些阶段如何组织、衔接与迭代的描述。选对模型项目就成功了一半选错模型往往从一开始就埋下失控的种子。下面逐一介绍几种经典模型。2.2 瀑布模型瀑布模型是最早、也最直观的模型其核心特征是顺序性与依赖性各阶段自上而下排列如同瀑布逐级下落前一阶段完成后才能开始下一阶段适用于项目开始时需求已确定、且较少变更的场景。实际工程中常用的还有两种变体实际的瀑布模型在相邻阶段之间加入反馈环发现问题时可回退修正V 模型将测试与开发阶段对应起来如单元测试对应详细设计、系统测试对应需求强调验证贯穿始终。优点是思路清晰、文档完备缺点是过于刚性需求一旦变更代价高昂且要到后期才能看到可运行软件。2.3 快速原型模型如果说瀑布模型假设需求一开始就知道那么快速原型模型恰恰承认需求往往是模糊的。原型Prototype的本质用途就是获知用户的真正需求快速构造一个可运行的简化版本原型让用户实际操作、提出意见根据反馈反复修正需求真正摸清后再正式开发产品。它特别适合需求不明确、用户自己也说不清要什么的项目。2.4 增量模型增量模型把软件产品分解为一系列增量构件Increment逐个交付先推出核心功能让用户体验再分批加入后续构件。它的好处是早期就能拿到可用版本、用户反馈更及时、风险被分散到多个增量中。代价是要求软件架构具备良好的可扩展性否则后续增量难以拼上去。2.5 螺旋模型螺旋模型将瀑布模型与快速原型模型结合并加入了关键的风险分析。它以螺旋上的若干圈代表一轮轮迭代每一圈都包含四个活动制定计划确定目标与方案风险分析评估方案、识别并化解风险实施工程开发本轮的可交付物客户评估用户评审进入下一圈。它专为规模大、风险高的项目设计——每一圈都把风险摆在桌面上而不是等到失败才发现。2.6 喷泉模型喷泉模型是与面向对象方法相关的模型。它的特点是各阶段相互迭代、无明显边界分析、设计、编码等活动可以交错、反复进行像喷泉的水珠上下翻涌。这正契合面向对象开发中分析即设计、设计即编码的渐进特质强调开发过程的无缝与可回溯。2.7 统一过程 RUPRUPRational Unified Process统一过程是一种以用例驱动、架构为中心的迭代过程分为四个阶段阶段目标初始阶段确定项目可行性、范围和商业 case细化阶段建立稳定的架构基线化解主要风险构造阶段完成产品的开发与测试移交阶段部署上线交付用户使用RUP 定义了若干核心工作流贯穿所有阶段业务建模、需求、分析与设计、实现、测试、部署。每一阶段都是这些工作流的一次迭代。2.8 敏捷过程进入 21 世纪**敏捷Agile**方法因能应对快速变化的需求而兴起。其价值观集中体现为《敏捷宣言》的四条对比个体和交互胜过 过程和工具可工作软件胜过 宽泛的文档客户合作胜过 合同谈判响应变更胜过 遵循计划。敏捷并非不要过程而是把人、可用软件、客户、变化放在更高优先级。2.9 极限编程 XP**极限编程Extreme Programming, XP**是敏捷方法中实践最具体、约束最鲜明的一种。它将一系列优秀实践做到极致典型包括测试驱动开发TDD先写测试再写代码结对编程两人一机实时互审持续集成频繁合并、随时可运行小规模发布与短迭代快速交付、快速反馈重构持续改善代码结构而不改行为简单设计、代码集体所有、现场客户等。本章小结从刚性的瀑布到弹性的原型、增量、螺旋、喷泉再到工程化的 RUP 与以人为本的敏捷/XP生存期模型的演进本质是一条主线如何让软件开发更好地应对需求不确定与风险不可控。理解了这些模型的取舍我们才能在第三章起深入每个阶段内部究竟做什么。第三章 软件需求分析无论采用哪种生存期模型需求都是第一个真正落地的关口。需求做错后面全错——这正是需求分析被称为最关键阶段的原因。3.1 需求分析的阶段需求分析本身也是一组有序活动通常分为四个子阶段需求获取通过与用户交流、观察、调研收集原始需求需求分析梳理、提炼分清哪些是实现约束、哪些是真正的功能需求需求定义将分析结果用规范语言写清楚需求验证与用户确认确保理解无误、无遗漏。3.2 主要工作产品该阶段最重要的产出是两个文档软件需求规格说明书SRS对软件功能、性能、约束的正式描述是后续设计、测试与验收的基准用户手册初稿从用户视角描述系统将如何使用帮助尽早暴露理解偏差。3.3 结构化分析的核心数据字典在结构化分析中**数据字典Data Dictionary**是贯穿全局的词汇表它是对系统中各类数据元素的精确定义。具体来说它描述数据流数据在系统中流动的路径与内容加工对数据施加的变换数据文件数据存储数据元素不可再分的最小数据单位数据源点 / 数据汇点数据的外部来源与去向。配合数据流图DFD使用数据字典让每个出现在图上的名字都有据可查。3.4 数据结构描述除了字典式的条目定义还可用图形化方式描述复杂数据结构定义式用一套符号如表示定义为、表示与、[]表示或、{}表示重复书写数据的组成Warnier 图以树形层次表达数据的包含与重复关系适合描述有嵌套结构的数据。3.5 三种建模视角结构化分析从三个侧面刻画系统建模类型回答的问题常用工具功能建模系统做什么数据流图 DFD数据建模数据是什么、如何关联E-R 图行为建模系统如何随事件响应状态转换图三者结合才能完整描述一个系统。3.6 决策树与决策表当某个加工的逻辑依赖于多个条件的组合时自然语言容易遗漏分支。此时可用决策树用树形结构展示条件 → 动作直观易读决策表用表格罗列所有条件组合及其对应动作确保不重不漏。本章小结需求分析的目标是把模糊的用户愿望转化为无歧义的规格说明。数据字典是结构化分析的中枢三种建模功能 / 数据 / 行为提供完整视图而决策树与决策表则驯服了复杂的条件逻辑。下一篇我们进入如何把需求设计成可实现的方案。第四章 结构化设计方法需求告诉我们要造什么设计回答怎么造。结构化设计SD把需求模型转化为由模块组成的软件结构是连接分析与编码的桥梁。4.1 软件设计的五项原则良好的设计不是凭感觉而是遵循一组原则①分而治之把大问题拆成小模块逐个击破 ②模块独立性追求低耦合、高内聚——模块之间联系尽量弱耦合低模块内部联系尽量紧内聚高 ③提高抽象层次用概念而非细节思考问题降低复杂度 ④复用性设计把通用部分抽出来便于多处复用 ⑤灵活性设计预留应变空间使需求变更时改动最小。其中低耦合、高内聚是评判模块质量的黄金标准。4.2 模块结构软件被组织为模块的层次结构上层模块调用下层模块并通过接口传递数据。结构化设计的目标就是从需求阶段的数据流图DFD导出这样一张模块结构图。4.3 基于数据流方法的设计过程从 DFD 导出模块结构有一套固定步骤复查并精化数据流图确定数据流图中数据流的类型变换型 or 事务型导出初始的软件结构图逐级分解细化各层模块精化软件结构导出接口描述和全局数据结构。4.4 变换型数据流最常见的是变换型数据流其工作过程可概括为三步取得数据从外部获取输入变换数据在变换中心进行核心加工给出数据将结果输出。对应地模块结构也分为输入枝、变换中心、输出枝三部分变换分析就是据此映射出初始结构。4.5 软件模块结构的改进方法初版结构往往粗糙需要反复优化模块功能完善化每个模块应有完整的入口 / 出口、错误处理消除重复功能抽取公共部分改善结构作用范围应在控制范围以内模块能影响的范围不应超出它能直接调用的范围减少高扇出、增大扇入避免一个模块管太多下属扇出过高鼓励被多处复用扇入增大避免病态连接如模块间出现内容耦合等非法依赖模块大小适中过大难懂、过小琐碎需平衡。4.6 接口设计的三方面接口设计关注模块如何与外界对话主要包括模块或软件构件之间的接口软件与其他软硬件系统之间的接口软件与人之间的接口即用户界面。4.7 用户界面的特性好的界面应具备可使用性易学、易用、高效灵活性能适应不同水平用户的习惯可靠性操作可恢复、不致数据丢失。4.8 程序流程图与基本控制结构详细设计常用程序流程图描述处理逻辑它建立在五种基本控制结构之上顺序型依次执行选择型二选一注意标准基本结构中不应出现两个以上的平行分支复杂选择应分解先判定型循环do-while先判断可能一次也不执行后判定型循环do-until先执行至少一次多情况选择型根据值分派到多个分支。这五种结构保证程序清晰、可读、可验证。4.9 设计阶段的交付文档结构化设计最终产出三份关键说明书概要设计说明书总体结构、模块划分详细设计说明书每个模块的实现算法数据库设计说明书数据结构与存储方案。本章小结结构化设计把需求翻译成模块结构。低耦合高内聚是灵魂数据流方法是主路变换分析是核心技巧而接口与界面设计决定了软件好不好用。下一章我们换一套截然不同的思路——面向对象。第五章 面向对象方法学概述前面几章是结构化的世界观把系统拆成功能与数据流。面向对象OO换了一套更贴近人类认知的视角——用对象而非功能来建模世界。本章先建立 OO 的基本概念并引出统一的建模语言 UML。5.1 什么是面向对象面向对象的本质可以用一个等式概括面向对象 对象 类 继承 消息通信对象Object客观事物的抽象既有数据属性也有行为操作类Class具有相同属性和操作的对象的模板继承Inheritance子类复用父类的特征并可加以扩展消息通信Message对象之间通过发送消息协作而非直接操纵彼此内部。封装封装是 OO 的基石它包含三层含义清楚的边界对象对外只暴露必要部分接口外界通过定义好的接口使用对象受保护的内部实现内部细节对外部隐藏可自由修改而不影响使用者。消息通信对象之间不互相翻看内部而是通过消息请求服务。这种松耦合让系统更易于修改与复用。5.2 主要的面向对象开发方法OO 思想提出后出现过多种方法各有侧重Booch 方法提出微开发与宏开发两层次强调图形化建模Rumbaugh 方法OMT以对象模型、动态模型、功能模型三类模型著称Coad 与 Yourdon 方法以 OOA / OOD 的五层结构清晰易学见长Jacobson 方法OOSE以用例Use Case驱动强调从用户视角捕获需求。后来这些方法被统一吸收进UML与RUP。5.3 统一建模语言 UML**UMLUnified Modeling Language**是 OO 建模的工业标准其特点包括统一标准集各家之大成面向对象天然契合 OO 世界观独立于过程不绑定特定开发方法可视化用图形表达模型与编程语言的关系UML 是建模语言可映射到多种编程语言。UML 的基本事物UML 的构造块分为四类事物结构事物类、接口、构件等、行为事物交互、状态机、分组事物包、注释事物注解。UML 的图UML 提供多种图常用有用例图主要元素是用例和执行者Actor用例之间的关系有泛化、扩展、包含使用类图描述类及类之间的关系包括关联、聚合、组合、泛化交互图含顺序图与协作图描述对象间的动态协作状态图描述对象生命周期包含初态、终态、中间状态与复合状态此外还有活动图、对象图、构件图、部署图等。UML 的关系类与类之间常见关系关联、依赖、泛化继承、实现。UML 的三种消息在交互图中对象间传递的消息分三类简单消息仅表示控制流不区分同步 / 异步同步消息发送方等待接收方处理完再继续异步消息发送方发出后不等待继续执行。本章小结面向对象用对象 类 继承 消息重新组织了软件的世界封装保证了模块边界UML 则提供了一套统一的可视化语言。下一章我们进入面向对象分析OOA学习如何用这套语言把需求落成模型。第六章 面向对象分析面向对象分析OOA的任务是从问题域中抽象出对象与类并建立起能反映用户需求的模型。它上承需求下启设计。6.1 确定系统边界分析的第一步是划清系统做什么、不做什么——即确定系统边界哪些功能属于系统内部哪些由外部环境人、其他系统承担。边界清晰模型才不会无限膨胀。6.2 面向对象分析的三种模型OOA 通常建立三类相互关联的模型用例模型从用户视角描述系统功能对应功能需求对象模型描述问题域中的对象、类及其静态关系最核心交互模型动态模型描述对象之间如何随时间协作完成用例。三者中对象模型是骨架用例与交互围绕它展开。6.3 建立用例模型的过程建立用例模型可分三步确定业务参与者Actor谁会使用系统或与系统交互确定业务需求用例Use Case参与者期望系统提供什么价值创建用例图用图形把参与者、用例及其关系画出来。6.4 用例的规格说明一个用例不能只画个圈还需用文字完整描述。一份规范的用例规格说明通常包括用例名称执行者前置条件执行前系统须满足的状态后置条件执行后系统达到的状态一个主事件流零到多个备选事件流异常或分支情形。6.5 对象模型的五个层次Coad 与 Yourdon 提出对象模型按抽象程度分为五个层次自顶向下为主题层对模型的分区便于把握大局类 - 对象层识别出系统中的类与对象结构层类之间的泛化 / 组合等结构关系属性层为每个类定义属性服务层为每个类定义操作方法。6.6 建立对象模型的步骤按上述五层自顶向下逐步建立对象模型划分主题先对问题域分块确定类与对象从需求中挑出候选类剔除冗余确定结构建立类间的泛化、关联、聚合关系确定属性为每个类填上属性确定服务为每个类定义应有的操作。本章小结OOA 的核心是用例模型刻画功能、对象模型刻画静态结构、交互模型刻画动态协作。从确定边界到建立用例再到五层对象模型OOA 把用户语言翻译成了开发者可设计的蓝图。下一章第七章补全我们补上从分析到设计之间关键的设计基础与体系结构。第七章 软件设计基础与体系结构【补全章节】说明原笔记在第六章 面向对象分析与第八章 面向对象设计之间缺了一章。本章按软件工程标准体系补写作为从分析模型迈向设计模型的过渡。如与你的原课件主题不符可随时替换为讲义中的对应章节。7.1 从分析模型到设计模型需求分析产出的是问题域模型做什么而设计要产出解域模型怎么做。两者之间有道鸿沟分析关心用户的世界设计关心计算机的世界。本章补上的正是跨越这道鸿沟所需的设计思维基础。7.2 模块化与抽象再认识第四章已提出分而治之与提高抽象层次。这里再强调一点好的抽象让我们在高层忽略细节、在底层专注细节。抽象与逐步求精是贯穿所有设计方法结构化与面向对象 alike的统一法则。7.3 耦合与内聚深化第四章给出了低耦合、高内聚的目标。进一步看内聚从低到高大致为偶然内聚 逻辑内聚 时间内聚 过程内聚 通信内聚 顺序内聚 功能内聚功能内聚最佳耦合从低到高大致为非直接耦合 数据耦合 特征耦合 控制耦合 外部耦合 公共耦合 内容耦合数据耦合最理想内容耦合最坏。设计时应追求高内聚、低耦合避免控制耦合与公共耦合这类牵一发而动全身的依赖。7.4 软件体系结构风格当模块越聚越多就需要**体系结构Architecture**来规定它们的宏观组织方式。常见风格有分层风格自上而下分层上层调用下层如表现层 / 业务层 / 数据层客户端 - 服务器C/S客户请求、服务器响应管道 - 过滤器数据在阶段间流式传递如编译器、Unix 管线事件驱动组件通过广播 / 订阅事件通信仓库数据共享各模块围绕一个公共数据存储协作微服务现代演化将系统拆为独立部署的小服务。7.5 设计的质量属性架构选择要在多个质量属性间权衡性能、可维护性、可扩展性、可靠性、安全性、可移植性等。没有最好的架构只有最适合当前诉求的架构——这正是设计之为艺术也之为工程的地方。本章小结补全从分析到设计需要模块化、抽象、耦合 / 内聚这些通用准则更需要体系结构来组织全局。理解了分层、C/S、管道 - 过滤器等风格以及质量属性的权衡我们才具备进入第八章面向对象设计的视野。第八章 面向对象设计构件第八章 面向对象设计分析回答做什么设计回答怎么做。面向对象设计OOD把 OOA 的对象模型精化为可实现的方案。本章聚焦设计中的关键概念以及经典的 Coad 与 Yourdon 设计模型。8.1 构件与类的区别初学者常混淆类与构件二者的核心差别在于抽象层次不同类是逻辑事务描述对象的模板存在于设计与代码中构件Component是计算机结点上的物理抽象是可独立部署、替换的物理单元。为了起到物理抽象作用类被实现为构件。构件只向外界暴露它所包含类的某些接口其余大量接口被封装在构件内部仅被协作的类使用对其他构件不可见。这种信息隐藏正是构件可独立演化的前提。8.2 服务与子系统接口服务Service一组有公共目的的相关操作子系统接口包括操作名、操作参数类型及返回值。设计子系统时只需对外公布稳定的接口内部实现可自由变化。8.3 封闭 / 开放体系结构封闭体系结构修改某一层只影响相邻层变化被封闭在局部开放体系结构一层的变化可能向上、向下传播。好的设计倾向于封闭性以控制变更的传播范围这与第四章低耦合一脉相承。8.4 Coad 与 Yourdon 的面向对象设计模型Coad 与 Yourdon 把 OOD 在逻辑上划分为四个部分每个部分由主题、类 - 对象、结构、属性、服务五个层次组成问题域部分直接映射到 OOA 的对象模型人机交互部分用户界面任务管理部分并发与中断处理数据管理部分对象的持久化存储。下面逐一展开。8.5 问题域部分的设计在 OOA 模型基础上对问题域部分做七步调整调整需求根据设计阶段新认识修正模型复用已有的类引入可复用的类或构件把问题域类组合在一起按主题聚合增添泛化类以建立类间的协议用抽象父类统一接口调整继承的支持级别视语言能力决定是否用多继承改进性能针对瓶颈优化存储对象决定哪些对象需要持久化。8.6 任务管理部分的设计为处理并发需识别并定义各类任务进程 / 线程。常见任务类型与识别步骤事件驱动型任务等待外部事件触发时钟驱动型任务按固定周期执行优先任务高优先级实时处理关键任务关系系统安全的紧要操作协调任务协调多个任务间的通信。设计步骤① 识别事件驱动任务② 识别时钟驱动任务③ 识别优先任务④ 识别关键任务⑤ 识别协调任务⑥ 审查每个任务⑦ 定义每个任务含优先级、周期、接口。8.7 数据管理部分的设计对象需要保存到数据库或文件中关键是把对象关系映射为存储结构一对一关联的映射两表各加对方主键或合并为一表一对多关联的映射在多方表中加一方主键作为外键继承关系的映射常用方式有每类一表父表 子表或单表继承此外还有依赖关系的处理与对象设计为类补充实现细节。本章小结OOD 的关键在于用构件封装类、用接口隔离变化并沿问题域 / 人机交互 / 任务管理 / 数据管理四个维度组织设计。任务管理驯服并发数据管理打通持久化——到这一章软件已从蓝图变成了可建造的方案。下一章第九章补全将进入编码实现。第九章 软件实现编码【补全章节】说明原笔记在第八章 面向对象设计与第十章 软件测试之间缺了一章。按软件工程体系设计之后、测试之前必然是编码实现本文据此补写作为补全章节。9.1 编码的任务设计解决了方案编码解决落地把设计文档翻译成某门程序设计语言的可执行代码。编码不是机械转录而是对设计的再推敲——许多设计缺陷正是在写代码时才暴露。9.2 程序设计语言的选择语言直接影响可维护性、性能与开发效率。选择时考虑问题域适配数值计算、业务逻辑、系统编程各有擅长语言可维护性与可读性优先选表达力强、类型安全的语言团队与生态库、框架、人才是否可得。9.3 编码风格与规范好的代码写给下一个人读。要点清晰命名、合理缩进、适度注释函数短小、单一职责遵循团队统一的编码规范如命名约定、文件组织。9.4 代码评审在运行测试之前先用人来发现缺陷代码走查Walkthrough作者讲解同行提意见正式审查Inspection按清单系统化检查效果显著。评审能发现大量逻辑与规范问题成本远低于后期返工。9.5 调试调试是定位并修复已暴露缺陷的过程。核心思路复现 → 定位二分、日志、断点→ 假设 → 验证修复 → 回归。切忌盲目改代码碰运气。本章小结补全编码把设计变成现实但能跑不等于好。选对语言、守住规范、重视评审与调试才能产出可维护的代码为第十章的测试打下基础。第十章 软件测试写出代码只是开始证明代码做对了才是测试的职责。测试不是挑刺而是用可控的投入把缺陷尽可能挡在交付之前。10.1 测试的基本概念测试的目标是以最少资源发现最多错误。一个基本原则是测试只能证明缺陷存在不能证明缺陷不存在。因此测试讲究策略与覆盖而非盲目点击。10.2 白盒测试白盒测试White-box关注程序内部的逻辑结构在已知代码的前提下设计用例追求对代码的覆盖。常见覆盖准则由弱到强语句覆盖 → 判定覆盖 → 条件覆盖 → 判定 / 条件覆盖 → 条件组合覆盖 → 路径覆盖。覆盖越强发现隐藏缺陷的概率越高但用例数也越多。10.3 黑盒测试**黑盒测试Black-box**把程序当黑箱只依据规格说明、不关心内部实现。常用技术等价类划分把输入域分为若干等价类每类取一代表值减少冗余用例边界值分析重点测试等价类的边界如 0、最大值、上溢点因为缺陷最爱藏在边界。10.4 集成测试组装测试单元测试通过后需把模块组装起来测接口与协作。组装方式有两种一次性组装整体拼装所有模块一次拼好再测。简单但定位错误难增殖式组装边拼边测包括自顶向下先顶层、再逐层向下自底向上先底层、再向上混合增殖式二者结合兼顾效率与可控。10.5 测试策略与步骤完整的测试自底向上、由小到大分四步单元测试针对单个模块函数 / 类集成测试验证模块组装后的接口与协作确认测试验证软件是否满足需求有效性系统测试把通过确认测试的软件放进真实运行环境测性能、安全、兼容等。本章小结测试用白盒看内部、黑盒看规格用增殖式组装化解集成风险并按单元 → 集成 → 确认 → 系统四级层层把关。即便如此仍会有缺陷流入运行——这就需要第十一章的软件维护。第十一章 软件维护软件交付不是终点。据统计维护成本往往占软件生命周期总成本的绝大部分。理解维护才能理解软件为什么这么贵。11.1 软件维护的定义软件维护是指在软件交付后为保证软件在一个相当长的时期内正常运行而进行的修改活动。它贯穿运行阶段是软件生命周期中持续时间最长的部分。11.2 维护的分类按修改目的维护可分为四类类型目的占比改正性维护修复运行中暴露的缺陷bug较小适应性维护使软件适应变化的环境新 OS、新硬件中等完善性维护扩充功能、提升性能满足新需求最大预防性维护主动修改以提高未来可维护性较小其中完善性维护占比最大——用户用着用着总会想要再加点东西。这也解释了为何软件总量只增不减、越来越难改。11.3 维护的代价与启示维护之所以昂贵源于维护性恶化每次匆忙修改都可能引入新缺陷、堆高复杂度。为降低代价应在设计与编码阶段就注重可读性、低耦合与文档完整——可维护性是设计出来的不是维护出来的。本章小结软件维护是为保证长期正常运行而做的持续修改改正性、适应性、完善性占比最大、预防性四类各有侧重。它提醒我们软件的真正成本不在开发而在它漫长的后半生。到这一章我们走完了从概念到退役的完整软件工程主线。