《软件工程导论》期末复习知识点总结（全）

- 写在最前
- 软件需求综述
- - 软件项目成功的三个主要因素
  - 软件人成功的三个主要因素
  - 软件工程和需求工程区别与联系
  - 软件需求的内容和层次
  - - 业务需求
    - 用户需求
    - 功能性与非功能性需求
- 软件需求获取
- - 需求工程的内容
  - - 需求开发
    - 需求管理
  - 需求获取的方法(11个)
  - 需求分析的方法(8个)
  - 开发原型
  - - 分类
    - 目的
- 需求文档编写与管理
- - 数据字典
  - - 定义
    - 具体内容
  - 需求文档
- 面向对象
- - 面向对象的本质特征
- 系统用例
- - 用例名称表达
  - - 命名格式
    - 命名用词
    - 用例选择
  - 用例间的关系
- 类图和顺序图
- - 类图
  - - 类图中的关系
    - 类图中的类
    - 题目要求
  - 顺序图
- 活动图和状态图
- - 活动图
  - - 注意事项
    - 完整例子
  - 状态图
  - - 要求
    - 状态转移条件
    - 示例
- 设计模式
- - 设计模式原则总览
  - 开闭原则（OCP）
  - 依赖倒转原则（DIP）
  - - 里氏代换原则（LSP）
    - 迪米特法则（最少知道原则）（LKP）
    - 接口隔离原则（ISP）
    - 单一职责原则（SRP）
- 软件工程概述
- - 软件和硬件的不同
  - 软件神话
  - 软件工程的概念
- 过程模型
- - 瀑布模型
  - - 概念
    - 优点
    - 缺点
    - 适用场合
  - V模型
  - 增量模型
  - - 概念
    - 优点
    - 缺点
    - 适用
  - 演化过程模型
  - - 概念
    - 优点
    - 缺点
    - 分类
    - - 原型开发模型
      - 适用场景
        
        优点
        
        缺点
      - 螺旋模型
      - 优点
        
        缺点
        
        适用场景
- 专用过程模型
- - 基于构件的开发
  - 形式化方法模型
  - - 优点
    - 缺点
    - 适用场景
  - 面向方面的软件开发
  - 统一过程模型
- 敏捷过程
- - 如何理解敏捷宣言
  - SCRUM概念
- 构建分析模型
- 构建设计模型
- - 设计概念
  - 设计元素分类
- 用户体验与可用性
- SOA
- - 基本思想
  - 基本要素
  - 服务架构模式
- 云计算
- - 什么是云计算
  - 为什么要用云
  - 云计算的基本形式
  - 虚拟化（资源的逻辑表示）的优势
  - 虚拟化的种类
- 写在最后

写在最前

《软件工程导论》期末复习知识点总结.pdf

话不多说，进入正文，如果这篇文章对你有帮助，请给博主点赞鼓励一下。

软件需求综述

软件项目成功的三个主要因素

需求的清晰表述
用户的参与
主管层的支持

软件人成功的三个主要因素

需求的把握与控制能力
良好的沟通能力
责任心与承担责任的能力

软件工程和需求工程区别与联系

软件需求工程属于软件工程的大范畴，是软件工程的一个分支，其主要对象是软件需求。
软件工程是求解软件的工程，需求工程是求解软件需求的工程。
将软件工程的原理、方法、技术、手段与软件需求的实际紧密结合，并创造性的应用于软件需求领域。
除此之外，还要根据软件需求的特点来发展需求工程的理论、方法、技术和工具。

软件需求的内容和层次

业务需求

描述组织或客户对系统、产品高层次的目标要求；通过项目远景与范围文档予以说明。

用户需求

描述用户使用产品必须完成的任务，通过实例（ use-case ）文档予以说明。

功能性与非功能性需求

描述开发人员必须实现的软件功能，用户通过这些功能完成他们的日常工作和任务，以满足业务需求。通过软件需求规范予以说明。
描述系统展现给用户的行为和执行的操作等，包括质量属性、操作界面细节、性能要求、约束条件、应遵从的标准与规范等。通过软件需求规范和模型予以说明。

软件需求获取

需求工程的内容

需求开发

获取需求
分析需求
编写SRS
验证SRS

需求管理

控制变更
控制版本
跟踪需求
跟踪状态

需求获取的方法(11个)

定义需求的开发过程
确定需求的收集、分析、细化和核实的步骤、方法、模板。
定义项目前景与范围
前景说明所有涉众对产品目标的达成的共识；
范围定义了需求是否属于某个特定版本的界线。
确定用户群
将可能使用产品的用户组，以避免出现某一用户群的需求被忽略的情况。
选择用户代表
为每类用户至少选择一位能代表他们需求的、有时间、有热情、有权利参与需求工作的用户代表。
建立核心队伍
把同类产品或产品前版本的用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求。
确定用例
从用户代表处收集他们使用软件完成所需任务的描述——用例，讨论用户与系统间的交互方式和对话要求。
确定系统事件和响应
列出系统可能发生的外部事件以及对每个事件所期待的响应时间。
举行进一步需求获取的讨论
专门的需求获取讨论会可以方便分析员和客户进行合作。
观察用户如何工作
观察用户执行业务的过程。画一张简单的数据流程图或业务流程图，描绘出用户什么时候获得什么数据，并怎样使用这些数据进行业务处理。
检查问题告
客户对当前系统的问题告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法。
需求重用
如果客户要求的功能与已有的某产品很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。

需求分析的方法(8个)

编制关联图
定义系统与外部实体的界限和接口
创建开发原型
当开发人员或用户不能确定需求时，可构建一个开发原型。它可使许多概念和可能发生的事更为直观明了。通过评价原型，能更好地相互理解所要解决的问题
分析需求的可行性
在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突、对外界因素的依赖和技术障碍。
确定需求优先级
应用分析方法来确定use-case、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本应包含的需求和特性。
为需求建立模型
需求的图形分析模型是SRS的极好补充说明。这样的模型包括用例图、数据流程图、实体关系图、状态变换图、对话框图、对象类及交互作用图等。
编写数据字典
通过建立数据字典，对系统用到的所有数据项和数据结构进行定义。
将需求分解到子系统
必须将包括多个子系统的复杂产品的需求分配到各个软件、硬件以及人员子系统和部件中去。
应用质量功能调配（QFD）
质量功能调配（QFD）是一种高级系统技术，它将产品功能、属性与对客户的重要性联系起来。QFD将需求分为三类：普通需求、期望需求、兴奋需求。

开发原型

目的

明确并完善需求
探索设计选择方案
发展为最终的产品原型

需求文档编写与管理

数据字典

定义

一个定义应用程序中使用的所有数据元素和结构的含义、类型、长度、格式、度量单位、精度以及允许取值范围的数据逻辑的描述。

具体内容

数据项
数据结构
数据流
数据存储
处理过程
外部实体

需求文档

需求文档的编写要有以下内容：

系统的目的和内容
系统中的术语表
用例
系统采用的技术
开发过程中的参加人员、业务规则、系统运行所依赖的条件、安全要求、文档要求等各种其它需求
法律、政治、组织机构等方面的问题

面向对象

面向对象的本质特征

抽象
将一类对象的共同特征总结出来构造类的过程，包括数据抽象和行为抽象两方面
封装
把数据和操作数据的方法绑定起来，对数据的访问只能通过已定义的接口
继承
从已有类得到继承信息创建新类，子类继承父类属性和方法
多态
包括重载和重写，允许相同或不同子类型的对象对同一消息作出不同响应

系统用例

用例名称表达

命名格式

动（宾）结构，执行者视角（用户观点而非系统观点）

命名用词

避免弱动词、弱名词

用例选择

选取有意义的目标，如“设置查询条件”就是无意义的

用例间的关系

关联关系
泛化关系
扩展关系
单向关联（一般箭头，强依赖关系）
继承/泛化（三角箭头，指向父类）
组合（整体指向部分，整体实心菱形，部分不可以独立存在）

类图中的类

“目”，类名-属性-方法，窗可以为空但不能缺少
权限属性名：类型 [ = 默认值 ]
权限方法名称(参数列表) [ : 返回类型]

其中权限表示为：

public：+
protected：#

活动图和状态图

活动图

注意事项

表达规范、统一（如果线如果是直线就一直是直线）
分支要写【条件】，一定要用中括！
要包括5个活动以上
一律用原矩形框
起点终点的画法
分支表示选择；分叉表示并行

设计模式

设计模式原则总览

依赖倒转原则（DIP）

含义：高层组件不依赖底层组件
实现方法：尽量使用合成/聚合，而不是使用继承
解释：
- 高层模块不应依赖低层模块，两者都应该依赖于抽象（在继承层次结构中，基类不应该知道它的任何子类）；
- 抽象不应该依赖于细节（已经详细实现的模块），细节应该依赖于抽象

迪米特法则（最少知道原则）（LKP）

含义：一个软件实体应当尽可能少的与其他实体发生相互作用
实现方法：通过中间类建立联系
解释：方法不能乱调用，只能调用下面类型（直接朋友）的方法：
- 同一个类中的其他方法
- 传递进来的参数对象的方法
- 在方法中自己实例化的任何对象的方法
- 当前对象内部的组件的方法

单一职责原则（SRP）

含义：一个类只负责一项职责
实现方法：应该有且仅有一个原因引起类的变更
例子：用户的属性（Property）和用户的行为（Behavior）没有分开，多个原因可能引起类的变更

软件工程概述

软件和硬件的不同

硬件
- 人工制造
- 易磨损（硬件磨损后可以使用备件替换）
- 使用标准化组件制造
- 相对简单
- 制造出来后一般不改变
软件
- 开发出来的
- 易退化（需求的不断变更是软件退化的根本原因）
- 自定义构建
- 较为复杂
- 开发出来结果后可能会经常改变

软件神话

软件神话就是谬论：

如果进度落后，那么增加多的程序员人手则可以赶上进度
对目标一般的称述就足以开始构建项目
可以容忍项目需求的变化，因为软件是灵活多变的
一旦我们编写了一个工作程序，我们就完成任务了
直到程序运行，才能评估质量
对于一个成功的项目来说，唯一可交付的工作产品就是程序
软件工程会让我们写太多文档，并且减缓我们的开发速度

软件工程的概念

将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件
以及上述方法的研究

过程模型

瀑布模型

概念

将软件生命周期分为六个阶段
软件开发要遵循过程规律，按次序进行
每个阶段均有里程碑和提交物
工作以线性方式进行，上一阶段的输出是下一阶段的输入

优点

简单、易懂、易用
为项目提供了按阶段划分的检查点，项目管理比较规范
每个阶段必须提供文档，而且要求每个阶段的所有产品必须进行正式、严格的技术审查

缺点

不支持需求变更
到最后部署才知道产品样子，返工成本巨大

适用场合

需求相当明确
开发团队对这一领域熟悉
外部不可控因素少
小型的清晰项目或长周期的项目

V模型

和瀑布模型顺序一样，但是每个阶段都有测试，尽早发现错误

增量模型

概念

软件被作为一系列的增量来进行开发
每一个增量都提交一个可以操作的产品
第一个增量往往是核心产品
客户使用上一个增量的提交物并进行自己评价，制定下一个增量计划，说明需要增加的特性和功能

优点

提高对用户需求的响应：用户看到可操作的早期版本后会提出一些建议和需求，可以在后续增量中调整。
人员分配灵活：如果找不到足够的开发人员，可采用增量模型，早期的增量由少量人员实现，如果客户反响较好，则在下一个增量中投入更多的人力
可规避技术风险：不确定的功能放在后面开发。

缺点

加新增量的时候必须不破坏原有已构造好的东西
需求变更响应滞后
管理人员技术能力要强

适用

以迭代的方式运用瀑布模型，人手不够
需求被很好理解，项目的边界固定，可以在短时间内创建全功能系统

演化过程模型

概念

演化模型是迭代的过程模型，使得软件工程师能够逐步开发出更完整的软件版本
对一系列活动的重复应用，用以评估一系列论断，解决一系列风险，达成一系列开发目标，并逐步增量地建立并完善一个有效的解决方案

优点

及时投入市场

缺点

项目策划困难
没有确定演进的最快速度

专用过程模型

基于构件的开发

能够使软件复用，为软件工程师带来极大收益

形式化方法模型

优点

软件工程师可以应用严格的数学符来说明、开发和验证基于计算机的系统
提供了一种机制，使得在软件开发中可以避免一些问题，如歧义性问题、不完整问题、不一致问题等

缺点

开发非常耗时，成本也很高。
只有极少数程序员具有应用形式化方法的背景，因此需要大量的培训
对于技术水平不高的客户，很难用这种模型进行沟通。

适用场景

用来开发高度关注安全的软件。
开发软件出错将导致重大经济损失的软件。

面向方面的软件开发

统一过程模型

敏捷过程

如何理解敏捷宣言

个体和交互胜过过程和工具
- 人是获得成功的最为重要的因素
- 合作、沟通以及交互能力要比单纯的编程能力更为重要
- 团队的构建要比环境的构建重要得多
可以工作的软件胜过面面俱到的文档
- 编制众多的文档需要花费大量的时间
- 要保持文档和代码同步，要花费更多的时间
- 编写并维护一份系统原理和结构方面的文档，并且是短小的并且主题突出的
- 直到迫切需要并且意义重大时，才来编制文档
客户合作胜过合同谈判
- 不能像订购日用品一样来订购软件
- 成功的项目需要有序、频繁的客户反馈
- 一个指明了需求、进度以及项目成本的合同存在根本上的缺陷
- 成功的关键在于和客户之间真诚的协作，经受住变更
响应变化胜过遵循计划
- 响应变化的能力常常决定着一个软件项目的成败
- 计划不能考虑得过远
- 计划往往会遭受形态上的改变，而不仅仅是日期上的改变
- 计划逐渐降低的细致度，意味着我们仅仅对于迫切的任务才花费时间进行详细的计划

SCRUM概念

Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发
迭代：开发一部分，就提交一部分，用户就使用一部分，就反馈一部分，我们就修改一部分
最有效的反馈就是当用户用这个软件（或其一部分）时给出的意见
过程
1. 需求：依靠用户的充分参与和及时反馈来保证功能满足需求的有效性
2. 设计
- 数据建模
- 流程建模
1. 持续集成
2. 测试
3. 重构

构建分析模型

分析元素有：

基于场景元素
基于流元素（数据流）
基于类元素
行为元素

构建设计模型

设计概念

抽象：数据，过程，控制
架构：软件的整体结构
模式：“传达”一个经过验证的设计解决方案
模块化：数据和功能的划分
信息隐藏：接口
功能独立性：高内聚和低耦合
重构：在不影响行为的情况下改进设计
细化：对所有抽象的细节进行细化

设计元素分类

体系结构：给人总体的外貌设计
接口设计：
- 用户界面（关键）
- 外部接口
- 内部接口（内部模块之间连接方式）
组件设计：数据结构、算法
- 设计原则：开闭原则
部署

用户体验与可用性

用户体验包括终端用户与公司、服务和产品交互的所有方面
- 满足客户的确切需求，没有麻烦
- 简单和优雅，生产出的产品让人拥有和使用都很愉快
- 远远超出了满足客户的需求，不仅仅是提供功能列表
- 高质量的用户体验应是多学科的综合
设计的三个层次：好的设计应同时达到三个维度
- 直觉设计：由外观解释产品本身，即设计可视性
- 行为设计：产品的使用效率与满意度，即使用性的范畴
- 思考设计：与产品的合理性与其推理性有关
可用性的属性和目标（目标就是满足以下内容）
- 有效性（功能没问题）
- 效率性（效率高）
- 可学习性（容易用，易上手）
- 满意度（满意）
用户体验和可用性的区别：用户体验包含了终端用户与公司、服务和产品交互的所有方面，而可用性更注重功能

SOA

基本思想

SOA：Service Oriented Architecture，面向服务的架构，或者说，以服务为基础搭建的企业IT架构
SOA中服务（Service）的理念，本质上是一种业务和技术完全分离，业务和技术又能自由组合的思想。它达到了目前软件设计思想的最高境界。
面向服务是对面向组件编程的进一步解耦和封装，业务组件可以自由地绑定各种传输协议。所谓”面向服务”，就是如何实现独立于技术的服务接口。

基本要素

松散耦合
粗粒度
位置和传输协议透明（最根本区别）

服务架构模式

以服务为核心的体系架构，是分层架构。最底层的功能性服务，到原子服务和服务构件，到顶层的业务流程服务，目的是最大限度地封装不同的服务，从而达到复用的目的；无论哪一个层次，其核心都是服务。

云计算

什么是云计算

从工程观点：在分配给大型物理机器的虚拟机上提供服务
从商业观点：一种解决大规模应用程序可伸缩性的方法

为什么要用云

不必支付硬件，降低成本
减少冗余能力的浪费，使资源充分利用
按需提供计算能力，确保我们可以随时为高峰期提供足够的能力
可以减少容量需求消退

云计算的基本形式

IaaS（基础设施即服务）：只提供云计算的基础平台（只提供络、存储、服务器、虚拟化）
PaaS（平台即服务）：在IaaS基础上还提供操作系统、中间件、运行时的组件
SaaS（软件即服务）：在PaaS的基础上还提供了数据、应用

《软件工程导论》期末复习知识点总结（全）

目录

写在最前

软件需求综述

软件项目成功的三个主要因素

软件人成功的三个主要因素

软件工程和需求工程区别与联系

软件需求的内容和层次

业务需求

用户需求

功能性与非功能性需求

软件需求获取

需求工程的内容

需求开发

需求管理

需求获取的方法(11个)

需求分析的方法(8个)

开发原型

分类

目的

需求文档编写与管理

数据字典

定义

具体内容

需求文档

面向对象

面向对象的本质特征

系统用例

用例名称表达

命名格式

命名用词

用例选择

用例间的关系

类图中的类

活动图和状态图

活动图

注意事项

设计模式

设计模式原则总览

依赖倒转原则（DIP）

迪米特法则（最少知道原则）（LKP）

单一职责原则（SRP）

软件工程概述

软件和硬件的不同

软件神话

软件工程的概念

过程模型

瀑布模型

概念

优点

缺点

适用场合

V模型

增量模型

概念

优点

缺点

适用

演化过程模型

概念

优点

缺点

分类

原型开发模型

适用场景

优点

缺点

螺旋模型

优点

缺点

适用场景

专用过程模型

基于构件的开发

形式化方法模型

优点

缺点

适用场景

面向方面的软件开发

统一过程模型

敏捷过程