软件工程笔记

软件概念

软件

软件 = 程序+数据+文档

• 程序
  按事先设计的功能和性能需求执行的指令序列
• 数据
  用于程序正常操纵信息的数据结构
• 文档
  与程序开发、使用、维护相关的图文资料

软件危机

在计算机软件的开发和维护过程中所遇到的一系列严重问题，通常导致开发效率降低、开发质量降低。

产生原因

• 客观上：
  逻辑部件 规模庞大
• 主观上：
  忽视需求分析（例如：错误地认为有一个目标的概括描述就可以着手编写程序，许多细节以后再补充）
  错误认为：软件开发=程序编写
  轻视软件维护

软件工程

1. 应用系统化的、学科化的定量的方法，来开发维护软件，将工程应用到软件
2. 对1中各种方法的研究
3. 要素：方法（包含：结构化方法、面向对象的方法）、工具、过程

四个发展阶段

1. 传统软件工程阶段
2. 对象工程
3. 过程工程
4. 构建工程

软件过程模型

软件过程，软件开发中所遵循的路线图。

概念

软件过程模型是从软件项目需求定义至软件运行维护的整个生命周期过程中系统开发、运行和维护所实施的全部过程。
为软件开发的各个阶段提供一种过程规范。

常用模型

1. 瀑布模型（经典生命周期模型）
2. 增量过程模型：增量模型、RAD模型
3. 演化过程模型：原型模型、螺旋模型
4. 喷泉模型

瀑布模型

特点

1. 分为固定的几个阶段，次序固定，自上而下
2. 以文档为驱动
3. 阶段间具有顺序性和依赖性
4. 每个阶段必须完成规定的文档，每个阶段结束前完成文档审查，及早改正错误

缺点

1. 实际项目很少遵守瀑布模型提出的顺序，需求可能变更
2. 客户通常难以清晰描述所有需求
3. 客户需要有耐心，只有项目完成才能看到所开发的软件

变体

V模型：强调了过程中的质量保证

增量过程模型

用于不确定因素多、资金到位不足、无法提出完整需求的开发，增量可并行开发、独立开发

从部分需求出发、先建立不完整系统、再反复扩充完善

增量模型采用了基于时间的线性序列 ， 每个确定线性序列都会输出该软件的一个“增量”。

特点

• 增量
  小而可用的软件
• 特点
  在前面增量的基础上开发后面的增量

优点

1. 增量包概念的引入 ， 以及它不需要提供完整的需求 。 只要有一个增量包出现，开发就可以进行。
2. 在项目的初始阶段不需要投入太多的人力资源。
3. 增量可以有效地管理技术风险。

缺点

1. 每个增量必须提供一些系统功能，有时开发者难以根据客户需求给出大小适合的增量

原型模型

客户定义一个总体目标集，但是他们并不清楚系统的具体输入输出；或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式。此时，原型法是很好的选择 。

优点

1. 快速为用户提供一个可以看到的原型软件
2. 可有效应对需求的不确定性
3. 原型系统可以逐步演化为最终系统，避免浪费人力

缺点

1. 整个软件可能是随意搭成的 ， 开发者没有考虑整体软件质量与长期的可维护性
2. 采用了一些折中手段让系统快速运行起来，比如不合适的操作系统、开发语言、低效算法等

螺旋模型

该模型结合了瀑布模型和原型模型的特点。螺旋模型强调风险管理，因此该模型适用于大型系统的开发。
螺旋模型沿着螺线旋转 ，在笛卡尔坐标的四个象限上分别表达了四个方面的活动 ：

• 制定计划 。
  确定软件目标 ， 选定实施方案 ， 弄清项目开发的限制条件。
• 风险分析。
  分析所选方案，考虑如何识别和消除风险。
• 实施工程。
  实施软件开发。
• 客户评估 。
  评价开发工作 ， 提出修正建议 。

优点

1. 支持用户需求的动态变化。
2. 原型可看作形式的可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便 。
3. 特别强调原型的可扩充性和可修改性 ， 原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力。
4. 为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险 。

缺点

1. 如果每次迭代效率不高，致使迭代次数过多将会增加成本并推迟提交时间
2. 使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高

适应场合

支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明 、 面向过程 、 面向对象等多种软件开发方法，是一种具有广阔前景的模型

基于构建模型

软件构件由厂家作为产品供应，通过定义良好的接口提供特定功能，这些构件能够集成到正在构建的软件中。
本质上是演化模型，具有很多螺旋模型的特点，差别是采用了预先打包的软件构件开发应用系统

四个阶段

• 需求
  与其它模型相同，这里不再赘述。
• 组件分析
  根据需求规格搜索可满足该需求的组件 。 通常情况下，没有完全匹配的情况，因而组件通常需要加以修改。
• 系统设计
  与其它模型的系统设计有所不同，因为该模型是基于重用的。设计者必须考虑到重用的概念，但遗憾的是，如果没有可重用的组件，还要设计新的软件。用的。设计者必须考虑到重用的概念，但遗憾的是，如果没有可重用的组件，还要设计新的软件。
• 开发和集成
  在这个阶段 ， 组件集成到系统中。

优点

1. 能最大程度复用已经开发的软件，减少开发费用，缩短开发周期

缺点

1. 模型复杂
2. 需求可能折中 ， 进而导致系统可能不完全符合需求
3. 无法完全控制所开发系统的演化

统一过程模型

一种用例驱动，以架构为核心，迭代并且增量的软件过程
结合面向对象分析与设计方法，最重要的体现是统一建模语言 （Unified Modeling Language, UML ）
时间上有四个顺序阶段 ： 初始阶段 、 细化阶段 、 构造阶段和交付阶段，每个阶段涉及9 种核心工作流的多种工作流

优点

1. 多次迭代，每次迭代有不同工作重点，有效识别风险
2. 采用了面向对象的分析与设计方法 ，且增量开发

缺点

1. 过程比较复杂 ， 可能导致效率低下
2. 必须要有严格的过程管理 ， 架构不正确也将引起全面错误

敏捷过程模型

特点

增量、快速、可执行原型来适应不可预测的变更

12原则

1. 尽早 、持续地交付有价值的软件来使客户满意。
2. 即使在开发的后期，也欢迎需求变更。
3. 交付的时间间隔越短越好。
4. 业务人员和开发人员必须天天都在一起工作。
5. 围绕有积极性的个人构建项目。
6. 最富有效果和效率的信息传递方法是 面对面交谈。
7. 可运行软件是进度的首要度量标准。
8. 敏捷过程提倡 可持续的开发速度。
9. 不断地 关注优秀的技能和好的设计会增强敏捷能力。
10. 简单（使不必做的工作最大化的艺术）是必要的。
11. 最好的架构、需求和设计出自于自组织团队。
12. 每隔一定时间，团队会 反省如何才能更有效地工作。

主要敏捷软件过程

• 极限编程
  只对即时需求做设计，不考虑长远需求
  沟通 、 简明 、 反馈 、 鼓励 、 尊重
• 自适应软件开发
  分为思考协作和学习个阶段
• 动态系统开发方法
  一个应用系统80% 的功能可以在20%的时间内完成

软件开发面临的三大问题

1. 提前预测哪些需求是稳定的而哪些需求会变更非常困难。同样，预测项目进行中客户优先级的变更也很困难。
2. 对很多软件来说，设计和构建是交错进行的。
3. 从制定计划的角度来看，分析、设计、构建和测试并不像我们所设想的那么容易预测。

解决方法：增量、快速、可执行原型来适应不可预测的变更—敏捷开发

需求分析

定义

确定系统必须具有的功能和性能，系统要求的运行环境并预测系统前景。以一种清晰、简洁、一致且无二义性的方式，陈述待开发系统的一个集合。

过程

需求获取->需求提炼->需求描述（撰写需求规格说明书）->需求验证

需求规格说明书

• 确定系统的运行环境要求
  硬件环境（网络、服务器等）
  软件环境（ 操作系统、 数据库等 ）
• 系统的功能性需求
  系统需要支持的若干功能点
  输入
  输出
  存储
  计算
• 系统的非功能性需求
  响应时间
  可靠性
  安全性
  可扩展性
• 系统接口

需求模型

基于场景的模型

场景建模描述用户如何与系统以及使用软件时出现的特定活动序列进行交互

用例图

• UML 用例图(User Case Diagram)
  从系统使用者的角度所理解的系统总体功能
• 参与者 （Actor ）
  在系统外部与系统直接交互的人或事物(如系统、进程）
  参与者是角色(role) 而不是具体的人
  参与者作为外部用户( 而不是内部)与系统发生交互作用
• 用例（Use Casxe ）
  系统外部可见的一个系统功能单元。
  系统的功能由系统单元所提供，并通过一系列系统单元与 一 个或多个参与者之间交换的消息所表达。
• 关系（Relationship)
  参与者与用例之间的关联关系，用实线表示，表示参与者与用例之间的交互，参与者使用这个用例功能。
  泛化关系
  用例与用例之间的关系：① 包含关系 ② 扩展关系
  
  • 包含关系
    用带<include>的虚线表示，A为基用例，B为包含用例时，A指向B。
    包含用例必须被执行 ，不需要满足某种条件
    包含用例的执行不会改变基用例的行为
  • 扩展关系
    用带<extend>的虚线表示，A为扩展用例，B为基用例时，A指向B。
    扩展用例是可选的，如果缺少扩展用例不会影响到基用例的完整性
    扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为

活动图

泳道图

类模型

类是组具有相同数据结构和相同操作的对象集合。
类是一组具有相同数据结构和相同操作的对象集合。类可视为一个具有类似特性与共同行为的对象摸板，可用来产生对象。
类是对象的抽象，而对象是类的具体实例。

类（Class ）在UML中通常以实线矩形框表示。
• 类的名称（Name ）必须的，用于同其它类进行区分
• 类的属性（Attribute ）
• 类的操作 （Operation）

类之间的关系

• 关联关系
1. 命名关联
2. 命名关联中的角色
3. 确定关联的多重性
• 聚合/复合关系
1. 聚合关系描述的是部分与整体的关系， UML中使用从部分指向整体的端点带有空心菱形的线段表示
2. 复合关系描述的也是部分和整体的关系，但是语义更强，部分的生命周期取决于整体的生命周期， UML中组成使用从部分指向整体的 UML中组成使用从部分指向整体的端点带有实心菱形的线段表示
• 泛化关系
1. 描述类的一般和具体之间的关系，表明“是一种”关系
2. UML 中泛化关系使用从子类 （ 具体 ） 指向超类 （ 一般 ） 的带有空三角形箭头的实线表示。

行为模型