jackfiled
9111affeec
All checks were successful
Build blog docker image / Build-Blog-Image (push) Successful in 1m34s
Reviewed-on: #4
236 lines
12 KiB
Markdown
236 lines
12 KiB
Markdown
---
|
||
title: 软件工程
|
||
tags:
|
||
- 软件工程
|
||
- 学习资料
|
||
date: 2024-06-12 20:27:25
|
||
---
|
||
|
||
你说得对，但软工无非就是瀑布模型规定的那六项基本活动及其变化，然后细化到需求分析需要用UML规范化表示的建模方法，后面就是如何通过框架模块的结构确定软件对象有哪些并分配功能。当然这其中也涉及到模块独立性的设计原则以及面向对象的7个设计原则，之后就是软件测试的白盒和黑盒方法。
|
||
|
||
## 软件工程概述
|
||
|
||
软件是包括程序、数据及其相关文档的完整集合。IEEE的定义是，软件是计算机程序、规程以及运行计算机系统所需要的文档和数据。
|
||
|
||
在20世纪的60年代，随着计算机软件引用领域增多，软件规模不断扩大，软件系统功能多样、逻辑复杂，不断扩充，从而导出系统开发出现不良的后果：
|
||
|
||
- 软件开发计划难以制定和实施
|
||
- 软件开发费用和进度失控
|
||
- 软件的质量无法让用户满意
|
||
- 软件无法维护
|
||
- 软件没有适当的文档资料
|
||
|
||
这就是**软件危机**。解决软件危机的方法就是软件工程。
|
||
|
||
F.L. Bauer提出，软件工程就是为了经济地获得能够在实际机器上搞笑运行的可靠软件而简历和使用的一系列高的工程化原则。Barry Boehm提出，软件工程是运行现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。Richard E. Fairley则认为软件工程学是为了在成本限额之内按时完成开发和修改软件产品所需的系统生产和维护的技术和管理的学科。IEEE计算机学会将软件工程定义为应用系统化的、规范化的、定量的方法来开发、运行和维护软件以及对于这其中各种方法的研究。
|
||
|
||
软件工程中的三要素为：
|
||
|
||
- 方法：给出需求、设计建模、编码和测试的方法
|
||
- 工具：给出各种自动或者半自动的软件支撑环境
|
||
- 过程：将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的，给出指导软件开发所需要的过程模型。
|
||
|
||
软件工程的目标是：
|
||
|
||
- 现实目标：在一个特定的项目中，在给定成本和时间的前提下，开发出满足用户需求且具有正确性、可用性等因素的软件产品。
|
||
- 终极目标：摆脱手动生产软件的状况，逐步实现软件研制和维护的自动化。
|
||
|
||
软件工程的原则是：
|
||
|
||
- 选择合适的开发模型
|
||
- 采用合适的设计方法
|
||
- 提供高质量的工程支持力度
|
||
- 重视开发过程的管理
|
||
|
||
## 软件生命周期模型
|
||
|
||
软件工程过程，是为了获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动。主要活动有：（1）编写软件规格说明；（2）软件开发；（3）软件确认；（4）软件演进。
|
||
|
||
软件生命周期是指软件产品从考虑其概念开发，直到废弃为止的整个时期，总的包括概念阶段，分析与设计阶段，构造阶段，移交和运行阶段等不同的时期。总共存在六个步骤：
|
||
|
||
1. 制定计划。
|
||
2. 需求分析
|
||
3. 软件设计
|
||
4. 程序编码
|
||
5. 软件测试
|
||
6. 运行维护
|
||
|
||
软件生命周期模型是一个框架，描述从软件需求定义直到软件经使用后废弃为止，跨越整个生存期的软件开发，运行和维护所实施的全部过程、活动和任务，同时描述生命周期不同阶段产生的软件工件明确活动的执行角色。
|
||
|
||
### 传统生命周期模型
|
||
|
||
#### 瀑布模型
|
||
|
||
|
||
|
||
瀑布模型强调在软件实现之前必须进行分析和设计工作，同时也造成了模型缺乏灵活性的问题，特别是面对软件的需求不明确或者不准确的情况时，模型的风险控制能力较弱。
|
||
|
||
因此瀑布模型中存在一个“do twice"的概念，即在交付给使用者之前的软件开发要做两次。
|
||
|
||
#### 演化模型
|
||
|
||
烟火模型提倡进行两次开发。第一次开发得到实验性的原型产品，其目的是探索可行性，弄清软件的需求。第二次在第一次的基础上获得较为满意的软件产品。
|
||
|
||
|
||
|
||
演化模型在明确用户需求和降低开发风险的同时，也带来了难以管理、结构较差和技术不成熟的问题，同时可能抛弃掉瀑布模型的文档控制优点。因此演化模型更多适合于需求不清晰的小型或中型系统，适用于开发周期较短的场合。
|
||
|
||
#### 增量模型
|
||
|
||
|
||
|
||
但是在增量模型中难以确定增量的粒度，同时确定所有的需求比较困难。
|
||
|
||
#### 喷泉模型
|
||
|
||
|
||
|
||
各个开发阶段没有特定的次序，可以并行进行，也可以在某个开发阶段中随时补充其他任何开发阶段。但是难以管理，工作计划需要随时更新。
|
||
|
||
#### V模型和W模型
|
||
|
||
将测试活动提前，使得瀑布模型能够驾驭风险。
|
||
|
||
|
||
|
||
#### 螺旋模型
|
||
|
||
|
||
|
||
四个象限：制定计划、风险分析、实施工程、客户评价。
|
||
|
||
#### 构件组装模型
|
||
|
||
利用模块化思想将整个系统模块化，并在一定构件模型的支持下复用构件库中软件构件，通过组装高效率、高质量地构造软件系统。构件组装模型本质上是演化模型。
|
||
|
||
|
||
|
||
充分利用软件复用，提高开发效率。允许多个项目同时开发，降低了费用，提高了可维护性。但是缺乏通用的构件组装结构标准，风险较大，同时构件可重用性和系统高效性之间不易协调。
|
||
|
||
#### 快速应用开发模型
|
||
|
||
|
||
|
||
增量型的软件开发过程，强调极短的开发周期。
|
||
|
||
#### 原型方法
|
||
|
||
考虑到完整而准确的需求规格说明是很难一次性得到的。
|
||
|
||
原型方法通过在获得一组基本需求之后，通过快速分析构造出一个小型的软件系统原型，满足用户的基本要求。
|
||
|
||
原型方法可以分为废弃策略和追加策略。废弃策略中的原型方法主要是探索和实验的目的，追加策略主要是进化型，将原型方法的思想拓展到软件开发的全过程中，适用于需求经常变动的软件项目。
|
||
|
||
原型提供了用户和开发人员良好的沟通手段，易于被人们接受。但是对于大型系统和存在大量运算、逻辑性较强的程序模型可能不太适用。同时可能会造成文档容易被忽略，同时建立原型的许多工作会被浪费掉。
|
||
|
||
### 新型软件生命周期模型
|
||
|
||
#### RUP
|
||
|
||
Rational Unified Process的生命周期在时间上被分解为四个顺序的阶段：
|
||
|
||
- 初始阶段：通过业务场景了解业务并确定项目的边界。
|
||
- 细化阶段：分析问题领域，建立适合需求的软件体系结构基础，编制项目计划，完成项目中技术要求高，风险大的关键需求的开发。
|
||
- 构造阶段：所有剩余的技术构建和稳定业务需求功能开发完成，所有功能被详细测试。
|
||
- 移交阶段：确保软件对最终用户是可用的。
|
||
|
||
总的来说，以用例为驱动的，软件体系结构为核心，应用迭代及增量的新型软件生命周期模型。
|
||
|
||
RUP由9个核心工作流构建每个迭代的主要活动。分别是6个核心过程工作流：业务建模、需求、分析和设计、实现、测试、部署和三个核心支持工作流：配置和变更管理、项目管理和环境。
|
||
|
||
#### 敏捷建模
|
||
|
||
敏捷建模由一系列的价值观、原则和实践组成，是一种快速软件开发的思想代码，代表性的应用有极限编程。
|
||
|
||
|
||
|
||
极限编程中的需求分析要求开发人员和客户一起将各种需求变成小的需求模块（User Story），这些模块将会被组合或者分解为更小的模块，成为Story Card。
|
||
|
||
极限编程的设计和开发强调测试驱动的开发，提倡在开发过程中常常进行设计复核、代码复核和重整和优化。
|
||
|
||
极限编程的测试通常集成在设计和开发过程中，并且提倡持续集成（CI），在开发过程中经常进行整合并运行单元测试。
|
||
|
||
## 软件需求分析
|
||
|
||
软件开发人员通过和软件产品的使用者和拥有者交流和调研获取的相关业务职能、业务知识和业务流程等信息，并对这些信息进行分析和整理后形成的有关该软件产品必须提供的功能和性能等指标的规格描述。
|
||
|
||
软件需求分析的任务就是通过一个无二义性的方式，将软件的需求严格地、形式的表达出来，并为用户和软件开发人员所接受。
|
||
|
||
软件需求分析的目标是借助于业务系统的逻辑模型导出软件系统的逻辑模型。解决目标系统“做什么”的问题。
|
||
|
||
在软件需求建模中需要遵循三条原则：
|
||
|
||
- 问题的信息域必须被表示和理解
|
||
- 软件将完成的功能必须被定义
|
||
- 软件的行为（作为外部事件的结果）必须被表示
|
||
|
||
软件需求工作分成软件需求的获取和软件需求的管理两个部分，其中管理负责需求的确认、需求的跟踪和需求的变更控制等内容。
|
||
|
||
软件的需求可以分为功能需求和非功能需求，其中非功能需求包括性能需求、环境需求和可靠性需求等。
|
||
|
||
软件需求的两个产出：
|
||
|
||
1. 用户需求说明书：对收集到的所有需求信息进行整理和分析，消除错误，归纳与总结共性的用户需求。
|
||
2. 软件需求规格说明书：从用户需求说明书出发，对比较复杂的需求进行建模分析，细化所有的软件功能，剔除不合理的部分，增加需要的部分，最后给出系统的逻辑模型。
|
||
|
||
### 面向对象的需求分析方法
|
||
|
||
UML，即统一建模语言，是面向对象分析与设计的一种标准表示。
|
||
|
||
4+1视图，通过模型来描述系统的结构和行为，或者说静态结构和动态结构，以用例视图为核心描述系统的不同视图。
|
||
|
||
|
||
|
||
#### 领域模型
|
||
|
||
领域模型是针对某一个特定领域内概念类或者对象的抽象化可视化表示。
|
||
|
||
|
||
|
||
在领域模型中使用类图表达概念及其关系，概念类之间的关系有关联、继承、组合、聚合和依赖等关系。
|
||
|
||
#### 用例模型
|
||
|
||
用途模型由用例图和解释实现用例过程的用例描述组成。用例是从使用系统的角色出发描述使用者与系统或者系统某个功能之间的交互场景，用来描述用户对于系统的功能需求。
|
||
|
||
用例模型一般由四个部分组成，分别是用例图、用例说明、系统顺序图和操作契约，其中前两者是必需的，后两者是可选的。操作契约一般包括三部分的内容：对象的创建或者消除，对象之间关联的创建和删除、对象的属性修改。
|
||
|
||
## 软件设计
|
||
|
||
软件设计的目标是根据需求分析的结果设想并设计软件，从概念模型出发得到物理模型。软件设计包括软件系统的结构设计、处理方式的设计、数据结构和数据存储的设计和界面、可靠性设计等。
|
||
|
||
软件的设计应该注意软件结构的模块化。模块具有独立性和耦合性。
|
||
|
||
模块的内聚性是模块功能强度的度量。
|
||
|
||
|
||
|
||
模块的耦合性是针对模块之间连接紧密程度的度量。
|
||
|
||
|
||
|
||
面向对象的设计原则：
|
||
|
||
- 单一职责原则
|
||
- 开闭原则
|
||
- 狄米特原则
|
||
- 开闭原则
|
||
- 依赖倒置原则
|
||
- 里氏替换原则
|
||
- 接口隔离原则
|
||
|
||
### 面向对象的设计方法
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|