软件工程主要包括哪几个基本要素？
-
软件
软件是计算机系统中与硬件相互依存的一部分，包括程序、数据及其相关文档的完整集合
“计算机程序、方法、规则、相关的文档资料以及在计算机上运行时所必需的数据”
-
软件包括的基本组成要素
-
程序
按事先设计的功能和性能要求执行的指令序列
-
数据
使程序能够正确地处理信息的数据结构
-
文档
与程序开发、维护和使用有关的图文材料
-
-
软件工程
软件工程是开发、运行、维护和修复软件的系统方法
软件工程是指指导软件开发和维护的工程性学科
-
软件工程方法包括的基本要素
-
过程
支持软件生命周期的所有活动
-
方法
为软件开发过程提供“如何做”的技术
-
工具
为软件开发方法提供自动的或半自动的软件支撑环境
-
-
软件工程的目标
软件工程的目标是运用先进的软件开发技术和管理方法来提高软件的质量和生产率，也就是要以较短的周期、较低的成本生产出高质量的软件产品，并最终实现软件的工业化生产
-
软件危机
由于软件本身的特点及软件开发方法等多方面问题，软件的发展速度远远滞后于硬件的发展速度，不能满足社会日益增长的软件需求。软件开发周期长、成本高、质量差、维护困难
-
软件危机表现方面
- 缺乏软件开发的经验和有关软件开发数据的积累，使得开发工作很难指定
- 软件人员和用户的交流存在障碍，除了知识背景的差异，缺少适合的交流方法及需求描述工具
- 软件开发过程不规范，缺少方法论的指导，开发人员各自为战，缺少整体的规划和配合，不重视文字资料工作，软件难以维护
- 随着软件规模的增大，其复杂性往往呈指数级升高
- 缺少有效的软件评测手段，提交用户的软件质量差，在运行中暴露出大量的问题，轻者影响系统的正常使用，重者发生事故，甚至造成生命财产的重大损失
-
软件生存周期
（答题的时候答的应该是下面的六点而不是这些，辅助理解记忆吧
软件生存期由软件定义、软件开发、运行维护三个时期组成
-
软件定义
问题定义、可行性研究、需求分析
-
软件开发
概要设计、详细设计、编码、测试
-
运行维护
四类活动：改正性维护、适应性维护、完善性维护、预防性维护
-
-
阶段工作重点及输出产物
-
问题定义与可行性研究
-
重点工作
到底要解决什么问题?在成本和时间的限制条件下能否解决问题？
- 确定待开发软件系统的总目标，给出它的功能、性能、约束、接口以及可靠性等方面的要求
- 由软件分析员和用户合作，探讨解决问题的可能方案
- 针对每一个候选方案，从技术、经济、法律和用户操作等方面，研究完成该项软件任务的可行性
-
输出物
开发任务的实施计划、可行性研究报告
-
-
需求分析
-
重点工作
目标系统应该做什么
- 分析用户要求，明确目标系统的功能需求和非功能需求
- 细化目标系统，了解需求细节
-
输出物
软件需求规格说明/系统功能规格说明、测试计划、初步的系统用户手册
-
-
软件设计
-
重点工作
目标系统如何做
- 制定设计方案，把需求转换呈软件体系结构（概要设计）
- 描述每个构建上需要做的工作（详细设计）
-
输出物
设计方案、单元测试计划、集成测试计划
-
-
程序编码和单元测试
-
重点工作
- 选择合适的编程语言，把软件设计转化成计算机可以接收的程序代码
- 对程序结构中的各个模块进行单元测试，排错
-
输出物
结构良好、清晰易读、与设计一致的代码
-
-
集成测试和系统测试
-
重点工作
- 将已测试过的模块按设计规定的顺序组装起来
- 根据需求规格说明的要求，对各项需求进行确认
-
输出物
-
-
软件的运行和维护
-
重点工作
改正性维护、适应性维护、完善性维护、预防性维护
-
输出物
-
-
-
软件过程
软件过程也称为软件生存期，是从软件项目需求定义直至软件运行维护为止，跨越整个生命周期的系统开发、运行和维护所实施的全部过程、活动和任务的结构框架
-
典型软件过程模型
- 瀑布模型
- 快速原型模型
- 增量模型
- 螺旋模型
- 喷泉模型
- 统一过程
- 基于构件的开发模型
- 敏捷过程
软件过程模型的第一个模型（具体看课本
-
主要缺陷是：
最终开发出的软件产品不能真正满足用户的需要
只是用于项目开始时需求已确定的情况
-
根本原因是：
几乎完全依赖于书面的规格说明
-
快速原型法主要应用的目的
加速软件开发过程，节约软件开发成本
-
原型法包括的基本类型
-
探索型原型
-
实验型原型
-
演化型原型
-
里程碑是用来说明项目进展情况的事件。通常把一个开发活动的结束或一个项目开发任务的完成定义为一个里程碑。 里程碑必须与软件开发工作的进展情况密切相关，而且里程碑的完成必须非常明显（也就是说，里程碑应该有很高的可见性）里程碑就是项目开发过程中一个重要的阶段点，这个阶段点之后将意味着项目的开发进入了另一个层面
-
需求分析的基本任务
需求分析的基本任务是准确地回答“系统必须做什么”这个问题，深入描述软件的功能和性能需求，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求
-
主要问题
- 系统的目标或范围问题
- 需求不准确问题
- 需求的异变问题
-
解决方法
- 发现和分析问题，并分析问题的原因/结果关系
- 与用户进行各种方式的交流，并使用调查研究方法收集信息
- 按照三个成分即数据、过程、接口观察问题的不同侧面
- 将获取的需求文档化，形式有用例、决策表、决策树等
-
结构化分析
是一种面向数据流进行分析的方法
是一种建模技术，核心是数据字典，包括在目标系统中使用和生成目标对象。围绕核心有三种图：数据流图（DFD），实体-关系图（ER），状态-迁移图（STD）
-
三种图的作用
-
数据流图：描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能（子功能），用于功能建模
-
实体-关系图：描述数据对象之间的关系，用于数据建模
-
状态-迁移图：描述系统对外部事件如何响应、如何动作，用于行为建模
-
数据字典以词条方式定义在数据模型、功能模型和行为模型中出现的数据对象及控制信息的特性，给出它们的准确定义，包括数据流、加工、数据文件、数据元素，以及数据源点和数据汇点等
（emmm...wtf.. 有时间就康康书本内容吧这是什么鬼
-
模块化设计的基本原则
- 低耦合：耦合是模块之间的相对独立性的度量
- 高内聚：模块功能强度（一个模块内部各个元素彼此结合的紧密程度）的度量
-
分治原则
分而治之是人们解决大型复杂问题时通常采用的策略
将大型复杂问题分解为许多容易解决的小问题，原来的问题也就容易解决了
-
分治原则注意事项
模块分解不是越小越好
-
黑盒测试
已知产品的功能设计规格，可以通过测试证明每个实现了的功能是否符合要求
黑盒测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
-
白盒测试
已知产品的内部工作过程，可以通过测试证明每个实现了的功能是否符合要求
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，即清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。
-
面向对象分析
面向对象分析就是抽取和整理用户需求并建立问题域精确模型的过程
-
基本模型
-
用例模型：由用例和场景表示的功能模型
-
对象模型：由类和对象表示的静态模型
-
交互模型：由状态图、顺序图等表示的动态模型
-
-
集成测试
集成测试也称组装测试或联合测试
在单元测试的基础上，把所有模块按照设计要求组装为系统测试
-
集成测试基本方式
-
一次性组装方式
-
增殖式组装方式
-
自顶向下的增殖方式
-
自底向上的增殖方式
-
混合式增殖方式
-
-
白盒测试分类：
逻辑测试属于白盒测试，逻辑覆盖是以程序内部的逻辑结构为基础设计测试用例的技术
-
语句覆盖
所谓语句覆盖就是设计若干个测试用例，运行被测程序，使得每一个可执行语句至少执行一次
-
判定覆盖
所谓判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次
-
条件覆盖
所谓条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次
-
判定-条件覆盖
所谓判定-条件覆盖就是设计若干个测试用例，运行被测程序，使得判断中的每个条件的所有可能取值至少执行一次，同时每个判断本身的所有可能判断结果至少执行一次
-
条件组合覆盖
所谓条件组合覆盖就是设计若干个测试用例，运行被测程序每个判断的所有条件取值组合至少执行一次
-
路径覆盖
设计足够的测试用例，覆盖程序中所有可能的路径
-
单元测试
单元测试又称模块测试，是针对软件设计的最小单位——程序模块——进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错
-
单元测试基本方式
-
模块接口测试
-
局部数据结构测试
-
路径测试
-
错误处理测试
-
边界测试
-
-
环路复杂度
环路复杂度是用来定量度量程序的逻辑复杂度
-
环路复杂度的计算
对于给定的控制流图G，按McCabe给出的环路复杂度V(G)的计算方法如下：
-
环路复杂性定义为控制流程图种的区域数
-
设E为控制流图的边数，N为图中的结点数，则 $$ V(G) = E - N + 2 $$
-
设P为控制流图中的判定结点数，则 $$ V(G) = P + 1 $$
-
-
独立路径
独立路径指的是从起点至终点的一条路径中至少有一条边是与别的路径中所不同的，同时路径中不存在环路。
至少沿一条新的边移动的路径。对所有独立路径的遍历使得程序中的所有语句至少被执行一次。
-
找出独立路径
-
软件体系结构
一个程序或计算机系统的软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件、构件的外部可见属性以及它们之间的相互关系。外部可见属性则是指软件构件提供的服务、性能、使用特性、错误处理、共享资源使用等
-
软件体系结构的分类
-
按风格划分的通用体系结构模型
-
数据流风格
应用场景：管道/过滤器、批处理序列
-
调用/返回风格
便于设计出易于修改和拓展的程序结构
- 主程序/子程序体系结构
- 面对对象
- 层次结构
-
-
特定领域的体系结构模型
-
类属模型
典型应用：编译器模型
-
参考模型
典型应用：OSI
-
-
分布式系统结构
-
多处理器体系结构
-
客户机/服务器体系结构
-
分布式对象体系结构
-
代理
-
-
-
UML
UML(Unified Modeling Language), 目前使用最广泛的面向对象建模语言
-
UML动态模型
- 时序图：描述对象的交互过程.以时间为参考(强调的是时间顺序).
- 虚线：(生命线)表示对象的生命周期.
- 实线：对象消息.
- 虚线：返回消息.
- 长方形：活动(激活).
- 叉：对象消亡.
- 协作图：跟时序图一样,但强调对象的连接关系.
- 状态图：描述对象的自身的状态(一个对象的类型不同可能行为很古怪,行为变化很大).
- 活动图：(类似于流程图)描述一个环境中的交互顺序.
- 时序图：描述对象的交互过程.以时间为参考(强调的是时间顺序).
-
UML静态模型
-
用例图：描述系统功能及功能的使用者
-
类图：表现系统里实体的关系,责任,类和类之间的关系，属性及方法
-
对象图：当类图不能完全显示关系时用对象图.描述对象的属性,对象名,方法
-
组件图：对类功能的封装,一个组件包含多个类.
虚线：表示依赖关系
-
部署图：描述系统中的物理结构.
实线：表示连接
-
-
抽象
-
封装
-
继承
-
多态
-
单元测试
-
组装测试（模块测试）
-
确认测试
-
系统测试
Loadinggraph LR A0((单元测试)) A1((单元测试)) A2((单元测试)) idtest0>被测模块] idtest1>被测模块] idtest2>被测模块] idtest0-->A0 idtest1-->A1 idtest2-->A2 B((集成测试)) A0-->|已经测试过的模块|B A1-->|已经测试过的模块|B A2-->|已经测试过的模块|B info>设计信息] info-->B C((确认测试)) B-->|已集成的软件|C req>软件需求] req-->C D((系统测试)) C-->|已确认的软件|D other>系统其他元素] other-->D E[可交付的软件] D-->E
流程图差不多可以看懂了，大不了再康康书
主要包括：用例视图、设计视图（逻辑视图）、进程视图（过程视图）、实现视图、分部视图（部署视图）
- 用例视图： 需求分析、集成测试和系统测试
- 设计视图： 软件编码
- 进程视图： 单元测试
- 实现视图： 软件编码
- 部署视图： 软件的运行和维护
功能性是软件最重要的质量特征之一，可以细化成完备性和正确性。对软件的功能性评价主要采用定性评价方法。
a.完备性
完备性是与软件功能完整、齐全有关的软件属性。如果软件实际完成的功能少于或不符合研制任务书所规定的明确或隐含的那些功能，则不能说该软件的功能是完备的。
b.正确性
正确性是与能否得到正确或相符的结果或效果有关的软件属性。软件的正确性在很大程度上与软件模块的工程模型（直接影响辅助计算的精度与辅助决策方案的优劣）和软件编制人员的编程水平有关。
对这两个子特征的评价依据主要是软件功能性测试的结果，评价标准则是软件实际运行中所表现的功能与规定功能的符合程度。在软件的研制任务书中，明确规定了该软件应该完成的功能，如信息管理、提供辅助决策方案、辅助办公和资源更新等。那么即将进行验收测试的软件就应该具备这些明确或隐含的功能。
对于软件的功能性测试主要针对每种功能设计若干典型测试用例，软件测试过程中运行测试用例，然后将得到的结果与已知标准答案进行比较。所以，测试用例集的全面性、典型性和权威性是功能性评价的关键。
根据相关的软件测试与评估要求，可靠性可以细化为成熟性、稳定性、易恢复性等。对于软件的可靠性评价主要采用定量评价方法。即选择合适的可靠性度量因子（可靠性参数），然后分析可靠性数据而得到参数具体值，最后进行评价。
经过对软件可靠性细化分解并参照研制任务书，可以得到软件的可靠性度量因子（可靠性参数）。
a.可用度
可用度指软件运行后在任一随机时刻需要执行规定任务或完成规定功能时，软件处于可使用状态的概率。可用度是对应用软件可靠性的综合（即综合各种运行环境以及完成各种任务和功能）度量。
b.初期故障率
初期故障率指软件在初期故障期（一般以软件交付给用户后的三个月内为初期故障期）内单位时间的故障数。一般以每100小时的故障数为单位。可以用它来评价交付使用的软件质量与预测什么时候软件可靠性基本稳定。初期故障率的大小取决于软件设计水平、检查项目数、软件规模、软件调试彻底与否等因素。
c.偶然故障率
指软件在偶然故障期（一般以软件交付给用户后的四个月以后为偶然故障期）内单位时间的故障数。一般以每1000小时的故障数为单位，它反映了软件处于稳定状态下的质量。
d.平均失效前时间（MTTF）
指软件在失效前正常工作的平均统计时间。
e.平均失效间隔时间（MTBF）
指软件在相继两次失效之间正常工作的平均统计时间。在实际使用时，MTBF通常是指当n很大时，系统第n次失效与第n+1次失效之间的平均统计时间。对于失效率为常数和系统恢复正常时间很短的情况下，MTBF与MTTF几乎是相等的。
国外一般民用软件的MTBF大体在1000小时左右。对于可靠性要求高的软件，则要求在1000~10000小时之间。
f.缺陷密度（FD）
指软件单位源代码中隐藏的缺陷数量。通常以每千行无注解源代码为一个单位。一般情况下，可以根据同类软件系统的早期版本估计FD的具体值。如果没有早期版本信息，也可以按照通常的统计结果来估计。“典型的统计表明，在开发阶段，平均每千行源代码有5060个缺陷，交付后平均每千行源代码有1518个缺陷”。
g.平均失效恢复时间（MTTR）
指软件失效后恢复正常工作所需的平均统计时间。对于软件，其失效恢复时间为排除故障或系统重新启动所用的时间，而不是对软件本身进行修改的时间（因软件已经固化在机器内，修改软件势必涉及重新固化问题，而这个过程的时间是无法确定的）。
易用性可以细化为易理解性、易学习性和易操作性等。这三个特征主要是针对用户而言的。对软件的易用性评价主要采用定性评价方法。
a.易理解性
易理解性是与用户认识软件的逻辑概念及其应用范围所花的努力有关的软件属性。该特征要求软件研制过程中形成的所有文档语言简练、前后一致、易于理解以及语句无歧义。
b.易学习性
易学习性是与用户为学习软件应用（例如运行控制、输入、输出）所花的努力有关的软件属性。该特征要求研制方提供的用户文档（主要是《计算机系统操作员手册》、《软件用户手册》和《软件程序员手册》）内容详细、结构清晰以及语言准确。
c.易操作性
易操作性是与用户为操作和运行控制所花的努力有关的软件属性。该特征要求软件的人机界面友好、界面设计科学合理以及操作简单等。
3.4 效率特征指标
效率特征可以细化成时间特征和资源特征。对软件的效率特征评价采用定量方法。
a.输出结果更新周期
输出结果更新周期是软件相邻两次输出结果的间隔时间。为了整个系统能够协调工作，软件的输出结果更新周期应该与系统的信息更新周期相同。
b.处理时间
处理时间是软件完成某项功能（辅助计算或辅助决策）所用的处理时间（注意：不应包含人机交互的时间）。
c.吞吐率
吞吐率是单位时间软件的信息处理能力（即各种目标的处理批数）。未来的社会情况复杂、信息众多，软件必须具有处理海量数据的能力。吞吐率就是体现该能力的参数。随着信息的泛滥，要求软件的吞吐率应该达到数百批。
d.代码规模
代码规模是软件源程序的行数（不包括注释），属于软件的静态属性。软件的代码规模过大不仅要占用过多的硬盘存储空间，而且显得程序不简洁、结构不清晰，容易存在缺陷。
//抄百度的明天可能再改改
-
接口：接口是不可直接实例化的特性集合的声明，即其对象不能直接实例化，需要通过类来实现，实现接口的类需要实现在接口中声明的方法
-
抽象类：抽象类是至少包含一个没有实现的方法的类，如果在一个抽象类中所有的方法都没有实现，则称其为纯抽象类
-
相同点：都不能直接实例化
-
不同点：在只支持单继承的语言中，一个类只能有一个直接父类，但是却可以实现多个接口