哈工大《软件工程专业导论》复习指南

哈工大软件工程专业导论复习指南

前言

选修课同学复习仅需掌握前5章和导论部分即可，软工专业同学需要掌握全部内容，不过平时分给的很多，稍微复习一下就可以应付考试。作者根据个人理解认为需要重点记忆的部分黑体标注，未标注的部分仅供了解，但最好能理解。

本文内容基于作者个人理解，如有不到位指出请指出，我将会不断丰富文章内容，使其成为一个很好的复习指南。

除了应付考试以外，作者更希望软工专业的同学对软件工程有大体的认识，学习并不仅仅是为了考试。实际上软件对于当前生活来说更加重要，各行各业都需要软件，一个完全不懂计算机的人也能够通过软件的使用达到所需要的目的。

引言——软件工程专业导论课程引言

软件工程（Software Engineering）：研究或运用工程化方法来设计、创造、构建和维护有效、实用和高质量软件的 一门学科。

中国软件工程专业的发展：20世纪80年代初，我国开始探索软件工程教育，有高校开设了软件工程研究生课程。1984年，举办了软件工程研究生班。1998年，教育部批准软件工程专业进入本科专业目录。2001年，教育部批准成立示范性软件学院，开发了本科生和研究生软件工程教育计划。2006年，教育部成立了高校软件工程专业教学指导分委员会。2011年，建设软件工程一级学科博士点。2020年，建设特色化示范性软件学院。这些标志着我国软件工程教育逐步走向成熟。

第一章 软件工程专业初步认知

软件工程主要研究内容：软件开发过程、软件开发方法、软件工程管理与支持、软件质量保障、软件工程度量、计算机辅助软件工程环境及工具等

软件工程的框架： 目标、 过程和原则

软件工程的要素： 方法、 工具和过程

软件危机：1960年代后期，随着软件规模及开发难度的增加，软件开发周期长、成本高、 质量差、维护难，导致软件危机爆发。问题：对软件开发工作量和成本估计不准；软件开发进度难以控制；软件产品质量与可靠性差强人意。

软件工程的产生：1968年10月，北大西洋公约组织NATO召开计算机科学会议，Fritz Bauer首次 提出“软件工程”概念及克服“软件危机”的策略，强调按照工程化原则和方法组织软件开发工作。软件工程技术领域由此应运而生。

软件工程方法发展历程：1960’s-1970’s：结构化方法 1980’s：面向对象的方法 1990’s：构件化方法和Web Services 2000’s：面向服务的SOA方法与敏捷软件开发方法 2010’s：基于互联网与云原生的软件开发方法 2020’s：面向元宇宙的智能化软件开发方法

软件工程的几个阶段：需求工程、软件设计、软件开发、软件测试与交付

1960s-1970s年代: 结构化方法

方法：结构化程序设计方法、瀑布模型、螺旋模型等

编程语言：Fortran语言、Pascal语言、C语言 结构化方法好比建平房或用建平房的技术建造复杂建筑

1980s年代: 面向对象的方法

方法：面向对象方法、面向对象模型及建模工具等

编程语言：C++(83)、 Java(95)、Visual 系列语言(90)等

面向对象方法好比建高楼，可以更方便地构建复杂建筑

1990s年代: 构件化方法

方法：软构件方法、Web Services、软件复用方法等

编程语言：Visual系列语言、Windows操作系统等

构件化方法好比堆积木、造预制件等，可以批量地、快速地构建更为复杂的建筑。

2000s年代: 面向服务的体系结构SOA方法

基于Internet与云计算的软件开发方法

软件工程技术主要发展趋势：

新型软件体系结构及开发方法 —— 基于云计算平台的软件体系结构、模型驱动的开发方法MDA、敏捷软件开发方法、软件集成开发环境及工具

软件构件化 —— 软构件（Software Component）技术、基于构件的软件复用（Software Reuse）

软件服务化 —— 面向服务的体系结构SOA、Web Services、软件即服务 SaaS、软件服务工程

软件需求工程 （Requirement Engineering）—— 基于知识的软件需求分析、需求分析自动化

中间件（Middleware）—— 中间件平台、企业服务总线ESB、网络构件 、基于中间件的软件集成技术

软件质量保障 —— 软件质量评测与度量、软件可靠性技术、软件过程 改进模型

软件领域化 —— 领域软件工程（ Domain Engineering）、行业应用软 件、企业应用软件

软件工程的发展历程：

阶段1：独立的程序(Independent Programming Service)

1950s-1960s: 机器为中心，专业服务公司，如IBM

阶段2：软件产品(Software Product)

1960s-1970s: 软件业独立发展，软件产品公司，如ADR

阶段3：企业解决方案(Enterprise Solution)

1970s-1980s: 应用为中心，企业解决方案公司,SAP, Oracle

阶段4：支持大众应用的软件包(Packaged Software for Mass)

1980s-1994: 个人为中心，大众软件公司，Microsoft, Apple

阶段5：网络软件与服务(Internet‐Based Software and Service)

1990s,网络为中心，互联网公司，Netscape, Yahoo, Google

2000s,社会为中心，服务公司，Facebook, Twitter, YouTube

软件工程学科的产生：

2004年8月，全世界500多位来自大学、科研机构和企业界的 专家、教授经过多年的努力，推出了软件工程知识体系、软件工程教育知识体系（ SEEK）两个文件的最终版本，标志着软件工程学科在世界范围正式确立，并成为 计算学科领域的独立学科，还在本科教育层次上迅速发展。

中国软件工程专业学科的发展：

20世纪80年代初，我国开始探索软件工程教育，部 分高校先行开设了软件工程课程。1984年和1985年，北京大学和复旦大学举办了软 件工程研究生班。1998年，教育部批准软件工程专业进入本科专业目录。2001年， 教育部批准成立示范性软件学院，开发了本科生和研究生软件工程教育计划。2006 年，教育部成立了高校软件工程专业教学指导分委员会。这些举措有效地促进了我 国软件工程学科的发展，标志着我国软件工程教育开始走向成熟。

1998年，教育部颁布了《普通高等学校本科专业目录（1998年颁布）》，软件工程专业 正式出现在该目录中，专业代码为080611W。

2001年，教育部和国家计委批准成立了35所“示范性软件学院”（后增加2所），培养高 层次、实用型、复合型、具有国际竞争力的软件工程人才，并开发了本科生和研究生软 件工程教育计划。全国现已有400多高校设有软件工程专业。

2006年，教育部成立了高等学校软件工程专业教学指导分委员会。2013年, 又批准成立 了独立的“教育部高等学校软件工程专业教学指导委员会” 。

2011年, 国务院学位委员会批准新增“软件工程”一级学科博士点与硕士点。现已有100多 高校设有软件工程博士/硕士点。

2020年，教育部批准成立33所“特色化示范性软件学院”，探索具有中国特色的软件人才 产教融合培养路径，培养满足产业发展需求的特色化软件人才。

软件工程知识体系（SWEBOK V3.0） 软件需求 软件设计 软件构造 软件测试 软件维护 软件配置管理 软件工程管理 软件工程模型与方法 软件工程过程 软件质量 软件工程经济学 软件工程职业实践 计算基础 工程基础 数学基础

软件工程科学技术范畴：软件过程（Software Process）软件开发方法（Software Development Method）软件需求工程（Software Requirement Engineering）软件体系结构（Software Architecture）软件开发工具与环境（Software Development Environment）软件复用与软构件（Software Reuse & Component）软件中间件（Software Middleware）软件测试（Software Testing）软件维护（Software Maintenance）

软件工程学科的基本思维模式

计算思维——符号化、计算化与自动化软件的研究目的是解决社会/自然问题。将社会/自然问题用符号表达，基于符号进行计算，将计算用软件来实现，是解决社会/自然问题的基本思维模式

软件与程序思想: 组合-抽象-构造-递归

“程序”是由基本动作指令构造的，若干指令的 一个组合或一个执行序列，用以实现复杂动作。程序的本质是组合、抽象与构造。构造的基本手段是迭代和递归。递归是一种表达相似性对象及动作的重复性无限性构造的方法。

第二章 软件体系结构与生命周期

软件体系结构（Software Architecture）：一个系统的基础组织，包含各个构件、构件互相之间与环境的关系，还有指导其设计和演化的原则。

软件体系结构 = 构件 + 连接件 + 约束

构件（Component）：具有某种功能的可复用的软件结构单元，表示系统中主要的计算元素 和 数据存储。构件是一个抽象的概念，在程序中可以指程序函数、模块、对象、类等。

连接件(Connector)：表示构件之间的交互并实现构件之间的连接。

约束(Constraint)：是指软件体系结构中的构件按照什么标准或要求连接起来，涉及系统的性能约束或功能约束。

软件体系结构风格是描述特定系统组织方式的惯用范例，强调了软件系统中通用的组织结构。 软件体系结构风格定义 了构件与连接件类型的 符号集及其组合的约束 集。

典型的软件体系结构风格：

调用/返回(Call/Return)体系结构风格

主程序/子程序体系结构：将功能划分为控制层次结构。

远程过程调用体系结构：其中的构件分布在网络的不同节点。

面向对象 (Object-Oriented)的体系结构风格

系统被看作是对象的集合；系统构件是各个对象，每个对象都有自己的功能集合，封 装了数据和用于该数据的操作。数据及其操作被封装成抽象数据类型；构件只通过接 口与外界交互，构件之间的通信与合作通过信息传递来实现。

以数据为中心（Data-Centric）的体系结构风格

将数据存储构件作为核心，与其他构件紧密结合，其他软构件访问该数据存储构件，形成类似于星型结构的拓扑关系。各客户端软件独立运行。

数据流(Data Flow)体系结构风格（又称管道-过滤器风格）

系统任务被分成若干连续的处理步骤，这些步骤由通过系统的数据流连接，输入数据 经过一系列计算或操作构件转换为输出数据。例如，管道-过滤器模式拥有一组由管道连接的过滤器构件，每个过滤器构件独立运行。

层次(Hierarchical)体系结构风格

软件系统由多个不同层次构件构成。在内层，构件完成建立操作系统接口的操作； 在中间层是实用工具服务和应用软件功能；在外层，构件实现用户界面的操作。

事件驱动体系结构风格

事件驱动就是在当前系统的基础上，根据事件声明和发展状况来驱动整个系统的运行。其基本思想是系统对外部的行为表现，可以通过它对事件的处理来实现。 构建不在直接调用过程，而是声明事件。触发一个事件时，系统会通过该事件注 册的构件表，自动调用其他构件的过程。

解释器体系结构风格（虚拟机风格）

解释器作为一种体系结构，主要用于构建虚拟机，用于拟合程序语义和计算机 硬件之间的间隙。实际上，解释器就 是利用软件来创建 的一种虚拟机。解释器风格又称为 虚拟机风格。

反馈控制环体系结构风格

反馈控制环是一种特定的数据流结构。传统数据流结构是线性的，而控制连续循 环过程的体系结构则是环形的。

MVC体系结构架构

模型-视图-控制器MVC(Model-View-Controller)架构

模型-视图-控制器MVC体系结构将软件系统划分为三类主要的构件：模型(Model)、视 图(View) 和控制器(Controller)，分别对应于业务逻辑处理功能、接口表示功能和对模型和视图的访问与协调功能。

软件体系结构设计的目标：满足软件需求。软件需求 是体系结构设计的基础和 驱动因素，对软件体系结 构具有关键性的塑形作用。追求高质量、可扩展、可 伸缩、易维护……。体系结构设计为详细设计 提供可操作指导。

软件生命周期：是指从软件的产生直到废弃的全部过程，就像产品生命周期。 一般而言，软件工程的基本过程是围绕着软件生命周期来进行的。

几种常见的软件生命周期模型：瀑布模型（Waterfall Model）演化模型（Evolutionary Model）螺旋模型(Spiral Model)

基本的软件过程：

需求工程指运用已证实有效的技术、方法进行需求分析、确定客户需求、帮助分析人员理解问题并定义目标系统的所有外部特征的工程方法和技术。

需求分析是指对解决现实世界某个问题的软件产品以及对软件产品约束的描述。

软件设计是指从软件需求规格说明书出发，根据需求分析阶段确定的功能，设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法、以及编写具体的代码，形成软件的具体设计方案。

软件编码是将软件详细设计处 理过程的描述转换为基于某种 计算机语言的程序，即源程序代码。

软件测试是通过运行程序代码来测试软件是否满足规定的功能和性能，是否存在缺 陷和问题，并产生软件评测报告。测试的目的是及早发现软件所存在的问题，避免出现缺陷导致事故！

软件运行与维护：在软件交付给用户后的运行期间根据需求变化或硬件环境变化 对软件产品进行部分或全部修改的过程。

软件工程生态环境：软件工程环境和软件环境

软件系统的分解：在设计复杂软件系统时，为降低系统复杂性，通常要将软件系统按照功能分解为多个部分或子系统；再将子系统分解为若干个子系统或类；依此类推。各子系统相对独立，相互之间具有简明的接口。

在软件系统中，对象（object）既表示客观世界问题空间中的某个具体的事物，又 表示软件系统解空间中的基本元素，是相互可区分的一个个“个体”。

类(Class)是对对象的抽象。有些对象具有相似的 特性描述，组成一个“类” 。

框架指的是一个可复用的设计构件， 是一组抽象构件与 构件之间交互的方 法；给项目开发带 来了方便。 对象框架将同类别对象的共性内容做成一个对象框架。

组件/构件(Component)：可独 立发布的机器级程序文件；将若干对象及其内部关系进行封装所 形成的一个可执行程序文件。 接口与实现分离：接口是对象或者组件的通信协议；实现是对象或者组件的内部构造细节。

J2EE框架: Java 2 Platform Enterprise Edition Framework

J2EE架构是一种使用 Java技术开发企业级分布式应用的计算环境； 是SUN牵头推出的事实上的工业标准。 J2EE的核心体系架构就是在MVC框架基础上扩展而来的。

Web服务体系架构(Web Service Architecture)

Web服务是一种面向服务的架构技术。通过标准的Web协议来实现分布式应用程序的创建和提供服务，目的是保证不同平台的应用服务可以互操作。

面向服务的体系结构SOA（Service Oriented Architecture）：是一个组件模型，它将应用程序的不同功能单元（称为服务）通过服务之间定义良好的接口和契约联系起来。

模型驱动的软件开发方法（MDD: Model Driven Development）：是以模型作为主要工具进行高级别抽象的软件开发方法。其基本思想是让开发者 从编程转移到高级别抽象中去，通过模型转成代 码或构件来驱动部分或全部的自动化开发。

第三章 软件需求工程

软件需求（Software Requirement）：以一种清晰、简洁、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、周期、成本、设计约束等方面的期望，是在开发过程中对软件系统的约束。

软件功能性需求（Functional Requirement）：指软件能够完成的功能及在某 些场景下可展现的外部可见行为或效果。

软件非功能性及质量需求：从各个角度对系统的约束和限制，反映了客户对软 件系统质量和性能的额外要求，如响应时间、数据精度、可靠性等。

软件开发约束性需求：对软件的开发成本、交付进度、技术选型、遵循标准等 方面提出的要求

软件需求工程（Requirement Engineering）是用工程的理念和方法来指导软件需求 实践；它提供了一系列的过程、策略、方法学和工具，帮助需求工程师加强对业务 或领域问题及其环境的理解，获取和分析软件需求，指导软件需求的文档化和评审 ，以尽可能获得准确、一致和完整的软件需求，产生软件需求的相关软件制品。

需求工程的几个阶段：

需求获取：通过与用户的交 流，对现有系统的观察及对任 务进行分析，从而开发、捕获 和修订用户的需求

需求分析：对收集到的需求 进行提炼、分析和审查，为最 终用户所看到的系统建立概念 化的分析模型

需求规格描述：需求规格说明书是需求开发的 结果

需求确认： 以需求规格说明为输 入，通过评审、模拟或快 速原型等途径，分析需求 规格的正确性和可行性， 发现存在的错误或缺陷并 及时更改和补充。

需求管理

敏捷开发的需求工程（Agile Requirements Engineering）

因为敏捷软件开发方法强调适应高频的需求变化，倡导需求描述要简捷高效。

敏捷开发方法不要求使用正式的需求文档，而是不断收集用户需求，将它们作为“用户 故事(User Story)”或“需求用例”写在卡片或白板上，并按照价值性和紧迫性进行优 先级排序，用于下一次迭代式开发；强调基于用户故事的软件交付。

用户故事的典型描述格式：作为一个<角色>，我想要<活动>，以便于实现<商业价值>

用户故事应满足INVEST原则：独立性（Independent）、可协商（Negotiable）、价值 性(Valuable)、可估量(Estimable)、小规模（Small）、可测试性（Testable）。

用户需求可以采用用户故事方式灵活变更，以适应需求不确定性强、产品快速变化和竞 争压力大的软件系统或产品的开发。

软件需求获取：开发者、用户之间为了定义新系统而进行的交流，以得到或产生 软件需求。需求获取是需求分析的前提，要收集拟开发新系统和正在使用的系统 的信息，并从这些信息中提取用户和系统需求，将问题求解、约束、细化、协商 和需求规格说明等元素结合在一起，为下一步的需求分析提供素材。

软件需求分析(Requirement Analysis) ：基于需求获取得到的初步软件需求，进一步精化和分析软件需求，确定软件 需求优先级，建立软件需求模型，发现和解决软件需求缺陷，形成高质量的 软件需求模型和软件需求规格说明书。

结构化分析方法：面向数据流进行需求分析的方法。该分析模型的核心是数据字典； 有3种模型图：数据流图（DFD）、实体-关系图(E-R图)、状态-迁移图（STD）等

功能建模方法（Functional Modeling）

功能建模：用抽象模型的概念，按照软件内部数据传递交换的关系，自顶向下，逐层 分解，直到找到满足功能要求的所有可实现的软件为止。

数据流图（Data Flow Diagram）：是软件工程流行的建模技术；它从数据传递和加工 的角度，以图形的方式刻画数据流，即从输入到输出的移动变换过程，其基础是功能 分解。它按照自顶向下的方式从环境图开始，将功能一直分解下去，直到模块描述。

数据建模方法（Data Modeling）

数据模型（Data Model）：使用实体-关系图(E-R图)来建立数据模型，以刻画数据对象及其 关系；图中包含三种元素：数据对象（实体）、数据对象的属性、数据对象之间的关系。

数据对象Data Object（实体(Entity)）是目标系统所需复核信息的表示，只封装了数据；属 性定义数据对象的特征；数据对象的关系分为三种：一对一关联、一对多关联、多对多关联。

行为建模方法(Human Behavior Representation, HBR)

行为模型（Behavior Model）：使用状态-迁移图（STD）来建立行为模型，以刻 画系统状态及引发状态变化的事件；图中有状态、状态转换、事件等元素。

数据字典(Data Dictionary)

数据字典：数据字典以词条方式定义在数据模型、功能模型和行为模型中出现的数 据对象及控制信息的特性，给出它们的准确定义，包括数据流加工、数据文件、数 据元素，以及数据原点和数据汇点等。

类图（Class Diagram）：描述系统 的类构成，刻画系统的静态组成结构。

类的关系

对象图（Object Diagram）：描述系统中的对象在运行过程中的一种静态瞬时快照；它是 类图在系统的运行过程中某个时刻点上或某一时间段内的实例化样本。

状态图(State Chart/Diagram)：描述实体（对象、系统）在事件刺激下的反应式动态行为 及其导致的状态变化；刻画了实体的可能状态、每个状态下可响应事件、响应动作、状态迁移。

顺序图(Sequence Diagram)：对象间的消息交互序列；强调消息传递的时间序。

通信图(Communication Diagram)：描述对象间的交互协作关系；突出对象间的合作。

需求规格描述(Software Requirement Specification)

需求分析完成后，需要形成需求文档“系统需求规格说明书”。它是为软件 系统或子系统指定需求和指定保障每个需求得到满足所使用的方法，描述软 件系统的功能和性能以及那些系统约束。

需求规格说明书以图文并茂的方式，结合需求模型以及需求的自然语言描述， 刻画软件需求，包括功能性和非功能性软件需求，软件需求的优先级列表等。

需求规格说明(SRS)：描述了计算机软件配置项的需求以及为确保需求得到满 足所使用的方法。

数据需求说明(DRD)：描述了软件开发过程中所需要处理的数据以及采集数据 的要求等。

第四章 软件设计与实现

软件设计：从软件需求规格说明书出发，根据需求分析阶段确定的功能设计软 件系统的整体结构、划分功能模块、确定每个模块的实现算法以及编写具体的 代码，形成软件的具体设计方案。

软件设计四个阶段：

数据设计：软件系统的全局数据结构设计，包 括数据实体及属性和相互之间的关系。

体系结构设计：表示软件系统的高层设计结构 与分解结构，即构件划分、构件外部属性及其 相互之间的交互关系。

构件接口设计：构件之间交互接口的设计，包 括构件接口的功能性和非功能性要求、接口交 互协议、接口操作及实现类定义等。

构件级设计：构件内的具体设计方案。例如面 向对象设计类及类的关系定义、构件内部的局 部数据结构和算法设计等。

软件设计管理：在软件设计与开发过程中，软件设计工程师需要与软件质量保证 人员、软件配置管理人员等一起对软件设计制品进行有效管理，以应对软件开发 与运维过程中出现的各种变化。

结构化软件设计：是基于模块化、自顶向下、逐层细化、结构化程序设计等技术基础上 发展起来的，是一种将结构化分析得到的数据流图映射成软件体系结构的设计方法。其 主要任务是在需求分析的基础上建立各种设计模型，并通过对设计模型的分析和评估来 确定，这些模型是否满足需求。

面向对象的软件设计

面向对象的软件设计的主要任务是：在面向对象分析的基础上，完成体系结构设计、接口设计或人机交 互设计、数据设计、类设计及构件设计。

面向对象设计中的数据设计并不是独立进行的；其类图相当于数据的逻辑模型，可以方便地转换成数据 的物理模型。

“包”的概念

当系统中涉及的类的数量比较多时，为了系统实现与维护过程中的方便性，往往会将设计类按照彼此关 联的紧密程度聚合到一个大粒度的“包”（Package）中。按照UML的定义,包是一组命名的建模元素集合。

包是一个逻辑设计概念；一个包可包含其他的包；包拥有自己的成员；包可以导入其他包。

设计模式：软件设计具有很强的经验性。软件设计模式是从软件设计过程中总结出来的相对成 熟和成功的方法，是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结； 是针对某类特定问题的可借鉴的通用和参考性的设计方案。

软件设计方法中使用模式主要有三类：

体系结构模式(Architecture Pattern)：定义软件系统的基本组织结构形态或方案，体现子 系统或软件构件的责任、相互之间的关系，并定义体系结构元素（子系统、包、类、构件） 之间关系的规则。

设计模式（Design Pattern）：为软件系统的子系统、构件或构件之间的关系提供精炼的解 决方案。这些模式解决设计中特有的元素，例如构件聚集、构件间的联系或影响构件到构件 之间通信的机制等。

框架（Framework）：随着应用的发展，某些带有整体性的应用模式形成了特定的框架，成为 已实现的特定的骨架基础设施。框架提供了基础功能，规定了系统元素、构件及构件的连接 方式。开发者只需要将注意力集中于业务逻辑的实现。

典型的设计模式：

工厂模式（Factory Pattern）是 Java 中最常用的设计模式之一。这种类型的设计模式属于创建型 模式，它提供了一种创建对象的最佳方式。在创建对象时不会对客户端暴露创建逻辑，并且是通过 使用一个共同的接口来指向新创建的对象。

抽象工厂模式（Abstract Factory Pattern）：围绕一个超级工厂创建其他工厂。该超级工厂又称 为其他工厂的工厂。它提供一种接口用以创建一个相联系的对象族（工厂），不需要显式指定它们 的类。每个生成的工厂都能按照工厂模式提供对象。

建造者模式（Builder Pattern）：使用多个简单对象一步一步构建成一复杂对象。它提供了一种创 建对象的方式；一个 Builder类会一步步构造最终的对象。该 Builder 类是独立于其他对象的。

适配器模式（Adapter Pattern）将一个类的接口转换成客户希望的另外一个接口。这种模式结合了 两个独立接口的功能；设置一个混合接口类，该类负责加入独立的或不兼容的接口功能。

中介者模式（Mediator Pattern）是用来降低多个对象和类之间的通信复杂性。它提供了一个中介 类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。

MVC（Model-View-Controller，模型-视图-控制器）模式：用于应用程序的分层开发。

Model（模型）：模型代表一个存取数据的对象。它可以带有逻辑，在数据变化时更新控制器。

View（视图）： 视图代表模型包含的数据的可视化。

Controller（控制器）：控制器作用于模型和视图上。它控制数据流向模型对象；在数据变化时更新视图。 它使视图与模型分离开。

SOA的核心：识别、设计和实现服务(Services)、服务构件(Components)、 服务间的协同(Choreography)。

SOMA：通过面向服务的建模、分 析和设计活动，构造SOA应用。

软件实现：根据软件设计模型，编写出目标软件系统的程序代码，并对代码进行 必要的测试，以发现和纠正代码存在中的缺陷，并将可运行的目标代码部署到目标 计算机上运行。

软件实现不仅要编写出程序代码，还要确保代码的质量，涉及多方面的软件开发 工作，如编码、测试、调试等等。

软件实现：包含编码、测试、调试等一系列的开发活动。

编码：基于软件设计模型和文档，采用程序设计语言，编写出目标软件系统的程序代码。

单元测试：对编写的各个基本模块进行单元测试，以发现模块单元中存在的缺陷和问题。

软件调试：发现产生缺陷原因，定位缺陷位置，进而对代码缺陷进行修复。

软件测试：对多个单元直至软件系统进行集成测试，以发现和纠正单元间的接口与参数传递问题。

敏捷软件开发方法(Agile Development Method)起步于上世纪90年代，成熟于本世纪初。敏捷开 发方法强调以代码为中心，只编写少量文档，快速、轻巧、主动、增量式应对软件需求变化， 持续、及时交付可运行的软件系统。

本质：以快速的增 量和迭代方式进行 软件开发

第五章 软件质量与软件工程管理

软件质量是指对用户在功能和性能方面需求的满足、对规定的标准和规范的遵循以 及正规软件某些公认的应该有的本质。

软件质量是在一定程度上应用有效的软件过程，创造有用的产品，为生产者和使用 者提供明显的价值。

软件过程的两个方面：

软件过程质量：好的软件过程能够生产出好 的产品，软件过程质量在一定程度上决定了 软件产品的质量。

软件产品质量：软件与明确描述的功能和性 能需求、文档中明确描述的开发标准以及任 何专业开发的软件产品都应该具有的隐含特 征相一致的程度，即软件满足给定需求（功 能、性能、标准、特征等）的程度。

软件质量涉及三方面因素：软件的运行特性、承受变更的能力和对新环境的适应能力。

软件质量管理：软件组织在软件产品生产中的质量策划、质量控制、质量度量与验证、质 量改进等与质量有关的相互协调的活动。

软件过程指软件生存期所涉及的一系列相关过程；是人们建立维护和演化软件产品整个过程 中所有技术活动和管理活动的集合。过程是活动的集合，活动是任务的集合。

软件过程是一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤， 包括中间产品、资源、角色及过程中采取的方法、工具等范畴。

软件过程主要针对软件生产和管理进行研究，涉及软件开发、工程支持和工程管理。

软件基本过程：按过程中活动的不同主体可分为五个过程：

获取过程：是获取者（需方）所从事的活动和任务，其目的是获得满足客户所表达的那些要 求的产品和服务。该过程以定义客户要求开始，以接受客户所要求的产品或服务结束。

供应过程：是供方为了向客户提供满足需求的软件产品或服务所从事的一系列活动和任务， 其目的是向客户提供一个满足已达成需求的产品或服务。

开发过程：是软件开发者所从事的一系列活动和任务，其目的是将一组需求转换为一个软件 产品或系统；包括13个活动：过程的实施准备、系统需求分析、系统结构设计、系统需求分 析、软件体结构设计、软件详细设计、软件编码和测试、软件集成、软件合格测试系统、集 成系统合格测试、软件安装、软件验收支持等。

运行过程：是系统操作者所从事的一系列活动和任务，其目的是在软件产品预期的环境中运 行该产品，并为该软件产品的维护提供支持。

维护过程：是维护者所从事的一系列活动和任务，其目的是对交付后的系统或软件产品，为 了纠正其错误、改进其性能和其他属性而进行修改，或因环境变更而对其进行调整。

软件过程成熟度是软件过程改进的一个重要概念；它是指一个特定软件过程得到清晰的定 义、管理、测量、控制并且是有效的程度。

软件过程基础设施是指软件过程的基础框架和结构框架，包括组织和管理的岗位和职责、支 持定义过程、开展过程、活动获取和分析过程有关绩效反馈以及不断进行过程改进活动所必 须的技术工具和平台。

软件过程改进SPI（Software Process Improvement）：就是在软件过程中为了更有 效地达到优化软件过程的目的，同时改善或改变其软件过程的一系列活动。

软件测试是以评价一个程序或软件系统的质量或能力为目的的一项活动（Bill Hetzel）。

软件测试是以发现错误为目的而执行一个程序或系统的过程（G. J. Myers）。

软件测试过程：设计数据(测试用例) -> 运行测试用例(程序来处理数据) -> 判断运行结果(是否符合预期结果)

软件测试关键任务：明确软件测试对象（程序代码）、设计软件测试用例、运行程序代码（输 入、输出和分析测试用例）、形成结果评价与判断（与预期结果对比，判断是否存在缺陷

软件测试活动：包括单元测试（Unit Testing）、集成测试（Integration Testing）、确认测试（ Validation Testing）、系统测试（System Testing）等

测试用例(Testing Case)： 测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。 测试用例是执行的最小测试实体；就是设计一个场景，使软件程序在这种场景下能够正常运行并达到程序所设计的执行结果。

单元测试（Unit Testing）：验证开发人员所编写的代码是否可以按照其所设想的方式执行而产 出符合预期值的结果，确保产生符合需求的可靠程序单元。 单元含义：结构化程序单元是模块；面向对象的程序单元是类。 单元测试范围：对软件基本组成单元（构件或模块）进行测试，侧重于构件中的内部处理逻辑 和数据结构（依据详细设计）。 单元测试内容：单元接口、局部数据结构、代码执行路径、代码的边界条件、错误及异常处理

集成测试(Integration Testing)：也称为组装测试或联合测试。在单元测试的基础上，将构成目标软件的程序单元按照总体设计的要求逐步组装成为子系统或 系统，测试它们的接口与集成是否存在缺陷。 集成测试是构造软件体系结构的系统化技术，旨在发现与接口相关的错误。 结构化集成测试针对调用关系进行测试；面向对象集成测试针对对象依赖关系进行测试。

系统测试(System Testing)： 系统测试是将已经集成好的软件系统作为一个整体，与计算机硬件、外设、支持软件、数据和人 员等其他元素结合在一起，在实际运行和使用环境下进行的一系列测试。 系统测试是在集成测试的基础上，检验软件系统是否符合需求规格说明书各方面的要求。

回归测试(Regression Testing)： 回归测试是验证对系统的变更或修改没有影响到原有的功能，并保证当前功能的变更是正确的。 回归测试可以发生在软件测试的任何阶段，包括单元测试、集成测试和系统测试，其令人烦恼的 原因在于频繁的重复性劳动。

软件测试过程的敏捷测试模型——该模型是针对敏捷软件开发迭代的测试活动；测试 活动是随着敏捷迭代化的开发过程持续不断地进行的，在有限时间内主要对新增功能 或特性进行测试，不断修正质量指标，从而确保频繁向客户交付可运行的软件产品。

白盒测试：又称“结构测试”、“逻辑驱动测试”；它把测试对象看做一个透明的 盒子，根据程序内部的逻辑结构及有关信息，来设计或选择测试用例，对程序所有逻 辑路径进行测试，测试程序运行是否正常和满足设计要求。

白盒测试的前提是已知软件模块的逻辑结构，据此可掌握模块的基本路径，检验程序 模块是否按内部工作流程来运行的；如果不是，则存在缺陷。

白盒测试主要用于单元测试和集成测试。

黑盒测试：又称“功能测试” 、 “数据驱动测试”；它将测试对象看做一个黑盒子，测试人 员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书检查程序功能 是否符合它的功能说明。

黑盒测试根据已知的程序功能和性能(而非内部细节)，设计测试用例并通过测试检验程序的 每个功能和性能是否正常。

黑盒测试主要用于集成测试、确认测试和系统测试。

软件维护是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程。 IEEE 的定义：软件维护是指软件交付给用户使用之后，修改软件系统及其他部件的过程，以 修复缺陷，提高性能或其他属性，增强软件功能以及适应变化的环境。

软件维护主要有四种类型：改正性维护（或称纠正性维护）、适应性维 护、完善性维护或增强、预防性维护或再工程。

改正性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误和缺陷和错误。 用户在使用软件过程中一旦发现缺陷，他们会向开发人员提出纠正性维护的请求。

适应性维护是指对软件进行改造以便适应信息技术和管理需求变化、新的运行环境和平台。 此类维护工作也要像系统开发一样，有计划、有步骤地进行。

完善性维护是为扩充功能和改善性能而进行的修改，主要是指对已有软件系统增加一些在系统 分析和设计阶段中没有规定的功能与性能特征；包括对处理效率和编写程序的改进。

预防性维护为了改进软件系统的可靠性和可维护性，为以后软件的改进奠定基础的维护活动。 为了适应未来软硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化 而不被淘汰。

软件维护技术包括软件逆向工程、代码重组、设计重构和软件再工程等。

代码重组（Code Refactoring）：在不改变软件功能的前提下，对程序代码进行重新组织 ，改善其内部结构,使重组后的代码具有更好的可维护性，能够有效支持代码的变更。

逆向工程指通过理解和分析目标系统来标识系统的部件及其交互关系，再使用其他形式或者更 高层的抽象创建系统表现（高抽象层次的软件制品）的过程。

软件设计重构（Redesign / Restructure）：通过调整程序代码改善软件的质量、性能，使其程序 的设计模式和架构更趋合理，提高软件的扩展性和维护性。

软件再工程（Software Reengineering）：通过分析和变更软件的架构，实现更高质量的软件系统 的过程。再工程既包括逆向工程，也包括正向工程。

软件演化是指程序不断调节，增强功能和结构，以适应变化的软件需求，满足新的软件需求 的过程，或提高软件系统的质量。

软件质量保证是建立一套有计划的系统方法，来向管理层保证拟定出的标准、步骤、实践和方法能够 正确地被所有项目所采用。其目的是通过对软件产品和活动进行评审和审计来验证软件是合乎标准的

软件质量保证过程：主要包括计划、监督、记录、分析和报告。

软件项目管理(Software Project Management)：对软件项目所涉及的过程、人员 、产品、成本和进度等要素进行度量、分析、规划、组织和控制的过程，以确保 软件项目按照预定的 成本、进度、质量要 求顺利完成，提交满 足用户要求的软件产 品或服务。

软件项目管理涉及的主要方面：4个P,即人员(People)、产品(Product)、过程(Process)和项 目（Project）。

软件度量（Software Metrics）：对软件开发项目、过程、产品、资源进行数据 定义、收集以及分析的持续性定量化描述及过程，如软件项目的规模、成本、工 作量、质量等，还包括顾客满意度度量、质量度量、项目度量、以及品牌资产度 量、知识产权价值度量等等。

软件项目估算（Software Project Estimation）：对需求分析、设计、编码、测试 、集成交付等整个软件开发过程所花费工作量、时间、成本等的预测。

软件项目计划：对软件项目实施所涉及的活动、人员的安排、任务的划分、开发进度、 资源的分配和使用等方面作出的预先规划。

软件需求管理(Software Requirement Management) 任务：获取、文档化和评审用户需求，对用户需求变更进行控制和管理。 内容：需求变更控制、需求跟踪、需求状态跟踪、需求文档版本控制。

软件风险管理（Software Risk Management）是对软件开发过程中各种风险进行 分析、预测、评估、监控的过程。 软件风险：使软件项目实施受到影响和损失、甚至导致失败的、可能会发生的事件 。 软件风险的类型：软件规模风险、商业影响风险、客户相关风险、软件过程风险、 开发环境风险、开发技术风险、开发人员风险等等

软件配置(Software Configuration)：由在软件工程过程中产生的所有信息项(包 括文档、代码、数据、标准与规范等)构成，可以看作软件的具体形态(软件配置项) 在某一时刻的瞬间影像。 软件配置管理（SCM，Software Configuration Management）：对软件产品进行 标识、存储、更动和发放，记录和报告其状态，执行版本控制、变更控制的规程， 并进行审计，验证软件产品的正确性，保证软件配置项的完整性和可跟踪性。

软件配置项(SCI，Software Configuration Item)：软件生命周期内产生、需进行 配置管理的工作产品，包括各类文档、程序代码、数据、标准与规范等。

软件质量管理（Software Quality Management） 软件质量管理是指软件开发机构为保证软件项目需求所实施的质量活动。

第六章 软件工程教育与职业发展

软件工程专业主要课程系列

基础理论类：数学基础理论、计算机科学基础理论

计算机专业类：计算机软硬件系统专业课、技术基础课

软件工程类：软件工程方法与技术核心课

软件开发平台与工具类：主流软件平台、程序设计语言、软件开发工具

软件工程实践类：软件工程项目设计与专业综合设计

专业专门化或行业应用类：专业方向选修课、学科交叉选修课、应用行业 领域选修课

企业与经济管理类：企业管理与创业课、经济法律课

专业实验

这一部分建议软工专业的同学在完成实验基础上进行复习，考试需要理解实验内容，但并不会考察特别难，往往会与前面需求分析课程的知识相结合一部分。

考试

软工专业考试分别有概念阐述题、判断题、简答题和实验分析题。阐述题需要对基本概念进行理解（有的部分要格外记忆），今年考了软件需求工程，软件体系结构，软件工程，软件设计风格这些的定义，还有软件工程的发展。判断题还是比较明显的，后面的简答题第一个是MVC阐述一下是什么，然后要画一个模型图，第二个是解释面向对象及过程，并且要求画面向对象的过程图。这一部分还有后面实验分析的部分xxf说使劲写写了就给分（笑），实验分析题一个是让画用例图的，另一个是画类图关系的。