【2024软考架构师自学笔记】4. 软件工程基础知识

注：本篇是重点，原本是按照大纲，并参考视频课程讲解补充内容，但由于两者内容编排不一致，导致有些混乱，以后有时间再编辑整理。

---

4.1 软件工程

4.1.1 软件工程概述

• 软件危机(Software Crisis)
  具体表现为软件开发进度难以预测、软件开发成本难以控制、软件功能难以满足用户期望、软件质量无法保证、软件难以维护和软件缺少适当的文档资料。
• 软件工程
  是应用计算机科学、数学、逻辑学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则和方法，以提高质量、降低成本和改进算法。
• 软件工程过程
  是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下4个方面：
  • P(Plan)——软件规格说明。规定软件的功能及其运行时的限制。
  • D ( Do) ——软件开发。开发出满足规格说明的软件。
  • C(Check)——软件确认。确认开发的软件能够满足用户的需求。
  • A(Action)——软件演进。软件在运行过程中不断改进以满足客户新的需求。
• 软件系统工具
  • 软件开发工具：需求分析工具、设计工具、编码排错工具、测试工具等。
  • 软件维护工具：版本管理工具、文档分析工具、逆向工程工具、再工程工具等。
  • 软件管理和支持工具：项目管理工具、配置管理工具
• 软件设计四个活动：数据设计、架构设计、人机界面设计、过程设计（功能等）。

4.1.2 软件过程模型

• 瀑布模型(Waterfall Model)
  阶段：需求分析、系统设计、程序设计、编码实现、单元测试、集成测试、系统测试、运行维护
  特点：自顶向下，逐级分层，每个阶段因果关系紧密相连，只适合需求明确的项目。
• 原型模型(Prototype Model)
  又称快速原型，是原型方法使用的生命周期模型。原型模型解决了瀑布模型需求难以一次确定、结果难以预见的缺点。原型模型有原型开发和目标软件开发两个阶段。抛弃型原型将原型作为需求确认的手段，在需求确认结束后就被抛弃不用， 继续用瀑布模型。演化性原型在需求确认结束后，不断补充和完善原型，直至形成一个完整的产品。
• 螺旋模型(Spiral Model)
  是在快速原型基础上扩展而成。它把整个软件开发流程分成多个阶段，每一个阶段都由：目标设定、风险分析、开发和有效性验证、评审4部分组成。包含维护周期。开发过程实际是上述4个部分的迭代过程。
  特点：特别强调了风险分析，适合大型软件开发。
• V模型
  模型整体为V字结构，左右对应。左边为需求分析、概要设计、详细设计、编码。右边为单元测试、集成测试、系统测试、验收测试。适用于需求明确和需求变更不频繁情况。强调测试。
  特点：
  1. 单元测试主要目的是针对编码中的错误。
  2. 集成测试目的是针对详细设计中的可能存在的问题。
  3. 系统测试是针对概要设计，检查系统作为一个整体是否有效得到运行。
  4. 验收测试由业务专家和用户测试，以确定系统是否能真正符合业务上需要。
• 增量模型
  系统分批次交付，首先开发核心模块。
• 喷泉模型
  以用户需求为动力，以对象作为驱动的模型，适合面向对象的开发方法。
• 基于构件的开发模型CBSD
  利用预先构件库开发。
• 形式化方法模型
  建立在严格数学模型基础上开发。
• 敏捷模型(Agile)
  尽快完成，可以适当牺牲文档。
• 统一过程模型(RUP)

4.1.3 敏捷模型

• 敏捷方法的特点
  • 敏捷型方法是“适应性” (adaptive) 而非“预设性” (predictive) 的。软件开发不能像工程那样预先设计规划，它得有一定的适应性，该方法使用反馈机制对不可预测过程进行控制。
  • 敏捷型方法是“面向人的” (People-oriented) 而非“面向过程的” (Process-oriented)。与传统的计划驱动方法相比，敏捷开发过程要求开发人员必须有权做技术方面的所有决定，强调开发中相关人员之间的信息交流。
• 敏捷方法的核心思想
  • 敏捷方法是适应型，而非可预测型。与传统方法不同，敏捷方法拥抱变化，也可以说它的初衷就是适应变化的需求，利用变化来发展，甚至改变自己，最后完善自己。
  • 敏捷方法是以人为本，而非以过程为本。
  • 迭代增量式的开发过程。敏捷方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化。
• 敏捷方法
  • 极限编程 (Extreme Programming，XP)
    基础和价值观是交流、朴素、反馈和勇气，即任何一个软件项目都可以从4个方面入手进行改善：加强交流、从简单做起、寻求反馈、勇于实事求是。
    X P是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期，通过积极的交流、反馈以及其他一系列的方法，开发人员和客户可以非常清楚开发进度、 变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
    高效、低成本，强调测试先行，即先写测试代码，再编写程序。
  • 水晶系列方法
    以人为中心，不同的项目，采用不同的策略。每个都有独特的角色、过程模式、工作产品和实践。
• 并列争球法(Scrum)
  该方法侧重于项目管理，是一种迭代式增量软件开发过程。把每段时间（如30天）一次的迭代称为一个冲刺Sprint，并按需求优先级来实现产品，多个自组织自治的小组并行地递增实现产品。
• 特性驱动开发方法(FDD)
  是一个迭代开发模型，认为有效的软件开发需要3要素：人、过程和技术。
  定义了6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。根据项目大小，部分角色可以重复。
  有5个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。

4.1.4 统一过程模型RUP

RUP描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。RUP类似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、模版以及事例支持。RUP软件开发生命周期是一个二维的软件开发模型。

• RUP中有9个核心工作流：
  • 业务建模 (Business Modeling)：确定高层次业务需求
  • 需求 (Requirements)：定义系统功能及用户界面
  • 分析与设计：把需求分析的结果转化为分析与设计模型。
  • 实现 (Implementation)：编码、单元测试。
  • 测试 (Test) ：检查各子系统之间的交互、集成。
  • 部署 (Deployment)：打包、分发、安装软件，升级旧系统;培训用户及销售人员，并提供技术支持。
  • 配置与变更管理 (Configuration & Change Management)：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
  • 项目管理 (Project Management): 为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
  • 环境 (Environment): 为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。
• RUP4个阶段：
  RUP把软件开发生命周期划分为多个循环 (Cycle), 每个循环生成产品的一个新的版本， 每个循环依次由4个连续的阶段 (Phase) 组成，每个阶段完成确定的任务。这4个阶段如下。
  • 初始 (inception) 阶段：定义最终产品视图和业务模型，并确定系统范围。
  • 细化 (elaboration) 阶段：设计及确定系统的体系结构，制订工作计划及资源要求。
  • 构造 (construction) 阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。
  • 移交 (transition) 阶段：把产品提交给用户使用。
• RUP定义的核心概念
  • 角色：Who的问题，对项目中的架构师、设计师、实现人员、测试等角色明确定义。
  • 活动：How的问题，独立工作单元。
  • 制品：What的问题。制品是活动生成、创建或修改的一段信息。
  • 工作流：When的问题。工作流描述了一个有意义的连续的活动序列。
• RUP特点
  • 用例驱动：RUP中的开发活动是用例驱动的，即需求分析、设计、实现和测试等活动都是用例驱动的。
  • 以体系结构为中心：RUP中的开发活动是围绕体系结构展开的。软件体系结构的设计和代码设计无关，也不依赖于具体的程序设计语言。对于一个软件系统，不同人员所关心的内容是不一样的，因此，软件的体系结构是一个多维的结构，会采用多个视图 (View) 来描述软件体系结构， 如“4+1”视图模型。
  • 迭代与增量：RUP强调采用迭代和增量的方式来开发软件。
• “4+1”视图模型
  • 分析人员和测试人员关心的是系统的行为，会侧重于用例视图；
  • 最终用户关心的是系统的功能，会侧重于逻辑视图；
  • 程序员关心的是系统的配置、装配等问题，会侧重于实现视图；
  • 系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，会侧重于进程视图；
  • 系统工程师关心的是系统的发布、安装、拓扑结构等问题，会侧重于部署视图。
• 软件开发采用迭代和增量的方式有以下好处：
  • (1)在软件开发的早期就可以对关键的、影响大的风险进行处理。
  • (2)可以提出一个软件体系结构来指导开发。
  • (3)可以更好地处理不可避免的需求变更。
  • (4)可以较早得到一个可运行的系统，鼓舞发团队的士气，增强项目成功的信心。
  • (5)为开发人员提供一个能更有效工作的开发过程。

4.1.5 软件能力成熟度模型CMM

软件能力成熟度模型 (Capability Maturity Model for Software,CMM) 是一个概念模型，模型框架和表示是刚性的，不能随意改变，但模型的解释和实现有一定弹性。国际上用于评估公司软件能力水平标准。

• 软件能力成熟度模型集成CMMI
  CMMI是一种软件能力成熟度评估标准，是在CMM上发展而来，主要用于指导软件开发过程的改进和进行软件开发能力的评估。
• CMMI五个成熟度等级：
  • 初始级：开发过程杂乱无章，没有明确定义的步骤，完全依赖个人能力。
  • 已管理级：软件过程已经进行管理、文档化。
  • 已定义级：制定标准流程。
  • 量化管理级：制定了质量度量标准。
  • 优化级：通过增量式的与创新式的过程与技术改进，不断地改进提升。

4.2 需求工程

• 软件需求：用户对系统在功能、行为、性能、设计约束等方面的期望。
• 软件需求包括：业务需求、用户需求、功能需求(也包括性能、质量等非功能需求)。
  需求阶段首先需要定义用户的原始需求，并与用户、客户达成一致；其次，需要这对原始需求进行分析，给出一个初步的软件解决方案，并给出该软件的需求描述规约，以指导后续的软件开发。业务需求和用户需求构成了用户原始需求文档的内容。
• 需求工程的活动的几个阶段：需求获取、需求分析、形成需求规格、需求确认与验证、需求管理。
• 需求管理主要内容：变更控制、版本控制、需求跟踪、需求状态跟踪。

4.2.1 需求获取

• 需求获取的基本步骤
  • 开发高层的业务模型：建立一个业务模型，描述用户的业务过程，确定用户的初始需求。
  • 定义项目范围和高层需求：常见的建模手段包括系统上下文图和系统顶层用例图等。
  • 识别用户角色和用户代表：用户角色可以是人，也可以是与系统打交道的其他应用程序或硬件部件。熟悉这些系统或硬件的人员作为用户代表。
  • 获取具体的需求
  • 确定目标系统的业务工作流
  • 需求整理与总结
• 需求获取方法：用户面谈、需求专题讨论会、问卷调查、现场观察、原型化方法、头脑风暴法

4.2.2 需求变更

• 变更控制过程：
  • 问题分析和变更描述：识别出问题，从而产生一个更明确的需求变更提议。
  • 变更分析和成本计算：分析确定是否执行变更。
  • 变更实现：修改后的需求。
  • 变更验证
  • 沟通存档
• 常见的需求变更策略：
  (1)所有需求变更必须遵循变更控制过程。
  (2)对于未获得批准的变更，不应该做设计和实现工作。
  (3)变更应该由项目变更控制委员会决定实现哪些变更。
  (4)项目风险承担者应该能够了解变更的内容。
  (5)绝不能从项目配置库中删除或者修改变更请求的原始文档。
  (6)每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性。
• 变更控制委员会
  变更控制委员会 (Change Control Board,CCB) 是项目所有者权益代表，负责裁定接受哪些变更。通常包括用户和实施方的决策人员。 CCB 是决策机构，但不提出变更方案。

4.2.3 需求追踪

• 需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性，是要在整个项目的工件之间形成水平可追踪性，确保所有的工作成果符合用户需求。
  跟踪能力是优秀需求规格说明书的一个特征。
• 需求跟踪有两种方式：
  (1)正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
  (2)逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
• 需求追踪工具：
  • 原始需求用例表：用户原始需求和用例对应表。
  • 用例元素表：用例和元素（功能点、设计元素、代码模块、测试用例）对应表。

4.3 系统分析与设计

系统分析是把复杂的对象分解为简单的组成部分，系统需求规格说明书。
系统设计的目标是根据系统分析的结果，完成系统的构建过程，内容包括概要设计和详细设计。

4.3.1 结构化方法

结构化方法SASD(Structured Analysis and Structured Design)，针对软件生存周期各个不同的阶段，它有结构化分析 (SA)、 结构化设计 (SD) 和结构化编程 (SP) 等方法。

结构化分析 (SA)

结构化分析方法给出一组帮助系统分析人员产生功能规约的原理与技术。结构化分析的常用手段是数据流图 (DFD) 和数据字典。

• 数据流图 (DFD)
  DFD需求建模方法，也称为过程建模和功能建模方法。 DFD建模方法的核心是数据流，从应用系统的数据流着手以图形方式刻画和表示一个具体业务系统中的数据处理过程和数据流。建立DFD图的目的是描述系统的功能需求。
  • 数据流图的4种基本元素：
    • 数据流：数据流用一个箭头描述数据的流向。
    • 处理：表示对数据进行的加工和转换，在图中用矩形框表示。
    • 数据存储：表示用数据库形式(或者文件形式)存储的数据。
    • 外部项：也称为数据源或者数据终点。描述系统数据的提供者或者数据的使用者，在图中用圆角框或者平行四边形框表示。
  • 数据流图的建模过程及步骤：
    • 明确目标，确定系统范围：明确目标系统的功能需求。
    • 建立顶层 DFD 图：表达和描述了将要实现的系统的主要功能。
    • 构建第一层DFD分解图：把顶层DFD 图中的处理分解成多个更细化的处理。
    • 开发 DFD层次结构图：对第一层DFD分解图中的全部处理框作出分解。分解可采用以下原则：保持均匀的模型深度；按困难程度进行选择；如果一个处理难以确切命名，可以考虑对它重新分解。
    • 检查确认DFD 图
  • 检查确认DFD 图的规则：
    • 父图中描述过的数据流必须要在相应的子图中出现；
    • 一个处理至少有一个输入流和一个输出流；
    • 一个存储必定有流入的数据流和流出的数据流；
    • 一个数据流至少有一端是处理端；
    • 模型图中表达和描述的信息是全面的、完整的、正确的和一致的。
• 数据字典
  数据字典是描述数据的信息集合，是对系统中使用的所有数据元素定义的集合。
  数据字典最重要的作用是作为分析阶段的工具。数据字典的作用是给数据流图上每个元素加以定义和说明。
  • 数据字典各部分的描述：
    • 数据项：数据项描述={数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系}
    • 数据结构：数据流图中数据块的数据结构说明。由若干个数据项或数据结构组成，数据结构反映了数据之间的组合关系。数据结构描述={数据结构名，含义说明，组成：{数据项或数据结构}}
    • 数据流：数据流图中流线的说明。数据流描述={数据流名，说明，数据流来源，数据流去向，组成：{数据结构},平均流量，高峰期流量}
    • 数据存储：数据流图中数据块的存储特性说明。数据存储描述={数据存储名，说明，编号，流入的数据流，流出的数据流，组成：{数据结构},数据量，存取方式}
    • 处理过程：数据流图中功能块的说明。处理过程描述={处理过程名，说明，输入：{数据流},输出：{数据流},处理：{简要说明}}
• 需求规格说明书SRS
• 系统设计
  • 人机界面设计原则：
    • 置于用户控制之下：不强迫，允许用户可随时控制操作
    • 减少用户记忆负担
    • 保持界面一致性

结构化设计

结构化设计 (Structured Design,SD) 是一种面向数据流的设计方法，它以SRS和SA阶段所产生的数据流图和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。结构化设计方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构。

• 结构化设计两个阶段：
  • 概要设计：主要任务是确定软件系统的结构，对系统进行模块划分，确定每个模块的功能、接口和模块之间的调用关系；
  • 详细设计：主要任务是为每个模块设计实现的细节。
• 模块结构
  功能分解就是将系统划分为模块，模块是组成系统的基本单位。
  • 信息隐藏与抽象：信息隐藏是采用封装技术，将程序模块的实现细节(过程或数据)隐藏起来。抽象原则要求抽取事物最基本的特性和行为，抽象层次包括过程抽象、数据抽象和控制抽象。
  • 模块化：模块是实现功能的基本单位，它一般具有功能、逻辑和状态3个基本属性，其中功能是指该模块“做什么”,逻辑是描述模块内部“怎么做”,状态是该模块使用时的环境和条件。
  • 耦合：表示模块之间联系的程度。从低到高排序：非直接耦合、数据耦合、标记耦合、控制耦合、通信耦合、公共耦合、内容耦合。
  • 内聚：内聚表示模块内部各代码成分之间联系的紧密程度，是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做目标单一的一件事情。一般说来，系统中各模块的内聚越高，则模块间的耦合就越低，但这种关系并不是绝对的。
    内聚度从高到低的排序：功能内聚、顺序内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚。
• 设计原则：在模块的分解中应尽量减少模块的耦合，力求增加模块的内聚，遵循“高内聚、低耦合”的设计原则。
• 系统结构图 (Structure Chart,SC)
  又称为模块结构图，它是软件概要设计阶段的工具，反映系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反映了系统的总体结构。
  在系统分析阶段，系统分析师可以采用 S A方法获取由DFD、 数据字典和加工说明等组成的系统的逻辑模型；在系统设计阶段，系统设计师可根据一些规则，从 DFD 中导出系统初始的SC。
  • 详细设计的主要任务：是设计每个模块的实现算法、所需的局部数据结构。
  • 详细设计的目标：实现模块功能的算法要逻辑上正确和算法描述要简明易懂。详细设计必须遵循概要设计来进行。
  • 设计的基本步骤：
    • (1)分析并确定输入/输出数据的逻辑结构。
    • (2)找出输入数据结构和输出数据结构中有对应关系的数据单元。
    • (3)按一定的规则由输入、输出的数据结构导出程序结构。
    • (4)列出基本操作与条件，并把它们分配到程序结构图的适当位置。
    • (5)用伪码写出程序。
  • 详细设计的表示工具：
    • 图形工具：利用图形工具可以把过程的细节用图形描述出来。具体的图形有业务流图、程序流程图、PAD(Problem Analysis Diagram) 图、NS流程图等。
    • 表格工具：用一张表来描述过程的细节，在这张表中列出了各种可能的操作和相应的条件。
    • 语言工具：用某种高级语言来描述过程的细节，例如伪码和PDL(Program Design Language) 等。
• 程序流程图
  又称为程序框图，是使用最广泛然的一种描述程序逻辑结构的工具。它用方框表示一个处理步骤，菱形表示一个逻辑条件，箭头表示控制流向。
• NS流程图
  也称为盒图，是一种强制使用结构化构造的图示工具，也称为方框图。其具有以下特点：功能域明确、不可能任意转移控制、很容易确定局部和全局数据的作用域、很容易表示嵌套关系及模板的层次关系。
• PAD图
  是一种改进的图形描述方式，可以用来取代程序流程图，相比程序流程图更直观，结构更清晰。最大的优点是能够反映和描述自顶向下的历史和过程。PAD提供了5种基本控制结构的图示，并允许递归使用。 PAD的特点如下：
  • 使用PAD符号设计出的程序代码是结构化程序代码；
  • PAD所描绘的程序结构十分清晰；
  • 用PAD图表现程序的逻辑易读、易懂和易记；
  • 容易将PAD图转换成高级语言源程序自动完成；
  • 既可以表示逻辑，也可用来描绘数据结构；
  • 支持自顶向下方法的使用。

UML统一建模语言

• UML组成3要素：构造块(事物、关系) 、图、公共机制。可用于需求工程和系统分析设计中。
• UML事物
  • 结构事物：静态部分，包括类、接口、协作、用例、构件、节点等。
  • 行为事物：代表时间和空间上的动作，包括消息、动作次序和连接。
  • 分组事物：包、构件。
  • 注释事物：描述、说明等。
• UML图
  • 静态图（结构图）：包括类图、对象图、构件图、部署图（软硬件之间的映射）、制品图（系统的物理结构）、包图、组合结构图
  • 动态图（行为图）：用例图（系统与外部参与者的交互）、顺序图（强调按时间的顺序）、通信图（之间协作图）、状态图（状态变迁）、活动图（类似流程图，可并行）、定时图（强调实际时间，例如洗衣机洗涤、放水、甩干）、交互概览图
• UML4+1视图
  与RUP中4+1视图一样，分为用例视图、逻辑视图、实现视图、进程视图、部署视图。
• 用例图 ****
  是用户角度描述系统功能，参与者（用户、组织、外部系统、时间、温度、传感器等）是外部触发因素，用例是功能单元。
  关系包括：
  • 包含关系：例如用户登记借书和查询借书记录两个功能单元，是需要包含用户登录这个功能单元的，需要用虚线箭头连接用户登录，并标注为<>。
  • 扩展关系：例如用户操作取款后，系统提示是否打印凭条，打印凭条这一功能单元是用户取款的附属（可选），使用虚线箭头指向取款功能单元，并标注为<>。
  • 泛化关系：是父子关系，例如用户注册（父）可以通过电话注册（子）或网上注册（子）。使用空心实线箭头表示。注意与包含关系的区别是泛化关系有父子关系，包含没有。
• 例题：根据描述填写用例图中缺少的信息。
• 类图与对象图 ****
  • 类图描述一组类、接口、协作和他们之间的关系。
  • 对象图：描述了一组对象及之间的关系，对象图是类图所建立的事物的实例等静态快照。
  • 关系：
    • 1: 0.* 一对0～多关系，例如：组和成员，图书列表和图书详情。
    • 依赖关系：一个事物发生变化影响另一个事物，例如：A类中调用B类的方法，若B类发生变化，则A类需要对应变化，即A依赖B。使用虚线箭头表示。
    • 泛化关系：特殊／一般关系。使用实线空心箭头表示。
    • 关联关系：包括：
      • 聚合关系：整体与部分生命周期不同，例如汽车和轮子关系，汽车报废轮子还可以用，使用实线空心棱形箭头表示。
      • 组合关系：整体与部分生命周期相同，例如公司和部门关系，公司倒闭部门也消失。使用实线实心菱形箭头表示。
    • 实现关系：接口与类的关系。使用虚线空心箭头表示。
• 顺序图
• 活动图
• 状态图
• 定时图

结构化编程

“面向结构”的程序设计方法即结构化程序设计方法，是“面向过程”方法的改进。
结构化程序设计的原则可表示为：程序=(算法)+(数据结构)。
结构化程序设计提出的原则可以归纳为32个字：自顶向下，逐步细化；清晰第一，效率第二；书写规范，缩进格式；基本结构，组合而成。

4.3.2 面向对象的方法

面向对象开发方法认为客观世界是由对象组成的，对象由属性和操作组成，对象具有封装性、继承性和多态性。面向对象开发方法是以用例驱动的、以体系结构为中心的、迭代的和渐增式的开发过程。（与RUP一样）主要包括需求分析、系统分析、系统设计和系统实现4个阶段。

• 面向对象分析方法OOA
  按照面向对象的思想来分析问题。OOA模型由5个层次(主题层、对象类层、结构层、属性层和服务层)和5个活动(标识对象类、标识结构、定义主题、定义属性和定义服务)组成。
• OOA的基本原则
  • 抽象：抽取事物共同的、本质性的特征。
  • 封装：封装就是把对象的属性和服务结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。
  • 继承：特殊类的对象拥有其对应的一般类的全部属性与服务，称作特殊类对一般类的继承。
  • 分类：分类就是把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。分类原则实际上是抽象原则运用于对象描述时的一种表现形式。
  • 聚合：聚合又称组装，其原则是：把一个复杂的事物看成若干比较简单的事物的组装体，从而简化对复杂事物的描述。
  • 关联：通过一个事物联想到另外的事物。事物之间确实存在着某些联系。
  • 消息通信：这一原则要求对象之间只能通过消息进行通信，而不允许在对象之外直接地存取对象内部的属性。
  • 粒度控制：对于一个复杂问题，考虑某部分的细节时则暂时撇开其余的部分。
  • 行为分析。现实世界中事物的行为是复杂的，由大量的事物所构成的问题域中各种行为往往相互依赖、相互交织。
• OOA基本步骤：确定对象和类、确定结构、确定主题、确定属性、确定方法。
• 面向对象设计方法 (Object-Oriented Design,OOD)
  是 OOA方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。OOD方法是一种更接近现实世界、更自然的系统设计方法。
• 在OOD 中类3种类型：
  • 实体类：实体类映射需求中的每个实体，是指实体类保存需要存储在永久存储体中的信息。
  • 控制类：是用于控制用例工作的类，例如，用例“身份验证”可以对应于一个控制类“身份验证器”,它提供了与身份验证相关的所有操作。
  • 边界类：用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。
• 面向对象程序设计
  面向对象程序设计 (Object Oriented Programming,OOP) 是一种计算机编程架构。 OOP的一条基本原则是计算机程序由单个能够起到子程序作用的单元或对象组合而成。 OOP 达到了软件工程的3个主要目标：重用性、灵活性和扩展性。 OOP= 对象+类+继承+多态+消息，其中核心概念是类和对象。
• OOP 的基本特点有封装、继承和多态。
• 多态
  多态是指在一组对象的一个类中，面向对象技术可以使用相同的调用方式来对相同的函数名进行调用，即便这若干个具有相同函数名的函数所执行的动作是不同的。
• 数据持久化与数据库
  主流的持久化技术框架包括Hibernate、iBatis和 JDO等。
• Hibernate：使用对象编程思维来操纵数据库。
• iBatis：通过手动编写SQL实现。

面向对象的23种设计模式

• 考查点：设计模式三种类型定位、设计模式分类、设计模式应用场景及特点
• 创建型模式（用于创建对象）
  • 工厂方法模式 Factory Method：动态创建对象
  • 抽象工厂模式 Abstract Factory：生产成系列对象
  • 原型模式 Prototype：克隆对象
  • 单例模式：创建单个
  • 构建器模式 Builder：复杂对象构建
• 结构型模式
  • 适配器模式 Adapter：类似电源适配器，转换接口
  • 桥接模式 Bridge：
  • 组合模式 Composite：
  • 装饰模式 Decorator：动态附加职责
  • 外观模式 Facade：对外统一接口，例如：手机的室外模式、飞行模式
  • 享元模式
  • 代理模式 Proxy：
• 行为型模式
  • 职责链模式 Chain of Responsibility：传递职责
  • 命令模式 Command：命令 可撤销
  • 解释器模式 Interpretor：例如工作流引擎
  • 迭代器模式 Iterator：
  • 中介者模式 Mediator：所有相互调用的各类，通过中介进行交互，网状变星型
  • 备忘录模式 Memento：
  • 观察者模式 Observer：订阅发布模式
  • 状态模式 Status：
  • 策略模式 Strategy：
  • 模版方法模式 Template Method：
  • 访问者模式 Visitor：数据与操作分类

软件系统建模

• 例题：
  软件系统建模是软件开发中的重要环节，通过构件软件系统建模可以帮助开发人员理解系统。软件系统建模是在系统需求分析和系统实现之间架起的一座桥梁，系统开发人员按照软件系统模型开发出符合设计目标的软件系统，并基于该模型进行软件的维护和改进。
  请围绕“论软件系统建模方法及其应用”论题，以此从以下三方面进行论证：
  1.概要的叙述你参与的软件系统开发项目以及你所担任的主要工作。
  2.说明软件系统开发中常用的建模方法有那几类？阐述每种方法等特点和适用范围。
  3.详细说明你参与的项目中采用了哪些方法，效果如何。
• 解题思路：
  1.根据实际描述
  2.建模方法：
  1）结构化建模方法：以过程为中心，可以分析现有系统以及定义新系统，使用数据流图实现，常用于流程较为稳定系统。
  2）信息工程建模方法（数据库建模方法）：以数据中心，使用ER图建模。
  3）面向对象的建模方法：将数据与过程集成到对象中，使用UML图实现。

4.4 软件测试

4.4.1测试方法

• 静态测试：是被测程序不运行，检查源程序的语句、结构、过程等来检查程序是否有错误。
• 动态测试：运行被测试程序。
• 黑盒测试：不考虑任何程序内部结构和特性测试，主要是对软件界面和软件功能进行测试。
  • 黑盒测试主要方法：等价类划分（如收费标准需使用各档值进行测试）、边界值分析（如收费标准各档的边界值）、错误推测、因果图
• 白盒测试：是借助程序内部的逻辑和相关信息，通过检测内部动作是否按照设计规格说明书的设定进行，检查每一条通路能否正常工作。白盒测试是从程序结构方面出发对测试用例进行设计。
  • 包括：基本路径测试、循环覆盖测试、逻辑覆盖测试
• 灰盒测试：介于黑盒与白盒测试之间，在内部结果出现错误，但输出结果正确的情况下可以采取灰盒测试方法。
• 自动化测试

4.4.2 测试阶段

• 单元测试：主要是对该软件的模块进行测试，通过测试以发现该模块的功能不符合/不满足期望的情
  况和编码错误。可以采用白盒测试和黑盒测试结合。
• 集成测试：一般采用白盒测试和黑盒测试结合。
  • 一次性组装
  • 增量式组装
• 系统测试：一般采用黑盒测试，以此来检查该系统是否符合软件需求。本阶段的主要测试内容包括功能测试、性能测试、健壮性测试、安装或反安装测试、用户界面测试、压力测试、可靠性及安全性测试等。
  • 性能测试：负载测试和压力测试都属于性能测试，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
  • 验收测试：验收测试是最后一个阶段的测试，通过了验收测试，该产品就可进行发布。测试人员还应进行Alpha测试（开放环境下测试）或Beta测试（实际上线后测试）。
  • 其他测试：
    • AB测试：是为Web或 App界面或流程制作两个 (A/B) 或多个 (A/B/n) 版本，在同一时间维度，分别让组成成分相同(相似)的访客群组(目标人群)随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。
    • Web测试：由于Web具有分布、异构、并发和平台无关的特性，因而它的测试要比普通程序
      复杂得多。
    • 链接测试：链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些未知地址页面的主要手段。
    • 表单测试：表单提交测试。
• 回归测试：功能变更，修改完成后的测试。
• 面向对象的测试
  • 算法层（单元测试）
  • 类层（模块测试）
  • 模版层／类树层（集成测试）
  • 系统层（系统测试）
• 自动化测试

软件调式

• 测试目的是找错误，调式目的是定位错误并修改错误。测试在前，调试在后。
• 软件调式方法：蛮力法（通过计算机找错误）、回溯法（从错误地方回找）、原因排除法

4.5 净室软件

净室 (Cleaning Room) 软件工程是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。净室方法不是先制作一个产品，再去消除缺陷，而是要求在规约和设计中消除错误，然后以“净”的方式制作，可以降低软件开发中的风险，以合理的成本开发出高质量的软件。
使用盒结构规约（或形式化方法）进行分析和设计建模，并强调正确性验证，而不是测试，作为发现和消除错误的主要机制。

4.5.1 理论基础

净室软件工程的理论基础主要是函数理论和抽样理论。

4.5.2 技术手段

• 1.统计过程控制下的增量式开发 (Incremental Development )
• 2.基于函数的规范与设计
• 3.正确性验证
• 4.统计测试 (Statistically Based Testing) 和软件认证

4.5.3应用与缺点

太理论化，需要更多的数学知识。其正确性验证的步骤比较困难且比较耗时。不进行传统的模块测试，这是不现实的。CSE毕竟脱胎于传统软件工程，不可避免地带有传统软件工程的一些弊端。

4.6 基于构件的软件工程

基于构件的软件工程 (Component-Based Software Engineering,CBSE) 是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。CBSE支持的“购买，而非建造”的思想。

4.6.1 构件和构件模型

可组装型、可部署性（构件总是二进制形式，无须在部署前编译）、文档化、独立性、标准化。
目前主流的构件模型是Web Services 模型、 Sun公司的EJB 模型和微软的.NET模型。

4.6.2 CBSE过程

(1)系统需求概览；
(2)识别候选构件；
(3)根据发现的构件修改需求；
(4)体系结构设计；
(5)构件定制与适配；
(6)组装构件，创建系统。

4.6.3构件组装

是用专门编写的“胶水代码”将它们整合。常见的组装构件有以下3种组装方式：顺序组装、层次组装、叠加组装。

4.7 软件项目管理

4.7.1项目管理概述

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员 (People)、 产品 (Product)、 过程 (Process) 和项目 (Project) 进行分析和管理的活动。

4.7.2 软件进度管理

在软件进度管理过程中，一般包括:活动定义、活动排序、活动资源估计、活动历时估计、制定进度计划和 进度控制。

• 工作分解结构 (Work Breakdown Structure,WBS)
  W B S 树形结构中最底层的被称为工作包，是最低层次的可交付成果，它应当由唯一主体负责完成。
• W B S常见的分解方式包括：按产品的物理结构分解、按产品或项目的功能分解、按照实施 过程分解、按照项目的实施单位分解、按照项目的目标分解、按部分或只能进行分解等。
• 任务分解的基本要求：
  (1) W B S 的工作包是可控和可管理的，不能过于复杂。
  (2)任务分解也不能过细，一般原则W B S的树形结构不超过6层。
  (3)每个工作包要有一个交付成果。
  (4)每个任务必须有明确定义的完成标准。
  (5)WBS必须有利于责任分配。
• 任务活动图
  通常采用甘特图等方式来展示和管理项目活动。

4.7.3 软件配置管理 (Software Configuration Management,SCM)

S C M活动的目标就是为了标识变更、控制变更、确保变更 正确实现并向其他有关人员报告变更。从某种角度讲， S C M 是一种标识、组织和控制修改的技 术，目的是使错误降为最小并最有效地提高生产效率。
软件配置管理核心内容包括版本控制和变更控制。

4.7.4软件质量管理

• 影响软件质量的因素：
  • 产品运行
  • 产品修改
  • 产品转移
• 软件质量保证主要任务：
  • SQA审计与评审
  • SQA报告
  • 处理不符合问题
• 软件质量认证主要采用的是：
  • ISO9000
  • 能力成熟度模型 (Capability Maturity Model,CMM)

4.7.5软件风险管理

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。
风险管理的主要目标是预防风险。
完。

---

2024-05-12
要点归纳

软件工程

一、软件危机

1. 软件开发进度难以预测。
2. 软件开发成本难以控制。
3. 软件功能难以满足用户期望。
4. 软件质量无法保证。
5. 软件难以维护。
6. 缺少文档资料。

二、软件过程模型（软件生命周期模型）

• 软件生命周期：需求分析、软件设计、软件开发、运行维护、淘汰。
• 软件过程模型
  1. 瀑布模型
     特点：前一阶段工作输出成果是下一阶段的输入。（是结构化开发方法使用的过程模型）
     缺点：需求难以一次确定、变更代价高、结果难以预测、各阶段工作不能并行。
  2. 原型模型
     特点：解决了瀑布模型的问题，根据需求快速开发出原型，用于需求沟通确认，迭代最终实现软件产品。分为：抛弃型和演化型。（是原型开发方法使用的软件过程模型）
  3. 螺旋模型
     特点：由瀑布模型和原型模型结合而来，将每个阶段都由：目标设定、风险分析、开发和有效性验证、评审4部分组成。强调“风险分析”。（适合于面向规格说明、面向过程、面向对象开发方法）
  4. 敏捷模型
     • 极限编程XP：高效、低风险、测试先行（先编测试代码再编写程序）。
     • 水晶系列方法：不同项目采取不同策略。
     • 并列争球法：将开发过程分成短的迭代周期，挑选最高优先级的。
     • 特征驱动开发方法：将开发人员分类。
  5. 软件统一过程模型RUP
     特点：用例驱动、以架构为中心、迭代和增量的软件开发过程。使用4+1视图描述架构：用例视图（中心）、逻辑视图（用户）、实现视图（开发视图，程序员）、进程视图（系统集成人员）、部署视图（系统工程师）。
• 软件能力成熟度模型CMM、CMMI
  成熟度等级：初始级、已管理级、已定义级、量化管理级、优化级。

需求工程

• 需求的3个层次：
  1. 业务需求：组织机构角度对系统产品高层次的目标要求。
  2. 用户需求：用户角度对系统产品的期望。业务需求和用户需求构成用户原始需求文档。
  3. 功能需求：从系统操作的角度定义了开发者必须实现的功能。
• 需求工程的5个阶段：
  1. 需求获取
  2. 需求分析
  3. 形成需求规格
  4. 需求确认与验证
  5. 需求管理
• 需求获取的基本步骤：
  1. 开发高层的业务模型
  2. 定义项目范围和高层需求
  3. 识别用户角色和用户代表
  4. 获取具体需求
  5. 确定目标系统的业务工作流
  6. 需求整理与总结
• 需求获取的方法：
  1. 用户面谈
  2. 需求专题讨论会
  3. 问卷调查
  4. 现场观察
  5. 原型化方法
  6. 头脑风暴法
• 软件需求规格说明书SRS
  包括：功能需求、非功能需求和约束，约束包括设计约束和过程约束，是需求开发和需求管理之间的桥梁。
• 需求管理
  包括：变更控制、版本控制、需求跟踪等活动。
• 需求变更
  1. 识别问题
  2. 问题分析和变更描述
  3. 变更分析和成本计算
  4. 变更实现
• 变更控制委员会CCB
  主要工作：通过评审的手段来决定是否能变更，但不提出变更方案。
  操作步骤：制定决策、交流情况、重新协商约定。
• 需求跟踪
  目标：建立与维护 “需求—设计—编程—测试” 之间的一致性，确保工作成果符合用户需求。

系统分析与设计

结构化方法 SASD

又称面向功能或面向数据流的软件开发方法，针对软件不同生命周期可分为：1.结构化分析、2.结构化设计、3.结构化编程。

1. 结构化分析

用图形表示用户需求中的功能需求，使用的手段主要有：数据流图DFD、数据字典、结构化语言、判定表、判定树。

• 结构化分析建模过程：
  1. 明确目标
  2. 确定系统范围
  3. 建立顶层DFD图
  4. 构建第一层DFD分解图
  5. 开发DFD层次结构图
  6. 检查确认DFD图
• 数据流图的4个基本元素：
  1. 数据流
  2. 处理加工
  3. 数据存储
  4. 外部项
• 数据流图需要满足的规则：
  1. 父图数据流必须在子图中出现
  2. 一个处理至少有一个输入流和输出流
  3. 一个存储必定有流入和流出
  4. 一个数据流至少有一端是处理端
  5. 模型表达信息是全面的、完整的、正确的、一致的
• 数据字典

2. 结构化设计

是一种面向数据流的设计方法，以SRS和SD阶段产生的数据流图和数据字典等文档为基础，是一个自顶向下、逐步求精、模块化的过程。

• SD分为：
  • 概要设计
    主要任务是：确定软件系统的结构，对系统进行模块划分，确定模块的功能、接口和模块之间的调用关系。
    概要设计使用系统结构图SC（模块结构图）来反映系统总体结构。
  • 详细设计
    主要任务是：为每个模块设计实现细节。
    详细设计使用图有：业务流图、程序流程图、问题分析图PAD、NS流程图等。
• 模块
  模块是实现功能的基本单位，具有功能、逻辑、状态3个属性。
  模块遵循：高内聚、低耦合原则。

3. 结构化编程

通过顺序、分支、循环构造。强调自顶而下逐步，清晰第一、效率第二、书写规范。原则：程序=算法+数据结构，以算法为主。

面向对象的方法 OO

面向对象的分析方法可分为：面向对象分析、面向对象设计、面向对象编程。

面向对象分析方法 OOA