软件工程简介

软件工程概述

软件工程的定义与特征
软件 = 程序 + 文档 + 数据

1. 软件的特征
   软件是无形的、不可见的逻辑实体
   软件是设计开发的，而不是产生制造的
   软件在使用过程中没有磨损、老化的问题
   软件是定制开发的
   软件是复杂的
   软件的开发成本高
   软件易于复制
   软件质量要求高

软件开发过程中，软件测试、系统维护等任务将占据工程的很大一部分成本

2. 软件技术的演化（四个阶段）
   第一阶段：程序设计阶段。1946年到60年代初，个体手工方式
   第二阶段：程序系统阶段。60年代初到70年代初，小组化生产，出现软件危机
   第三阶段：传统软件工程阶段。20世纪70年代中期至80年代中期，把工程化的思想引入到软件开发中，结构化方法的发展，规模化软件开发
   第四阶段：面向对象阶段。20世纪80年代中期至今，面向对象方法学发展，软件定制和满足客户需求

发展趋势
软件服务：云服务、大数据服务
多样性：中间件
开放性：新型中间件平台

软件工程的起源和概念

软件危机：（两个方面的问题）
如何开发软件
如何维护软件
表现：
规模大、复杂度增加
供需差增大
价格昂贵
开发速度慢
质量难以保证
解决方法
重视需求分析，明确与确切表达需求
重视与客户沟通和交流
统一的、公认的方法论和规则指导
重视设计和实现过程中的资料
充分的检测工作
软件工程
软件工程 = 方法 + 过程 + 工具
工程化思想：把软件看作是一个工程产品
两个方面：1、软件开发技术 2、软件工程管理
产生原因：1、缺乏软件过程控制能力 2、能力成熟模型
软件工程管理 = 质量 + 成本 + 工期

软件工程框架
软件工程可以定义为三元组：<目标，原则，活动>

软件工程框架的作用：

1. 给出了软件所设计软件工程的工程要素
2. 给出两个要素之间的关系
3. 给出了软件工程学科所研究的主要内容

目标
生产具有正确性、可用性以及开销合宜的产品
正确性：指软件产品达到预期功能的程度
可用性：指软件基本结构、实现及文档为用户可用的程度
开销合宜：指软件开发、运行的整个开销满足用户要求的程度
活动
生产一个最终满足需求且达到工程目标的软件产品所需要的步骤
主要包括需求、设计、实现、确认和支持等活动
需求：定义问题，建立系统模型
设计：在需求分析的基础上，给出系统的软件设计方案（设计包括总体设计和详细设计）
实现：把设计结果转换为可执行的程序代码
确认：确认活动贯穿于整个开发过程（主要活动：需求复审、设计复审及其程序测试。主要任务是：软件测试）
支持活动：支持活动包括修改和完善。它为系统的运行提供完善性维护、纠错性维护和适应性维护

软件过程

软件过程
开发逻辑，是获取正确软件的关键
软件过程框架：
组织与管理框架：过程改进活动及角色与职责
技术与工具框架：技术及自动化活动工具
框架活动：

1. 沟通：软件相关共利益者之间的交流和协作
2. 策划：为软件开发制定计划
3. 建模：创建软件开发所涉及的模型和设计方案
4. 构建：编码和测试活动
5. 部署：将软件部署到运行环境，并交付给用户

软件工程生存周期模型
软件也有一个从生到死的过程，这个过程一般称为软件生存周期或生命周期（Software Development Life Cycle）
软件生存周期包括可行性分析、项目计划、需求分析、软件设计、编码与测试、维护等阶段，每个阶段有包含一系列的活动。

常用的软件生存周期模型

结构化分析

结构化分析方法的概念

结构化方法是一种特定的软件开发方法学（20世纪70年代由Eward Yourdon, Tom Demarco等人提出），一种系统化的软件开发方法。
结构化分析方法
结构化设计方法
结构化程序设计方法

结构化分析模型

结构化分析方法是一种传统的系统建模技术，其中需求分析非常重要，需求分析的重要过程是需求建模。主要目标为：

1. 描述客户需要；
2. 建立软件设计的基础
3. 定义在软件完成后可以确认的一组需求

分析模型：为基于计算机系统提供必须的信息、功能和行为域的说明。模型是对系统某个方面的抽象，抛弃了具体的细节，对系统中最突出的特征做简化。
分析模型元素：

1. 基于场景的元素
2. 基于过程的活动序列的元素
3. 基于类的元素
4. 行为元素
5. 面向信息流的元素
6. 基于数据的元素

目标与原则：分析模型的所有元素都可以直接映射到设计模型。
创建分析模型时应遵循的原则：

1. 模型应关注在问题或业务域内可见的需求，抽象的级别相对较高；
2. 分析模型的每个元素都能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解；
3. 基于基础机构和其他非功能的模型应推延到设计阶段再考虑；
4. 最小化整个系统内的关联；
5. 确认分析模型为所有利益者都带来价值；
6. 尽可能保持模型简洁。

结构化需求分析：
用户需求一般用自然语言描述
系统需求必须用较专业的方式来描述
模型是软件设计的基础，也是创建规约的基础
需求分析的原则：

1. 表示和理解问题的信息域
2. 定义软件将完成的功能
3. 表示软件的行为（作为外部事件的结果）
4. 划分描述信息、功能和行为的模型，从而使得可以以层次的方式揭示细节；
5. 分析过程应从要素信息移向细节实现。

系统模型从以下不同的角度表述系统：

1. 从外部来看：它是对系统分析上下文或系统环境建模；
2. 从行为上看：它是对系统行为建模；
3. 从结构上看：它是对系统的体系结构和系统处理的数据结构建模。

结构化的需求分析模型：

1. 系统行为模型：数据流模型，用来描述系统中的数据处理过程；状态转换模型，用来描述系统如何对事件做出响应。
2. 实体—关系模型：关心的是寻找系统中的数据及其之间的关系，却不关心系统中包含的功能。

结构化分析模型结构：

1. 结构化分析模型结构的核心是数据字典（Data Dictionary，DD），包含了软件使用或产生的所有数据对象描述的中心库

2. 分析模型结构的中间层有三种视图：
   数据流图（DFD，Data Flow Diagram）：有两个目的：一是指明数据在系统中移动时如何被变换；二是描述对数据流进行变换的功能和子功能。
   实体—关系图（E-RD，Entity-Relationship Diagram）：描述数据对象间的关系，用来进行数据建模活动的记号。
   状态转换图（STD，State Transition Diagram）：指明作为外部事件的结果，系统将如何动作。

3. 分析模型结构的外层是规约描述：
   在实体—关系图中每个数据对象的属性可以使用数据对象来描述
   在数据流中出现的每个加工/处理的功能描述包含在加工规约中
   软件控制方面的附加信息包含在控制规约中

面向数据流的建模是结构化需求分析的方法之一：采用自顶向下逐层分解，描绘满足用户要求的软件模型。
表示：数据流图——描述系统处理过程
数据字典——模型中的数据信息集合
数据流图符号：

建模：

1. 数据流图（DFD图）：表达系统功能模型的工具，包含数据流、数据存储、加工、数据源、数据潭等。

2. 数据字典：定义数据流和数据存储。数据字典是分析模型中出现的所有名字的一个集合，并包括有关命名实体的描述。作用：一是它是所有名字信息管理的有效机制；二是它作为连接软件分析、设计、实现和进化阶段的开发机构的信息存储。组成元素：数据流、数据流分量、数据存储、处理（对于处理阶段，可用输入—处理—输出（IPO，Input-Process-Output）视图更方便）。
   

3. 定义加工小说明：判定表或判定树等。

结构化分析过程

1. 建立系统的功能模型
   使用工具：数据流图DFD
   建立系统环境图（顶层数据流图），确定系统边界
   自顶向下，逐步求精，建立系统的层次数据流图
2. 建立数据字典
   使用工具：+、|、{}等
   定义数据流、数据存储、数据项
3. 给出加工小说明
   工具：判定表、判定树
   描述一个加工做什么，即加工逻辑，也包括执行条件、优先级、执行频率、出错处理等