计算机基础知识（第三篇）

计算机基础知识（第三篇）

软件工程

软件过程概述

软件开发生命周期

• 软件定义阶段：问题定义、可行性分析、需求分析
• 软件开发阶段：概要设计、详细设计、编码、测试
• 软件运行和维护阶段：软件交付、运行、维护

软件系统的文档

• 用户文档：包括用户手册、操作指南、帮助文档
• 系统文档：包括需求规格说明书、概要设计文档、详细设计文档、测试计划和报告

软件工程过程

• P(Plan)：软件规格说明。规定软件的功能及其运行时的限制。
• D(Do): 软件开发。开发出满足规格说明的软件。
• C(Check)：软件确认。确认开发的软件能够满足用户的需求。
• A(Action): 软件演进。软件在运行过程中不断改进以满足客户新的需求。

软件系统工具

• 软件开发工具：需求分析工具、设计工具、编码与排错工具、测试工具等。
• 软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
• 软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。

软件设计四个活动：数据设计、架构（体系结构）设计、人机界面（接口）设计和过程（功能）设计

软件工程生命周期：

• 可行性分析与项目开发计划：主要确定软件的开发目标及其可行性。
• 需求分析：确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型，该阶段产生的主要文档有软件需求说明书。
• 概要设计：概要设计就是设计软件的结构，明确软件由哪些模块组成，这些模块的层次结构、调用关系、功能是什么样的。设计该项目总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系。该阶段产生的主要文档有概要设计说明书。
• 详细设计：详细设计阶段的主要任务是把功能描述转变为精确的、结构化的过程描述。即该模块的控制结构是怎样的，先做什么，后做什么，有什么样的条件判定，有些什么重复处理等，并用相应的表示工具把这些控制结构表示出来。该阶段产生的主要文档有详细设计文档。
• 编码：编码阶段就是把每个模块的控制结构转换成计算机可接受的程序代码
• 测试：测试是保证软件质量，该阶段产生的主要文档有软件测试计划、测试用例和软件测试报告。
• 维护：软件维护是软件生存周期中时间最长的阶段。

软件成熟度模型

能力成熟度模型CMM

• 初始级：软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。
• 可重复级：建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。
• 已定义级：管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。
• 已管理级：制定了软件过程和产品质量的详细度量标准。
• 优化级：加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。

能力成熟度模型集成CMMI

• 初始级：过程不可预测且缺乏控制
• 已管理级：过程为项目服务
• 已定义级：过程为组织服务
• 定量管理：过程已度量和控制
• 优化级：集中于过程改进和优化

软件过程模型

瀑布模型

瀑布模型：将软件生存周期中的各个活动规定为依线性顺接的若干阶段的模型，包括需求分析、设计、编码、运行与维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水逐级下落。

特点：

• 阶段顺序性：开发过程按照固定的阶段顺序进行，每个阶段的输出作为下个阶段的输入，形成严格的线性流程。
• 逐步推进：每个阶段都有明确的工作内容和成果，开发团队逐步推进，直到完成整个软件开发过程。
• 输入输出清晰：每个阶段都有明确的输入和输出，使得开发过程可控，能够清晰地跟踪和管理项目进展。
• 评审和确认：在每个阶段末尾进行评审，确保工作成果符合要求和质量标准，只有经过确认的成果才能传递给下个阶段。
• 反馈和迭代：如果在评审中发现问题，需要及时反馈并进行修正。在极端情况下，可能需要返回前一阶段甚至更早的阶段进行修正。
• 成本控制：瀑布模型试图通过一次性完成各个阶段的工作来控制开发成本，尽量减少多个阶段间的反复，以较小的费用来开发软件。

V模型

V模型描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。V模型提供了一种将验证确认活动应用于早期软件工程工作中的方法。

左边的下画线分别代表了以下阶段：需求分析、概要设计、详细设计、编码

右边的上画线代表了以下测试类型：单元测试、集成测试、系统测试、验收测试

特点：

• 单元测试的主要目的是针对编码过程中可能存在的各种错误；
• 集成测试的主要目的是针对详细设计中可能存在的问题；
• 系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行；
• 验收测试通常由业务专家或者用户进行，以确认产品能真正符合用户业务上的需要；
• V模型适用于需求明确和需求变更不频繁的情形。

测试模型

W模型的定义：W模型是对V模型的一种改进。W模型中，软件开发和测试是紧密结合的，每个开发活动完成后就同步进行测试活动：需求分析完成后进行需求测试；设计完成后进行设计测试；编码完成后进行单元测试；集成完成后进行集成测试；系统构建完成后进行系统测试；完成交付准备工作之后进行验收测试。(w模型也叫双v模型）

W模型的缺点：W模型中开发活动都是串行的，开发和测试也是一种线性的关系，只有开发活动完成了才能进行测试活动。这种方式使得W模型无法适应敏捷、迭代开发，以及灵活的变更调整。

H模型的定义：H模型中的测试活动是一个独立的流程，只要满足了测试就绪条件，就可以开始测试活动。这种灵活的组织方式，使得H模型完全具备了前两个模型的优点：既可以与所有的开发活动紧密结合，又足够灵活满足敏捷和迭代的开发模型。

W模型的缺点：H模型的灵活也造就它难以驾驭的特点。如果管理者没有足够的经验就实施H模型，可能会事倍功半，测试活动的成本收益比会比较低。

总结：根据以上测试3种模型的特点，建议一般的软件开发过程采用W模型，实施敏捷和迭代开发的可以考虑采用H 模型。

增量模型

增量模型将需求分段为一系列增量产品，每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的"增量"，第1个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

特点：

• 首先开发核心模块功能：采用增量模型时，首先着重开发系统的核心功能和基本特性，以满足最基本的需求。
• 与用户确认：每个增量开发完成后，与用户进行确认，确保用户满意度，并根据反馈进行调整和改进。
• 逐步完善功能：在用户确认后，继续开发次要的核心模块功能，逐步完善系统的功能和特性。
• 每次开发一部分功能：增量模型采取逐步迭代的方式进行开发，每次只开发系统的一部分功能，使得开发过程更为可控。
• 优先级最高的服务最先交付：根据用户需求的优先级，优先开发优先级最高的功能，以尽快满足用户需求。

原型化模型

演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。典型的演化模型有原型模型和螺旋模型等。

原型模型开始于沟通，其目的是定义软件的总体目标，标识需求，然后快速制订原型开发的计划，并构建原型。交付给客户使用，并收集客户的反馈意见，这些反馈意见可在下一轮中对原型进行改进。

特点：

• 原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型
• 原型方法比较适合于用户需求不清、需求经常变化的情况
• 构造方便、快速，造价低。对用户的需求是动态响应、逐步纳入的，不适合大型项目

螺旋模型

螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。在螺旋模型中，软件开发是一系列的增量发布。

四个阶段

• 制订计划：在这个阶段，确定项目的目标、约束条件、资源需求等，制定项目计划和进度安排。
• 风险分析：在这个阶段，对项目可能面临的风险进行分析和评估，确定可能存在的问题并提出解决方案。
• 实施工程：在这个阶段，进行系统的设计、开发、测试和部署工作，按照计划和风险分析的结果执行项目任务。
• 客户评估：在这个阶段，与客户进行沟通和评估，收集反馈意见并进行改进，以确保系统满足用户需求和期望。

螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。通过周期性的重复和风险分析，螺旋模型能够在项目开发过程中及时识别和解决问题，降低项目失败的风险，并确保项目按时交付并满足用户需求。

形式化方法模型

形式化方法模型是一种软件工程方法，它采用数学和形式化技术来进行软件开发、验证和验证。形式化方法的核心思想是通过数学逻辑、形式化规约和严格的推理来确保软件系统的正确性和可靠性。这些方法通常适用于对软件系统进行严格的规约和证明，尤其是对于安全关键系统和高可靠性系统的开发。

特点：数学基础、形式化规约、形式化验证、严格推理、高可靠性、复杂性管理

喷泉模型

喷泉模型是一种软件开发模型，也被称为喷泉开发模型或者逐步增量模型。它是增量模型的一种变体，强调了开发过程的逐步演化和持续改进。与传统的瀑布模型相比，喷泉模型更加灵活和迭代，注重快速交付部分功能，并在每个阶段不断迭代和改进。

特点：

• 阶段交叠：不同于瀑布模型的线性顺序，喷泉模型的各个阶段可以部分交叠，使得开发过程更加迭代和灵活。
• 逐步交付：喷泉模型强调逐步交付软件的部分功能，每个增量都是可运行的软件版本，可以及时满足用户的需求。
• 持续改进：在喷泉模型中，开发团队通过不断的迭代和反馈，持续改进软件产品，以适应用户需求的变化和不断提升产品质量。
• 用户参与：喷泉模型鼓励用户在开发过程中参与，并及时提供反馈意见，以确保最终交付的产品符合用户期望。
• 风险管理：喷泉模型重视风险管理，通过及时的风险评估和控制，降低项目失败的风险，并提高项目的成功率。

统一过程模型(RUP)

RUP把软件开发生命周期划分为多个循环，每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段组成，
每个阶段完成确定的任务。这4个阶段如下。

• 初始阶段：定义最终产品视图和业务模型，并确定系统范围。
• 细化阶段：设计及确定系统的体系结构，制订工作计划及资源要求。
• 构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交．
• 移交阶段：把产品提交给用户使用

9个核心工作流程：

1. 业务建模：理解待开发系统所在机构的商业运作，评估待开发系统对机构的影响。
2. 需求：定义系统功能及用户界面，为项目预算和计划提供基础。
3. 分析与设计：将需求分析结果转化为分析与设计模型。
4. 实现：将设计模型转换为实现结果，集成为可执行系统。
5. 测试：验证需求是否被正确实现，发现并归档软件质量上的缺陷。
6. 部署：打包、分发、安装软件，升级旧系统，培训用户并提供技术支持。
7. 配置与变更管理：跟踪和维护系统开发过程中产生的所有制品的完整性和一致性。
8. 项目管理：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
9. 环境：为软件开发机构提供软件开发环境，提供过程管理和工具的支持。

特点：

• 用例驱动：需求分析、设计、实现和测试等活动都是以用例为中心进行驱动的。
• 以体系结构为中心：包括系统的总体组织和全局控制、通信协议等。体系结构是一个多维的结构，采用多个视图来描述。
• 迭代与增量：将整个项目开发分为多个迭代过程。每次迭代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程。每次迭代是在已完成部分的基础上进行的，每次增加一些新的功能实现，直至最终完成项目。

4+1 视图模型：

• 分析人员和测试人员关心系统的行为，侧重于用例视图；
• 最终用户关心系统的功能，侧重于逻辑视图；
• 程序员关心系统的配置、装配等问题，侧重于实现视图；
• 系统集成人员关心系统的性能、可伸缩性、吞吐率等问题，侧重于进程视图；
• 系统工程师关心系统的发布、安装、拓扑结构等问题，侧重于部署视图。

敏捷模型

敏捷开发的总体目标是通过"尽可能早地、持续地对有价值的软件的交付"使客户满意。通过在软件开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变需求。

敏捷过程的典型方法有很多，实现了敏捷方法所宣称的理念就称之为敏捷宣言。

敏捷宣言：个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。

核心思想：

• 敏捷方法是适应型，而非可预测型。
• 敏捷方法是以人为本，而非以过程为本。
• 以原型开发思想为基础，采用增量式开发，发行版本小型化。

主要的敏捷方法：

极限编程(XP)：

基础和价值观：交流、朴素、反馈和勇气。
核心理念：任何软件项目都可以通过加强交流、从简单做起、寻求反馈和勇于实事求是进行改善。
开发方法：采用近螺旋式的开发方法，将复杂的开发过程分解为相对简单的小周期。通过积极的交流、反馈等方法，开发人员和客户可以清楚了解开发进度、变化、待解决的问题和潜在的困难，并及时调整开发过程。
测试先行：XP提倡测试先行，以降低后续出现bug的几率。

水晶系列方法：

以人为中心，提倡“机动性的”方法。包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。

并列争球法(Scrum)：

迭代的增量化过程，将每段时间（如30天）划分为一个个“冲刺(Sprint)”。按需求的优先级别来实现产品，多个自组织和自治的小组并行地递增实现产品。

特性驱动开发方法(FDD)：

认为有效的软件开发需要人、过程和技术三个要素。包含5个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。

逆向工程

软件复用：

软件复用是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。

逆向工程：软件的逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。

逆向工程的四个级别：

• 实现级：包括程序的抽象语法树、符号表、过程的设计表示。
• 结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。
• 功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型。
• 领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如E-R模型。

其中，领域级抽象级别最高，完备性（完整）最低，实现级抽象级别最低，完备性最高。

重构：

重构是指通过改变程序的内部结构，以改进其设计、可读性、可维护性和性能，而不改变其外部行为。重构可以通过重新组织代码、简化算法、消除重复等方式来改善程序的质量和结构。

设计恢复：

设计恢复是指通过对已有软件系统的逆向工程分析，还原出其设计和结构。这可以帮助我们理解现有系统的组织方式、模块之间的关系以及它们之间的交互。

再工程：

再工程是指对现有软件系统进行重构、改进和现代化，以满足新的需求、提高性能或增强可维护性等方面的要求。是在逆向工程所获得信息的基础上，修改或重构已有的系统，产生系统的一个新版本。

正向工程：

正向工程是指将软件设计的高级概念和抽象转化为实现代码的过程。它是逆向工程的相反过程，不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统。

需求工程

软件需求：指用户对系统在功能、行为、性能、设计约束等方面的期望。是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

需求分类：

• 书本上的分类：功能需求、性能需求、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密要求、可靠性要求、成本消耗和开发进度需求、其他非功能性需求

• 常见的分类：

  业务需求：企业或客户对系统高层次的目标要求

  用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么

  系统需求：从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等

需求开发：需求获取、需求分析、需求定义、需求验证

需求管理：变更控制、版本控制、需求跟踪、需求状态跟踪

需求获取：

常见的需求获取法包括：

• 用户访谈：1对1-3，找有代表性的用户进行访谈，对提问者的水平是有要求的。其形式包括结构化（有剧本）和非结构化（随意发挥）两种。
• 问卷调查：用户多，无法一一访谈，收集到的需求不够精准，比较杂乱，比较考验问卷编写者的水平
• 采样：从种群中系统地选出有代表性的样本集的过程，类似于数学中的数理统计。样本数量＝0.25*（可信度因子／错误率)2
• 情节串联板：一系列图片，通过这些图片来把需求给进行叙述出来，这样虽然生动，但是耗时
• 联合需求计划（JRP)：通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。
• 需求记录技术：任务卡片、场景说明、用户故事、Volere白卡

需求分析：

一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

常见的需求分析任务包括：

• 绘制系统上下文范围关系图（数据流图）
• 创建用户界面原型· 分析需求的可行性
• 确定需求的优先级
• 为需求建立模型
• 创建数据字典
• 使用QFD(QFD：质量功能部署，把需求和QFD进行关联）

结构化的需求分析：

结构化特点：自顶向下，逐步分解，面向数据。

三大模型：功能模型(数据流图)、行为模型(状态转换图)、数据模型(E-R图)以及数据字典。

数据流图

基本图形元素：外部实体、加工、数据存储、数据流

数据流：由一组固定成分的数据组成，表示数据的流向。在DFD中，数据流的流向必须经过加工。

加工：描述了输入数据流到输出数据流之间的变换，数据流图中常见的三种错误如图所示：

• 加工3.1 .2有输入但是没有输出，称之为“黑洞”
• 加工3.1 .3有输出但没有输入。称之为“奇迹”。
• 加工3.1 .1 中输入不足以产生输出，我们称之为“灰洞”。

数据字典DD

数据流图描述了系统的分解，但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明，即为了描述数据流图的。

数据字典有以下4类条目：数据流、数据项、数据存储和基本加工。（注意这里没有描述外部实体，因为外部实体不是系统内部的内容）

加工逻辑也称为“小说明”。常用的加工逻辑描述方法有结构化语言、判定表和判定树3种。

需求定义：

需水定义（软件需求规格说明书SRS)：是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。

需求定义方法：

• 严格定义也称为预先定义（结构化定义），需求的严格定义建立在以下的基本假设之上：所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形（或文字）可以充分体现最终系统，适合需求明确的情况。
• 原型方法，迭代的循环型开发方式，需要注意的问题：并非所有的需求都能在系统开发前被准确地说明。项目干系人之间通常都存在交流上的困难，原型提供了克该服困难的一个手段。特点：需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

需求定义方法，可以确保在软件开发过程中，需求明确、项目干系人理解一致，为开发团队提供清晰的工作基础，从而保障软件项目的顺利开展。

需求验证：

需求验证，也称为需求确认，旨在与用户一同确认需求的准确性，评审和测试需求规格说明书(SRS)。该过程包括以下两个步骤：

• 需求评审：分为正式评审和非正式评审。
• 需求测试：设计概念测试用例和场景，用以测试需求，不牵涉到编写代码。

一旦需求验证通过，需要邀请用户签字确认，作为验收标准之一。此时，需求规格说明书成为需求基线，不得随意更新。若需更改，必须经过需求变更流程。通过需求验证确保了软件开发过程中需求的准确性和一致性，为后续开发工作提供了稳定的基础。

需求管理：

定义需求基线：通过了评审的需求说明书就是需求基线，下次如果需要变更需求，就需要按照流程来一步步进行。

需求跟踪：

需求跟踪是编制每个需求与系统元素之间联系的文档，又称为双向跟踪。它包括两种方式：

1. 正向跟踪：用于确认用户原始需求是否全部实现，以判断产品是否存在遗漏。
2. 反向跟踪：用于验证软件实现是否符合用户需求，不多不少。

使用方式：

• 正向跟踪：若原始需求和用例对应，打上对号；若某行无对号，表示原始需求未实现，存在问题。
• 反向跟踪：若某列无对号，说明有多余功能用例，软件实现了多余功能，需要审查。

通过需求跟踪，可以确保软件开发过程中的需求与实现之间的对应关系清晰明了，帮助团队确保产品开发的准确性和完整性，同时避免遗漏或过度实现的问题。

业务流程设计

程序流程图是一种图形化的工具，用于描述和表示程序或系统中各个步骤之间的逻辑关系和顺序。它通过使用特定的符号和连接线，直观地展示了程序的操作流程、决策点和数据流动，使得复杂的程序逻辑变得易于理解和分析。

特点：

• 可视化：将复杂的程序逻辑以图形方式展示，易于理解和交流。
• 系统分析：帮助程序员和系统分析师发现和解决程序中的逻辑错误和缺陷。
• 文档化：作为程序设计和维护的文档，提高程序的可读性和可维护性。

程序流程图广泛应用于软件开发、系统设计和流程管理等领域，通过清晰直观的方式帮助团队成员和利益相关者理解和优化工作流程。

IPO图是一种用于描述和分析系统或过程的工具，通过明确输入（Input）、处理（Process）和输出（Output）三个基本要素，帮助理解和设计系统或流程的运作方式。IPO图常用于系统分析、程序设计和流程改进等领域，以简洁的方式展示信息流和操作步骤。

三个基本要素：输入、处理、输出

特点：

• 简单明了：以直观的方式展示系统或过程的基本构成，便于理解和交流。
• 结构清晰：清楚地分离输入、处理和输出，有助于分析和设计系统。
• 易于使用：适用于各种复杂程度的系统或过程，从简单的程序到复杂的业务流程均可使用。

应用场景：系统分析和设计、程序设计、流程改进

N-S图是一种用于表示程序设计的图形化工具。它通过使用嵌套的矩形框表示程序的结构和控制流，以便于理解和维护。N-S图是一种结构化编程的工具，主要用来表示顺序、选择和循环等基本结构。虽然比较容易表示嵌套和层次关系，并具有强烈的结构化特征。但
是当问题很复杂时，N-S图可能很大，因此不适合于复杂程序的设计。

基本元素：顺序结构、选择结构、循环结构

特点：

• 清晰的结构表示：通过嵌套的矩形框直观地展示程序的控制流和逻辑结构，有助于理解程序的整体结构。
• 支持结构化编程：符合结构化编程的原则，便于维护和修改代码。
• 易于转换为代码：图形化的表示方式便于直接转换为编程语言的代码。

应用场景：程序设计和文档、教学工具、代码审查和优化

问题分析图 是一种图形化工具，用于表示程序设计中的控制结构和操作步骤。PAD图帮助程序员和系统分析师更直观地理解和设计复杂的程序流程，特别适用于结构化编程。PAD图的主要目的是通过分层的方式展示程序的逻辑结构，便于分析和维护。

基本元素：操作、条件、循环

业务流程设计分类

业务流程管理BPM

是一种方法论，用于优化、管理和自动化组织内的业务流程。它涉及识别、建模、分析和优化业务流程，以实现更高效、灵活和协调的运作。BPM关注整个业务流程的管理，包括流程的执行、监控、优化和自动化。

业务流程重组BPR

BPR是更为激进的方法，它着眼于对现有业务流程进行彻底的重新设计和改造，以实现质的飞跃的改进，是对企业的业务流程进行根本性的再思考和彻底性的再设计，从而获得可以用诸如成本、质量、服务和速度等方面的业绩来衡量的显著性的成就。

系统设计

基本原理

• 抽象化：将复杂的问题分成更小、更易管理的部分。
• 自顶而下，逐步求精：从整体框架入手，然后逐步添加细节。
• 信息隐蔽：隐藏复杂的内部细节，只暴露必要的信息给其他部分。
• 模块独立（高内聚，低耦合）：每个模块都有自己的功能，并且尽可能不依赖其他模块。

模块的设计要求独立性高，就必须高内聚，低耦合

• 内聚：是指一个模块内部功能之间的相关性
• 耦合：是指多个模块之间的联系

内聚程度从低到高：

• 偶然内聚：一个模块内的各处理元素之间没有任何联系
• 逻辑内聚：模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能
• 时间内聚：把需要同时执行的动作组合在一起形成的模块
• 过程内聚：一个模块完成多个任务，这些任务必须按指定的过程程序执行
• 通信内聚：模块内的所有处理元素都在同一个任务
• 顺序内聚：一个模块中各个处理元素都密切相关同一功能且必须顺序执行，前一个功能元素的输出就是下一个功能元素的输入
• 功能内聚：最强的内聚，模块内的所有单元共同作用完成一个功能，缺一不可

耦合程度从低到高：

• 无直接耦合：两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，不传递任何信息
• 数据耦合：两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递
• 标记耦合：两个模块之间传递的是数据结构
• 控制耦合：一个模块调用另一个模块时，传递的是控制变量
• 外部耦合：模块间通过软件之外的环境联合
• 公共耦合：通过一个公共数据环境相互作用的那些模块间的耦合
• 内容耦合：当一个模块直接使用另一个模块的内部数据。或通过非正常入口转入另一个模块内部时

概要设计

1. 系统总体结构设计：基本任务是采用某种设计方法，将一个复杂的系统按功能划分成模块、确定每个模块的功能、确定模块之间的调用关系、确定模块之间的接口，即模块之间传递的信息、评价模块结构的质量
2. 数据结构及数据库设计：数据结构的设计、数据库的设计
3. 编写概要设计文档：主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划
4. 评审：对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审

详细设计

1. 对每个模块进行详细的算法设计，用某种图形、表格和语言等工具将每个模块处理过程的详细算法描述出来。（流程图、IPO图、N-S图、PAD图）
2. 对模块内的数据结构进行设计
3. 对数据库进行物理设计，即确定数据库的物理结构
4. 其他设计。根据软件系统的类型，还可能要进行以下设计：代码设计、输入输出格式设计、用户界面设计
5. 编写详细设计说明书
6. 评审

人机界面设计

三大黄金原则

• 置于用户控制之下：确保用户对系统操作具有充分的控制权，使用户感觉自己在掌控整个交互过程
• 减少用户的记忆负担：设计应尽量减少用户需要记忆的信息量，使用户能够专注于当前任务而无需记忆过多的步骤或数据
• 保持界面的一致性：在界面设计中保持视觉和交互的一致性，使用户能够建立对系统的预期，减少学习成本和操作错误

软件测试

系统测试：为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。

测试原则：

• 应尽早并不断的进行测试，比如V模型，从设计的时候就开始测试；
• 测试工作应该避免由原开发软件的人或小组承担；
• 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期的输出结果；
• 既包含有效、合理的测试用例，也包含不合理、失效的用例；
• 检验程序是否做了该做的事，且是否做了不该做的事；
• 严格按照测试计划进行；
• 妥善保存测试计划和测试用例；
• 测试用例可以重复使用或追加测试。

软件测试方法：静态测试、动态测试

静态测试

静态测试指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试包括对文档和代码的静态测试，具体方法包括桌前检查、代码审查和代码走查。这种方法能够有效地发现30%-70%的逻辑设计和编码错误。

桌前检查：在你自己编写代码后，你会进行桌前检查，这意味着你会仔细查看你的代码，以捕捉可能的错误、逻辑问题或风格不一致之类的问题。这是一种个人层面的检查，有助于在代码提交前修复问题。代码审查：代码审查是团队中的成员一起对某个人编写的代码进行检查。通过代码审查，团队可以共同评估代码的质量，发现潜在的问题，并确保代码符合团队的标准和最佳实践。这有助于提高代码的稳定性和可维护性。

代码走查：代码走查是一种更广泛的审查实践，通常包括团队的开发人员、测试人员和其他相关人员。在代码走查过程中，团队会深入检查代码的各个方面，包括逻辑、性能、安全性等。目标是确保代码在整体上是健壮、高效且符合预期要求的。

动态测试：

是指在计算机上实际运行程序进行软件测试。常用的测试方法包括白盒测试、黑盒测试、灰盒测试和自动化测试。

黑盒测试：关注于测试软件的功能（功能性测试），而不考虑内部实现细节，测试人员不需要知道代码的具体结构，而是根据软件的需求规格和功能来设计测试用例。这种方法类似于将测试人员置于一个"盒子"外，只观察软件的输入和输出，以确定是否按预期工作。

举例：假设你正在测试一个在线登录系统。对于黑盒测试，你会设计测试用例，包括输入不同的用户名和密码组合，然后观察系统的响应，验证是否成功登录、失败登录是否有适当的错误提示等，而不考虑系统内部的代码结构。

白盒测试：白盒测试关注于测试软件的内部逻辑和代码结构（结构性测试），以确保代码按照预期方式执行。测试人员需要了解软件的代码，以设计测试用例，以覆盖不同的代码路径和分支情况，以及验证代码是否满足质量标准和最佳实践。

举例：假设你正在测试一个计算器应用。对于白盒测试，你会检查代码，确保加法、减法、乘法和除法等操作都正确实现。你可能会编写测试用例，测试各种输入情况，例如测试正数、负数、小数等，以确保代码在不同情况下都能正确执行。

测试阶段：

单元测试：

• 也称为模块测试、算法测试。
• 测试的对象是可独立编译或汇编的程序模块、软件构件或OO软件中的类（统称为模块）。
• 测试依据是软件详细设计说明书。
• 侧重于测试模块中的内部逻辑和数据结构。
• 一般会采用白盒测试。

集成测试：

• 目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。
• 测试依据是软件概要设计文档。

系统测试：

• 测试对象是完整的、集成的计算机系统；
• 测试的目的是在真实系统工作环境下，验证完成的软件配置项能否和系统正确连接，并满足系统／子系统设计文档和软件开发合同规定的要求。
• 测试依据是用户需求或开发合同。
• 主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等，其中，最重要的工作是进行功能测试与性能测试。
• 系统测试通常由独立的测试团队执行，他们并不直接参与软件的开发过程。

确认测试：

• 主要用于验证软件的功能、性能和其他特性是否与用户需求一致。
• 测试依据是需求文档，确认测试是软件或产品开发的最后一个阶段，在系统测试完成后进行。
• 主要目标是确保软件或产品已经满足最终用户的期望和需求。
• 在确认测试中，最终用户（或其代表）将根据他们的实际使用情境，验证软件是否符合他们的业务流程和预期目标根据用户的参与程度，通常包括以下类型：内部确认测试、Alpha测试、Beta测试、验收测试。

回归测试：

• 测试目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性（不能把其他好的模块改错）。

测试用例的设计：

黑盒测试用例

等价类划分：等价类划分是一种通过将输入值分成不同类别，从而减少测试用例数量，同时确保测试覆盖各种可能情况的方法。

边界值分析：边界值分析通过测试输入数据的边界值，验证系统在边界条件下的行为是否正确。

错误推测：错误推测基于经验和直觉来推测可能产生问题的地方，并设计相应的测试用例。

因果图分析：因果图分析通过分析输入条件（原因）和输出结果（结果）之间的逻辑关系来设计测试用例。

通过使用等价类划分、边界值分析、错误推测和因果图分析等方法，可以有效地设计黑盒测试用例，确保系统在各种输入情况下的正确性和稳定性。这些方法不仅可以提高测试效率，还可以确保测试覆盖全面，有助于发现潜在的系统问题。

白盒测试用例

语句覆盖SC：逻辑代码中的所有语句都要被执行一遍，覆盖层级最低，因为执行了所有的语句，不代表执行了所
有的条件判断。

判定覆盖DC：逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。

条件覆盖CC：针对每一个判断条件内（比如一个if）的每一个独立条件（if中的每个判定条件）都要执行一遍真和假。

条件判定组合覆盖CDC：同时满足判定覆盖和条件覆盖。

路径覆盖：逻辑代码中的所有可行路径都覆盖了，覆盖层级最高。

调试

测试与调试

• 测试：旨在发现软件中的错误。
• 调试：找出错误的代码和原因，并进行修正。
• 调试步骤：确定错误位置、分析原因、回归测试
• 调试方法：蛮力法、回溯法、原因排除法

软件属性

• 外部属性：面向管理者和用户的属性，可直接测量。例如性能指标。
• 内部属性：软件产品本身的属性，如可靠性等。只能间接测量。

McCabe度量法：又称为环路复杂度，用于度量程序的复杂度。

计算公式：( V(G) = m - n + 2 )

• ( m )：有向图中的有向边数。
• ( n )：有向图中的节点数。

系统维护

系统转换是指新系统开发完毕，投入运行，取代现有系统的过程，需要考虑多方面的问题，以实现与老系统的交接，有以下三种转换计划：

• 直接转换：现有系统被新系统直接取代了，风险很大，适用于新系统不复杂，或者现有系统已经不能使用的情况。优点是节省成本，只适合小系统。
• 并行转换：新系统和老系统并行工作一段时间，新系统经过试运行后再取代，若新系统在试运行过程中有问题，也不影响现有系统的运行，风险极小，在试运行过程中还可以比较新老系统的性能，适用于大型系统。缺点是耗费人力和时间资源，难以控制两个系统间的数据转换。
• 分段转换：分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每个子系统，成熟一个子系统，就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题。

数据转换与迁移：将数据从旧数据库迁移到新数据库中。有三种方法：系统切换前通过工具迁移、系统切换前采用手工录入、系统切换后通过新系统生成。

系统维护是整个系统开发过程中耗时最长的，系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度，其评价指标如下：

• 易分析性。软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。
• 易改变性，软件产品使指定的修改可以被实现的能力，实现包括编码、设计和文档的更改。
• 稳定性。软件产品避免由于软件修改而造成意外结果的能力。
• 易测试性。软件产品使已修改软件能被确认的能力。

系统维护包括硬件维护、软件维护和数据维护，其中软件维护类型如下：

• 正确性维护：发现了bug而进行的修改。
• 适应性维护：由于外部环境发生了改变，被动进行的对软件的修改和升级。
• 完善性维护：基于用户主动对软件提出更多的需求，修改软件，增加更多的功能，使其比之前的软件功能、性能更
  高，更加完善。
• 预防性维护：对未来可能发生的问题进行预防性的修改。

遗留系统

遗留系统是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统。这类系统通常具有以下特点：

1. 功能上的局限性：系统虽然完成企业中许多重要的业务管理工作，但仍然不能完全满足要求。
2. 技术上的落后：系统在性能上已经落后，采用的技术已经过时。
3. 规模和复杂性：通常是大型的软件系统，已经融入企业的业务运作和决策管理机制之中，维护工作十分困难。
4. 缺乏现代管理和开发方法：没有使用现代信息系统建设方法进行管理和开发。

净室软件工程

是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达的零缺陷或接近零缺陷，强调的是预防大于检查。净室方法不是先制作一个产品，再去消除缺陷，而是要求在规约和设计中消除错误，然后以"净"的方式制作，可以降低软件开发中的风险，以合理的成本开发出高质量的软件。

在净室软件工程背后的哲学是：通过在第1次正确地书写代码增量，并在测试前验证它们的正确性，来避免对成本很高的错误消除过程的依赖。它的过程模型是在代码增量积聚到系统的过程的同时，进行代码增量的统计质量验证。它甚至提倡开发者不需要进行单元测试，而是进行正确性验证和统计质量控制。

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

净室软件工程应用技术手段：

• 统计过程控制下的增量式开发。
• 基于函数的规范与设计。
• 正确性验证（CSE的核心）
• 统计测试和软件认证。

净室软件工程在使用过程的一些缺点：

• CSE太理论化，需要更多的数学知识，其正确性验证的步骤比较困难且比较耗时，
• CSE开发小组不进行传统的模块测试，这是不现实的。
• CSE也会带有传统软件工程的一些弊端。

基于构件的开发模型CBSD

基于构件的软件开发模型（Component-Based Software Development，CBSD）是一种软件开发方法，它将软件系统划分为多个可重用的、独立的构件（也称为组件），并通过组合这些构件来构建整个系统。

特点：

• 构件化： 软件系统被分解为多个独立的构件，每个构件都是可重用的、具有特定功能的单元。这些构件可以是现有的组件库中的标准构件，也可以根据项目需求定制开发的。
• 组装： 开发过程中，通过组装这些独立的构件来构建整个系统。构件之间通过定义好的接口进行交互，使得系统具有灵活性和可扩展性。
• 重用： CBSD鼓励最大限度地重用已有的构件，从而提高开发效率和软件质量。通过构件的重用，可以减少开发时间和成本，并降低开发过程中的风险。
• 独立开发和维护： 每个构件都是独立开发和维护的，开发团队可以专注于构件的功能和实现细节，而不必关注整个系统的复杂性。
• 标准化接口： 构件之间通过标准化的接口进行通信和交互，使得构件可以被灵活地替换和升级，而不影响整个系统的稳定性和功能。
• 快速开发和迭代： CBSD支持快速的软件开发和迭代，可以根据需求动态地添加、修改或删除构件，从而更好地满足用户的需求和变化。

基于构件的软件工程CBSE

基于构件的软件工程（Component-Based Software Engineering, CBSE）是一种基于分布对象技术的方法，强调通过可复用构件设计与构造软件系统。CBSE体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于已有构件的组装。

用于CBSE的构件应该具备以下特征：

• 可组装型：对于可组装的构件，所有外部交互必须通过公开定义的接口进行，同时它还必须对自身信息的外部访问。
• 可部署性：软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行，构件总是二进制形式，无须在部署前编译。
• 文档化：构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。
• 独立性：构件应该是独立的，应该可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供服务，则应显示声明。
• 标准化：构件标准化意味着在CBSE过程中使用的构件必须符合某种标准化的构件模型。构件模型定义了构件实现、文档化以及开发的标准，其包含的模型要素为：接口、使用信息、部署。

构件模型包含以下要素：

• 接口：构件通过构件接口来定义，构件模型规定应如何定义构件接口以及在接口定义中应该包含的要素，如操作名、参数以及异常等。
• 使用信息：为使构件远程分布和访问，必须给构件一个特定的、全局唯一的名字或句柄，构件元数据是构件本身相关的数据，比如构件的接口和属性信息。
• 部署：构件模型包括一个规格说明，指出应该如何打包构件使其部署成为一个独立的可执行实体，部署信息中包含有关包中内容的信息和它的二进制构成的信息。

被构件使用的通用服务

• 平台服务，允许构件在分布式环境下通信和互操作。
• 支持服务，这是很多构件需要的共性服务。例如，构件都需要的身份认证服务、需要GPS服务之类。
• 中间件实现共性的构件服务，并提供这些服务的接口。

CBSE过程是支持基于构件组装的软件开发过程，过程中的6个主要活动：系统需求概览、识别候选构件、根据发现的构件修改需求、体系结构设计、构件定制与适配、组装构件创建系统。

CBSE过程与传统软件开发过程不同点：

• CBSE早期需要完整的需求（即需求明确），以便尽可能多地识别出可复用的构件。
• 在过程早期阶段根据可利用的构件来细化和修改需求。如果可利用的构件不能满足用户需求，就应该考虑由复用构件支持的相关需求。
• 在系统体系结构设计完成后，会有一个进一步的对构件搜索及设计精化的活动，可能需要为某些构件寻找备用构件，或者修改构件以适合功能和架构的要求。
• 开发就是将已经找到的构件集成在一起的组装过程。

构件组装是指构件相互直接集成或是用专门编写的"胶水代码"将它们整合在一起来创造一个系统或另一个构件的过程。常见的组装构件有以下3种组装方式：

• 顺序组装：通过按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件。如上一个构件输出作为下一个构件的输入。
• 层次组装：这种情况发生在一个构件直接调用自另一个构件所提供的服务时。被调用的构件为调用的构件提供所需的服务。二者之间接口匹配兼容。
• 叠加组装：这种情况发生在两个或两个以上构件放在一起来创建一个新构件的时候。这个新构件合并了原构件的功能，从而对外提供了新的接口。外部应用可以通过新接口来调用原有构件的接口，而原有构件不互相依赖，也不互相调用。这种组装类型适合于构件是程序单元或者构件是服务的情况。

构件组装的三种不兼容问题（通过编写适配器解决）:

• 参数不兼容。接口每一侧的操作有相同的名字，但参数类型或参数个数不相同。
• 操作不兼容，提供接口和请求接口的操作名不同。
• 操作不完备。一个构件的提供接口是另一个构件请求接口的一个子集，或者相反。

面向对象开发

概念

对象：基本的运行实体，为类的实例，封装了数据和行为的整体，如学生、汽车等真实存在的实体。对象具有清晰的边界、良
好定义的行为和可扩展性。

消息：对象之间进行通信的一种方式称为消息。

类：是对象的抽象，定义了一组大体相似的对象结构，定义了数据和行为。

• 实体类：表示系统中的业务数据及其相关操作，通常对应现实世界中的实体对象，比如书本，人。
• 边界类：作为系统与外部世界（如用户界面、外部系统）之间交互的接口，比如用户界面。
• 控制类：负责实现系统的业务逻辑，处理数据流和控制应用程序的流程，比如用户认证。

继承：父类和子类之间共享数据和方法的机制，是类与类之间的一种关系。

多态：通俗来说，就是多种形态，具体点就是去完成某个行为，当不同的对象去完成时会产生出不同的状态。在编程语言和类型论中，多态指为不同数据类型的实体提供统一的接口，多态由继承机制支持。包括以下四种多态：

• 参数多态：不同类型参数多种结构类型
• 包含多态：父子类型关系
• 过载多态：类似于重载，一个名字不同含义
• 强制多态：强制类型转换

覆盖（重写）：子类在原有父类接口的基础上，用适合于自己要求的实现去置换父类中的相应实现。即在子类中重定义一个与父类同名同参的方法。

重载：与覆盖要区分开，函数重载与子类父类无关，且函数是同名不同参数。

封装：一种信息隐蔽技术，其目的是使对象的使用者和生产者分离，也就是使其他开发人员无需了解所要使用的软件组件内部的工作机制，只需知道如何使用组件。

绑定：是一个把过程调用和响应调用所需要执行的代码结合的过程。在一般的程序设计语言中，绑定可以是静态绑定（在编译时进行）或动态绑定（在运行时进行）。静态绑定在编译时确定调用的具体代码，而动态绑定则在运行时根据对象的实际类型确定调用的代码。

• 静态绑定是基于静态类型（类型在编译时就确定），在程序执行前方法已经被绑定；
• 动态绑定是基于动态类型（类型在运行时才能确定），运行时根据变量实际引用的对象类型决定调用哪个方法，动态绑定支持多态。

面向对象设计原则

单一职责原则：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。

开闭原则：软件实体应当对扩展开放，对修改关闭。

里氏代换原则：所有引用基类的地方必须能透明地使用其子类的对象。

依赖倒转原则：高层模块不应该依赖低层模块，它们都应该依赖抽象，抽象不应该依赖于细节，细节应该依赖于抽象。

接口隔离原则：客户端不应该依赖那些它不需要的接口。

合成复用原则：优先使用对象组合，而不是继承来达到复用的目的。

迪米特法则：每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

UML图

UML，即统一建模语言，与程序设计语言无关。它主要用于可视化、描述、构造和文档化软件系统的制品。

UML的三个要素：

• UML的基本构造块：描述模型中最具有代表性的成分。
• 规则：规定如何将这些构造块放置在一起。
• 公共机制：适用于整个语言的一些通用机制。

UML的基本构造块：

• 事物：对模型中最具有代表性的成分的抽象。
• 关系：将事务结合在一起，定义它们之间的交互和依赖。
• 图：聚集了相关的事物，以图形化的方式展示系统的结构和行为。

UML中的四种事物：

• 结构事物：描述系统的静态部分，如类、接口、协作和组件。
• 行为事物：描述系统的动态部分，如交互和状态机。
• 分组事物：将其他事物组织在一起，如包。
• 注释事物：为模型元素提供描述性的注释和说明。

关系

依赖：一个事物的语义依赖于另一个事物的语义的变化而变化，是一种使用关系，即一个类的实现需要另一个类的协助，普通箭头指向被使用者，比如Driver类指向Car类，代表Driver需要使用Car。

关联：是一种拥有关系，它使得一个类知道另一个类的属性和方法。带普通箭头的实线，指向被拥有者。双向的关联可以有两个箭头，或者没有箭头。单向的关联有一个箭头。细分为组合和聚合。

• 聚合：是一种整体与部分的关系。且部分可以离开整体而单独存在。聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。
• 组合：是一种整体与部分的关系。但部分不能离开整体而单独存在，组合关系是关联关系的一种，是比聚合关系还要强的关系。

泛化：是一种继承关系，表示子类继承父类的所有特征和行为。

实现：是一种类与接口的关系，表示类是接口所有特征和行为的实现。

类图

类图：静态图，为系统的静态设计视图，展现一组对象、接口、协作和它们之间的关系。

多重度：指的是不同类之间的联系，类似于数据库设计的表与表的关系。

对象图

对象图：静态图，展现某一时刻一组对象及它们之间的关系，为类图的某一快照。在没有类图的前提下，对象图就是静态设计视图。

用例图

用例图：静态图，展现了一组用例、参与者以及它们之间的关系。

用例图中的参与者是人、硬件或其他系统可以扮演的角色；用例是参与者完成的一系列操作。

用例之间的关系：包含（include）、扩展(extend)、泛化。

序列图

序列图：即顺序图，动态图，是场景的图形化表示，描述了以时间顺序组织的对象之间的交互活动。

• 有同步消息(进行阻塞调用，调用者中止执行，等待控制权返回，需要等待返回消息，用实心三角箭头表示)、
• 异步消息(发出消息后继续执行，不引起调用者阻塞，也不等待返回消息，由空心箭头表示)、
• 返回消息(由从右到左的虚线箭头表示)三种。

通信图

通信图：动态图，即协作图，是顺序图的另一种表示方法，也是由对象和消息组成的图，只不过不强调时间顺序，只强调事件之间的通信，而且也没有固定的画法规则，和顺序图统称为交互图。

状态图

状态图：动态图，展现了一个状态机，描述单个对象在多个用例中的行为，包括简单状态和组合状态。转换可以通过事件触发器触发，事件触发后相应的监护条件会进行检查。

活动图

活动图：动态图，是一种特殊的状态图，展现了在系统内从一个活动到另二个活动的流程。

• 活动的分岔和汇合线是一条水平粗线。
• 每个分岔的分支数代表了可同时运行的线程数。
• 活动图中能够并行执行的是在一个分岔粗线下的分支上的活动。

构件图

构件图(组件图):静态图，为系统静态实现视图，展现了一组构件之间的组织和依赖。

部署图

部署图：静态图，为系统静态部署视图，部署图描述的事物理模块的节点分布。它与构件图相关，通常一个结点包含一个或多个构件。其依赖关系类似于包依赖，因此部署组件之间的依赖是单向的类似于包含关系。

UML 4+1视图

逻辑视图。逻辑视图称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。

进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。

实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。也叫开发视图。

部署视图，部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。也叫物理视图。

用例视图。用例视图是最基本的需求分析模型。也叫统一的场景。

设计模式

描述了在我们周围不断重复发生的问题，以及该问题的解决方案的核心。设计模式提供了相关问题的解决方案，使得人们可以简单方便地复用成功的设计和体系结构。

四个基本要素：

• 模式名称：描述模式的简洁名称，便于记忆和讨论。
• 问题：描述应在何时使用该模式，解决特定情境中的问题。
• 解决方案：提供具体的设计内容，包括类和对象的结构及其交互方式。
• 效果：描述模式应用的结果和影响，阐明其优缺点。

设计模式分为三类：创建型模式、结构型模式和行为型模式。

创建型模式：（对象创建）

主要处理对象的创建，避免在代码中显式地实例化对象，从而提高代码的灵活性和复用性。

结构型模式：（类和对象组合）

主要处理类和对象的组合，确保在不同系统部件之间建立灵活和高效的结构。

行为型模式：（交互行为）

主要描述类或对象的交互行为，关注对象之间的职责分配和通信。

创建型设计模式

工厂模式（Factory Pattern）

工厂模式就像是一家披萨店。你告诉披萨店你想要什么类型的披萨，它会根据你的需求为你制作披萨。在这里，披萨店就是一个工厂，披萨是工厂创建的产品。

单例模式（Singleton Pattern）

单例模式确保一个类只有一个实例。这就像一座城市只有一个市长，无论多少人住在这座城市，市长都是唯一的。

建造者模式（Builder Pattern）

建造者模式像是建造一座房子。你可以选择房子的类型、颜色、材料等，并由建筑工人按照你的选择来构建房子。通过建造者模式，可以逐步构建复杂对象，而无需亲自处理所有细节。

原型模式（Prototype Pattern）

原型模式通过复制现有对象来创建新对象。这就像使用3D打印机复制一件艺术品或零件，从一个原型创建多个相同的物品。

结构型设计模式

适配器模式（Adapter Pattern）

适配器模式允许两个不兼容的接口协同工作。它就像使用电源适配器将外国电器插头适配到国内插座，使不同的类可以一起工作。

桥接模式（Bridge Pattern）

桥接模式分离了一个对象的抽象部分和具体部分，使它们可以独立地变化。这个模式就像一座桥，将两个独立的领域连接起来。

组合模式（Composite Pattern）

组合模式允许将对象组织成树状结构，使单个对象和组合对象都可以一致地对待。这就像将多个文件夹和文件组织成文件系统树一样。

装饰器模式（Decorator Pattern）

装饰器模式允许动态地为对象添加新的功能，而无需修改其源代码。这就像在你的家中不断地添加新的家具或装饰来改善它的外观和功能。

外观模式（Facade Pattern）

外观模式提供了一个简化的接口，用于访问复杂系统中的一组接口。这个模式就像建筑物的外立面，隐藏了建筑内部复杂的结构，使外部用户可以轻松访问。

享元模式（Flyweight Pattern）

享元模式旨在最小化内存或计算开销，通过共享尽可能多的相似对象来实现。这就像在共享办公空间中租用一个工作区，多个人可以共享同一空间，减少了资源浪费。

代理模式（Proxy Pattern）

代理模式允许一个对象代表另一个对象进行控制访问。就像你聘请一个房产经纪人代表你购买房产，代理模式可以控制对另一个对象的访问。

行为型设计模式

责任链模式（Chain of Responsibility Pattern）

责任链模式就像是传递请求。多个对象依次尝试处理请求，直到有一个对象能够处理为止。

命令模式（Command Pattern）

命令模式就像使用遥控器来控制设备。你将命令封装在遥控器按钮中，然后可以随时执行命令。

解释器模式（Interpreter Pattern）

解释器模式用于处理语言解释和编译器等领域，它定义了一种语言的语法表示，并提供了解释器来解释这种语法。

迭代器模式（Iterator Pattern）

迭代器模式提供了一种顺序访问集合元素的方法，而无需暴露集合的内部结构。

中介者模式（Mediator Pattern）

中介者模式就像是一个中间人协调多个对象之间的交互。它减少了对象之间的直接通信，降低了耦合度。

备忘录模式（Memento Pattern）

忘录模式允许你保存对象的状态，以便将来可以还原到先前的状态。

观察者模式（Observer Pattern）

观察者模式允许多个观察者（订阅者）订阅主题（发布者），当主题有新信息时，观察者会自动接收通知。

状态模式（State Pattern）

状态模式允许对象在不同状态下表现出不同的行为，就像人的不同情绪状态，每种状态下的行为可能不同。

策略模式（Strategy Pattern）

策略模式允许在运行时选择不同的算法或策略来解决同一个问题。

模板方法模式（Template Method Pattern）

模板方法模式定义了一个算法的框架，并允许子类实现其中的一些步骤。

访问者模式（Visitor Pattern）

访问者模式允许你定义不同的访问者来执行不同类型元素的操作。

项目管理

进度管理

软件项目进度管理的目的：确保软件项目在规定的时间内按期完成。

项目管理基本原则：划分、相互依赖、时间分配、工作量确认、确定责任、明确输出结果、确定里程碑。

项目管理进度安排：为监控软件项目的进度计划和工作的实际进展情况，表示各项任务之间进度的相互依赖关系，需要采用图示的方法。

• Gatt图：又称为横道图，横轴表示时间，纵轴表示活动，以时间顺序表示活动，能反应活动间的并行关系，但无法反应活动之间的依赖关系，因此也难以清晰的确定关键任务和关键路径。
• Pert图：类似于前趋图，是有向图，反应活动之间的依赖关系，有向边上标注活动运行的时间，但无法反应活动之间的并行关系。

关键路径

所谓关键路径就是指项目完成必须要执行的环节和步骤，我们可以通过pert图来求出项目要完成必须要经过哪些环节以及项目的总工期，注意，虽然关键路径是项目的最短工期，但却是从开始到结束时间最长的路径。

活动时间

• 最早开始时间 (ES)：某项活动能够开始的最早时间。
• 最早结束时间 (EF)：某项活动能够完成的最早时间。
• 最迟结束时间 (LF)：为了使项目按时完成，某项活动必须完成的最迟时间。
• 最迟开始时间 (LS)：为了使项目按时完成，某项活动必须开始的最迟时间。

总浮动时间

在不延误项目完工时间且不违反进度制约因素的前提下，活动可以从最早开始时间推迟或拖延的时间量。总浮动时间反映了该活动的进度灵活性。

自由浮动时间

在不延误任何紧后活动的最早开始时间且不违反进度制约因素的前提下，活动可以从最早开始时间推迟或拖延的时间量。

软件配置管理

软件配置管理（Software Configuration Management，简称SCM）是软件项目管理的一个关键方面，旨在有效地管理和控制软件开发过程中的各种元素和变更。它涉及到跟踪、控制和管理软件系统的不同版本、构件、文档和配置项，以确保软件开发过程的有序性、可追踪性和可控性。

关键概念和任务：

• 配置项（Configuration Items,Cls)：配置项是软件项目中的各种组成部分，包括源代码、文档、库、二进制文件、脚本等。每个配置项都可以被版本化、控制和管理。
• 版本控制：SCM包括版本控制，它允许跟踪和管理配置项的不同版本。每个版本都有一个唯一标识符，以便在需要时回溯到特定版本。
• 变更管理：变更管理是SCM的一部分，它涉及处理和记录对配置项的变更请求、评审、批准和实施。这确保了变更是有计划、受控制和可追踪的。
• 配置控制：配置控制是确保配置项在整个软件开发周期中保持一致性和稳定性的过程。它包括定义、文档化和执行配置管理策略。
• 构建和发布管理：SCM也涵盖了构建和发布管理，确保软件的不同版本可以按需构建和发布，以满足用户需求。

为什么需要软件配置管理？

• 版本控制：确保团队可以追踪和管理不同版本的软件，以及变更历史，从而降低错误和冲突的风险。
• 协作支持：允许多个开发者协同工作，同时修改和访问同一代码库，而不会导致冲突。
• 追踪和审计：提供可追踪性，以确定哪些代码或文档用于特定版本的软件，以及谁进行了何种变更。
• 质量控制：帮助确保软件的稳定性和质量，通过控制和验证变更的影响。
• 配置管理：确保在软件项目中保持一致性，防止意外的配置问题。
• 自动化构建和部署：通过自动化构建和部署流程，提高了软件交付的可靠性和效率。

总之，软件配置管理是软件开发项目中的关键实践，它有助于确保软件的稳定性、质量和可维护性，同时提供了一种有效的方式来跟踪和管理软件的版本和变更。这对于大型和复杂的软件项目尤为重要。

质量与风险管理

风险管理就是要对项目风险进行认真的分析和科学的管理，这样，是能够避开不利条件、少受损失、取得预期的结果并实现项目目标的，能够争取避免风险的发生或尽量减小风险发生后的影响。但是，完全避开或消除风险，或者只享受权益而不承担风险是不可能的。

风险管理计划编制：如何安排与实施项目的风险管理，制定下列各步的计划：

• 风险识别：识别出项目中已知和可预测的风险，确定风险的来源、产生的条件、描述风险的特征以及哪些项目可以产生风险，形成一个风险列表。
• 风险定性分析：对已经识别的风险进行排序，确定风险可能性与影响、确定风险优先级、确定风险类型。
• 风险定量分析：进一步了解风险发生的可能性具体由多大，后果具体由多严重。这一步并不是必须的。
• 风险应对计划编制：对每一个识别出来的风险来分别制定应对措施，这些措施组成的文档称为风险应对计划。包括消极风险和积极风险。
• 风险监控：监控风险计划的执行，检测残余风险，识别新的风险，保证风险计划的执行，并评价这些计划对减少风险的有效性。

在信息系统项目中，从宏观上来看，风险可以分为项目风险、技术风险和商业风险。

项目风险是指潜在的预算、进度、个人（包括人员和组织）、资源、用户和需求方面的问题，以及它们对项目的影响。项目复杂性、规模和结构的不确定性也构成项目的（估算）风险因素。项目风险威胁到项目计划，一旦项目风险成为现实，可能会拖延项目进度，增加项目的成本。

技术风险是指潜在的设计、实现、接口、测试和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）也是风险因素。技术风险威胁到待开发系统的质量和预定的交付时间。如果技术风险成为现实，开发工作可能会变得很困难或根本不可能。

商业风险威胁到待开发系统的生存能力，主要有以下5种不同的商业风险：

• 市场风险：开发的系统虽然很优秀但不是市场真正所想要的。
• 策略风险：开发的系统不再符合企业的信息系统战略。
• 销售风险：开发了销售部门不清楚如何推销的系统。
• 管理风险：由于重点转移或人员变动而失去上级管理部门的支持。
• 预算风险：开发过程没有得到预算或人员的保证。