南阳理工学院李亚红软件工程.docx
《南阳理工学院李亚红软件工程.docx》由会员分享，可在线阅读，更多相关《南阳理工学院李亚红软件工程.docx（69页珍藏版）》请在冰豆网上搜索。
南阳理工学院李亚红软件工程
南阳理工学院李亚红软件工程
软件工程--
原理、方法与应用（第三版）
主要内容
v绪论
v上篇-传统软件工程
v软件生存周期与软件过程
v结构化分析与设计
v中篇-面向对象软件工程
v面向对象与UML
v需求工程与需求分析
v面向对象分析
v面向对象设计
v编码与测试
v下篇-软件工程的近期进展、管理与环境
v软件维护
v软件复用
v软件工程管理
v软件质量管理
v软件工程环境
v软件工程高级课题
第一章绪论
v软件和软件危机
v软件工程学的范畴
v软件工程的发展
v软件工程的应用
v软件工程的教学
Ø软件是能够完成预定功能和性能的可执行的计算机程序，包括使程序正常执行所需的数据，以及有关描述程序操作和使用的文档（R.S.Pressman）
Ø软件=程序（包括数据）+文档
Ø程序是为了解决某个特定问题而用程序设计语言描述的适合计算机处理的语句序列
Ø数据是使程序能正常操纵信息的数据结构
Ø文档是与程序开发，维护和使用有关的图文材料
❑软件与硬件的不同
❑软件开发不同于硬件设计
❑软件生产与硬件制造不同
❑软件维护不同于硬件维修
❑软件是逻辑的，而不是物理的
⏹软件开发与人关系密切
⏹软件开发成本大
⏹软件生产是简单的拷贝
⏹软件不会磨损和老化
⏹软件受环境影响大
⏹软件维护易产生新的问题
⏹软件危机的表现
✓对软件开发成本和进度的估算很不准确
✓用户很不满意
✓质量很不可靠
✓没有适当的文档
✓软件成本比重上升
✓供不应求：
软件开发生产率跟不上计算机应用迅速深入的趋势
硬件/软件成本变化趋势
软件技术进步落后于需求增长
⏹软件危机的原因
•客观：
软件本身特点
----逻辑部件
----规模庞大、复杂度高
•主观：
不正确的开发方法
----忽视需求分析
----个人化方式：
软件开发=程序编写
----轻视软件维护
⏹解决途径
•组织管理
----工程项目管理方法
•技术措施
----软件开发技术与方法
----软件工具
⏹促使了软件工程的诞生
⏹按工程化的原理和方法组织软件开发是软件开发中的问题一个主要出路
2.软件工程学的研究范畴
2.软件工程学的研究范畴
⏹软件开发方法
⏹为软件开发提供了¡°如何做¡±的技术
⏹个性化方法-〉结构化方法-〉面向对象方法-〉软件复用
⏹软件工具
⏹为软件开发提供了自动的或半自动的软件支撑环境
⏹单个工具-〉工具箱、集成工具-〉环境
⏹软件工程管理
⏹目的：
为了按进度及预算完成软件计划
⏹内容：
成本估算、进度安排、人员组织、质量保证等
❒三种编程范型
❒过程式编程范型
❒程序由一组被动数据和一组能动过程组成
❒程序=数据结构+算法
❒着眼于程序的过程和基本控制结构，粒度最小
❒面向对象编程范型
❒数据及其操作被封装在对象中
❒程序=对象+消息
❒着眼于程序中的对象，粒度比较大
❒基于构件技术的编程范型
❒构件是通用的、可复用的标准化对象类
❒程序=构件+架构
❒着眼于适合整个领域的类对象，粒度更大
过程式和面向对象的编程范型
❒三代软件工程
⏹传统软件工程
⏹结构化分析→结构化设计→面向过程的编码→软件测试
⏹面向对象软件工程
☐
☐传统的软件过程
☐软件演化模型
☐形式化方法模型
☐统一过程和敏捷过程
☐软件可行性研究
1.软件生存周期
典型的软件生存周期
软件生存周期的主要活动
⏹需求分析
⏹明确需要解决的问题（从用户的视角）
⏹建立需求模型：
功能、性能、约束、接口等
⏹软件分析
⏹从开发人员的视角对软件进行分析
⏹建立分析模型：
软件的逻辑模型
⏹软件设计
⏹确定软件的总体结构和各部件的数据结构和操作
⏹建立软件设计模型：
考虑实现技术和平台
⏹编码
⏹用程序设计语言将设计文档翻译成源程序
⏹建立软件实现模型：
包含现有软件构件包
⏹软件测试
⏹发现程序中的错误、提高软件质量
⏹单元测试、集成测试、确认测试、系统测试
⏹运行维护
软件过程与软件生存周期
2.传统的软件过程
⏹传统的过程模型
⏹瀑布模型
⏹waterfallmodel
⏹基于软件生存周期的线性开发模型
⏹快速原型模型
⏹rapidprototypemodel
⏹基于原型的迭代化开发模型
瀑布模型
瀑布模型
⏹特点
⏹阶段的顺序性和依赖性
⏹推迟实现的观点
⏹质量保证的观点
⏹存在问题
⏹不适合需求模糊的系统
⏹开发初始阶段很难彻底弄清软件需求
快速原型模型
快速原型模型
⏹特点
⏹“逼真”的原型可以使用户迅速作出反馈
⏹循环回溯和迭代：
非线性模型
⏹使用快速开发工具
⏹种类
⏹渐进型：
对原型补充和修改获得最终系统
⏹抛弃型：
原型废弃不用
⏹应防止的偏向
⏹舍不得抛弃，从而影响软件质量
3.软件演化模型
⏹演化开发模型：
使所开发的软件在迭代中逐步完善
⏹增量模型（incrementalmodel）
⏹螺旋模型（spiralmodel）
⏹构件集成模型（componentintegrationmodel）
增量模型
增量模型
⏹增量
⏹小而可用的软件
⏹第一个增量通常是软件的核心
⏹特点
⏹在前面增量的基础上开发后面的增量
⏹每个增量的开发可用瀑布或快速原型模型
⏹每个增量开发的顺序性和总体的迭代性相结合
螺旋模型
螺旋模型
⏹特点
⏹瀑布模型（顺序性、边开发边复审）+快速原型（迭代性）
⏹风险分析-〉发现、控制风险
⏹一个螺旋式周期
⏹计划：
确定目标，选择方案，选定完成目标的策略
⏹风险分析：
从风险角度分析该策略
⏹开发：
启动一个开发活动
⏹评审：
评价前一步的结果，计划下一轮的工作
面向对象的基本概念
⏹对象Object
⏹类Class
⏹继承Inheritance
⏹消息Message
⏹面向对象
⏹对象+类+继承+消息通信
构件集成模型
构件集成模型
⏹构件
⏹在某个领域内具有通用性，可以复用的软件部件
⏹将可以复用的构件存储起来，形成构件库
⏹特点
⏹面向对象
⏹基于构件库
⏹融合螺旋模型特征
⏹支持软件开发的迭代方法
⏹软件复用
4.形式化方法模型
⏹形式化方法模型：
基于程序变换和验证技术的软件开发
⏹转换模型（transformationalmodel）
⏹净室模型（cleanroommodel）
转换模型
转换模型
⏹开发过程
⏹确定形式化需求规格说明书
⏹进行自动的程序变换
⏹针对形式化开发记录进行测试
⏹特点
⏹形式化软件开发方法
⏹形式化需求规格说明
⏹变换技术
⏹程序自动生成技术
⏹确保正确
净室模型
净室模型
⏹净室思想
⏹在分析和设计阶段消除错误
⏹在“洁净”状态下实现软件制作
⏹形式化
⏹盒结构表示分析和设计
⏹正确性验证
⏹增量模型
⏹把软件看成一系列的增量
软件过程模型的特点汇总
5.统一过程和敏捷过程
⏹统一过程
⏹RationalUnifiedProcess（RUP）描述了软件开发中各个环节应该做什么、怎么做、什么时候做以及为什么要做，描述了一组以某种顺序完成的活动
⏹敏捷过程
⏹AgileDevelopment是一种以人为核心、迭代、循序渐进的开发方法，其软件开发过程称为“敏捷过程”
RUP
RationalUnifiedProcess将软件开发分为四个阶段：
⏹先启–定义整个项目的范围
⏹精化–制定项目计划、描述功能、建立体系架构框架
⏹构建–构造软件产品
⏹迁移–将软件产品移交到最终用户手中
敏捷过程
⏹敏捷开发的价值观
⏹个人和交互胜过过程和工具
⏹可以运行的软件胜过面面俱到的文档
⏹客户合作胜过合同谈判
⏹响应变化胜过遵循计划
⏹敏捷开发的12条原则
⏹尽早、不断地提交有价值的软件
⏹允许改变需求，利用变化来为客户创造优势
⏹尽快、不断地提交可运行的软件
⏹在业务人员和开发人员必须天天都在一起工作
⏹以积极向上的员工为中心建立项目组，提供环境和支持，并信任他们的工作
⏹在团队内部重视面对面的交流
⏹依据可运行软件来评估项目的进展
⏹提倡可持续的开发
⏹时刻关注技术上的精益求精和好的设计，以增强敏捷能力
⏹简单是最根本的
⏹最好的构架、需求和设计出于自组织团队
⏹每隔一定时间，要反省如何才能更有效地工作，然后作相应调整
极限编程
⏹eXtremeProgramming是一种轻量级的、敏捷的软件开发方法
⏹4个价值观
⏹交流、简单、反馈、勇气
⏹4个方面改善
⏹加强交流、从简单做起、寻求反馈、勇于实事就是
⏹12个核心实践
⏹完整团队、计划对策、测试、简单设计、结对编程、小软件版本、设计改进、持续集成、代码共有、编码标准、系统比喻、可持续的速度
6.软件可行性研究
⏹目的
⏹研究项目是否可能实现和值得进行
⏹回答Whytodo?
⏹研究的内容
⏹经济可行性
⏹技术可行性
⏹运行可行性
⏹法律可行性
可行性研究的步骤
⏹对当前系统进行调查和研究
⏹弄清当前系统
⏹导出新系统逻辑模型
⏹导出新系统的解决方案
⏹设计不同的解决方案
⏹提出推荐的方案
⏹本项目的开发价值
⏹推荐这个方案的理由
⏹编写可行性认证报告
⏹系统概述
⏹可行性分析
⏹结论意见
软件风险分析
⏹风险识别
⏹项目风险
⏹技术风险
⏹商业风险
⏹风险预测
⏹风险发生的可能性
⏹风险发生后的后果
⏹风险的驾驭和监控
小结
⏹随着软件工程的发展，许多学者先后提出了瀑布模型、快速原型模型、增量模型、螺旋模型、转换模型、净室模型和构件集成等多种过程模型，各种软件开发模型各有优缺点
⏹在选定软件开发过程时，开发者不仅应该了解开发过程的特点，还应该结合待开发系统的特点一起考虑。
如有必要，也可以同时组合多种模型或创建新的模型。
第三章结构化分析与设计
•概述
--结构化分析与设计的由来
⏹结构化分析与设计最初系由结构化程序设计扩展而来
⏹瀑布模型的首次实践
⏹SA与SD的流程
⏹结构化分析（工具：
DFD、PSPEC）分析模型（分层DFD图）+SRS
⏹结构化设计（工具：
SC图）映射初始设计模型（初始SC图）
⏹初始设计模型（初始SC图）优化最终设计模型（最终SC图）
⏹基本任务与指导思想
⏹结构化分析
⏹建立分析模型
⏹编写需求说明
⏹结构化设计
⏹软件设计=总体设计+详细设计
⏹SC图须分两步完成
•概述
--结构化分析与设计的由来
⏹结构化分析与设计最初系由结构化程序设计扩展而来
⏹瀑布模型的首次实践
⏹SA与SD的流程
⏹结构化分析（工具：
DFD、PSPEC）分析模型（分层DFD图）+SRS
⏹结构化设计（工具：
SC图）映射初始设计模型（初始SC图）
⏹初始设计模型（初始SC图）优化最终设计模型（最终SC图）
⏹基本任务与指导思想
⏹结构化分析
⏹建立分析模型
⏹编写需求说明
⏹结构化设计
⏹软件设计=总体设计+详细设计
⏹SC图须分两步完成
•概述
--SA模型的组成与描述
结构化分析模型的描述工具
•概述
--SD模型的组成与描述
结构化设计模型的描述工具
⏹SC图的组成符号
⏹矩形框来表示模块，带箭头的连线表示模块间的调用，并在调用线的两旁标出传入和传出模块的数据流
2.结构化系统分析
⏹T.DeMarco的定义
⏹结构化分析就是使用DFD、DD、结构化英语、判定表和判定树等工具，来建立一种新的、称为结构化说明书的目标文档
⏹结构化分析的基本步骤
⏹由顶向下对系统进行功能分解，画出分层DFD图
⏹由后向前定义系统的数据和加工，编制DD和PSPEC
⏹最终写出SRS
2.结构化系统分析
--画分层数据流图
2.结构化系统分析
--画分层数据流图
2.结构化系统分析
--画分层数据流图
2.结构化系统分析
--确定数据定义与加工策略
⏹从数据的终点开始定义数据和加工
⏹数据定义—DD
⏹例如：
发票
⏹发票＝学号＋姓名＋｛书号＋单价＋数量＋总价｝＋书费合计
⏹加工策略—PSPEC
⏹分层DFD图产生了系统的全部数据和加工，通过对这些数据和加工的定义，常常对分析员提出一些新问题，促使新的调查和思考，并可能导致对DFD的修改。
画DFD，定义加工和数据，再画，再定义，如此循环，直至产生一个为用户和分析员一致同意的文档——SRS。
2.结构化系统分析
--需求分析的复审
⏹复审人员
⏹用户和系统分析员共同进行复审，并吸收设计人员参加
⏹复审的重点
⏹尽量多地发现文档中存在的矛盾、冗余与遗漏，尽可能确保DFD、DD、加工说明等文档的完整性、一改性和易读性，
3.结构化系统设计
从分析模型导出设计模型
数据流图的类型
⏹数据流图的类型
⏹变换（transform）型结构
⏹传入路径
⏹变换中心
⏹传出路径
⏹事务（transaction）型结构
⏹一条接受路径
⏹一个事务中心
⏹若干条动作路径
变换结构的DFD
事务型结构DFD
同时存在两类结构
SD方法的步骤
变换映射
⏹划分DFD图的边界
⏹建立初始SC图的框架
⏹顶层都只含一个用于控制的主模块
⏹第一层包括传入、传出和中心变换三个模块
⏹分解SC图的各个分支
⏹分解实质上是“映射”
例子—划分DFD
第一级分解
传入分支的分解
传出分支的分解
变换中心的分解
初始SC图
事务映射
⏹在DFD图上确定边界
⏹事务中心
⏹接受部分（包括接受路径）
⏹发送部分（包括全部动作路径）
⏹画出SC图框架
⏹DFD图的三个部分分别映射为事务控制模块，接受模块和动作发送模块
⏹分解和细化接受分支和发送分支
例子—划分DFD
第一层分解
混合结构
优化结构设计的指导规则
⏹对模块划分的指导规则
⏹提高内聚，降低耦合后
⏹简化模块接口
⏹少用全局性数据和控制型信息
⏹保持高扇入/低扇出的原则
⏹扇入高则上级模块多，能够增加模块的利用率
⏹扇出低则表示下级模块少，可以减少模块调用和控制的复杂度
扇入和扇出
例子：
扇出
例子：
扇出
4.模块设计
⏹模块设计也称详细设计
⏹目的
⏹为SC图中的每个模块确定算法和数据结构，用选定的表达工具给出清晰的描述
⏹主要任务
⏹编写软件的“模块设计说明书”
模块设计的原则与方法
⏹清晰第一的设计风格
⏹结构化的控制结构
⏹仅用这三种控制结构来构成程序
⏹每个控制结构只应有一个入口和一个出口
⏹逐步细化的实现方法
常用的表达工具
⏹流程图
⏹N－S图
⏹伪代码
⏹PDL语言
N-S图
小结
⏹讨论传统软件工程的系统开发技术，重点放在基于瀑布模型的结构化分析与设计和模块设计上，但不涉及同为传统软件工程的快速原型开发等内容。
全章以实例（从“教材销售”到“教材购销”）为主线，依次展示了结构化分析、结构化设计和模块设计的常用技术。
第四章面向对象与UML
Ø面向对象概述
ØUML简介
Ø静态建模
Ø动态建模
Ø物理架构建模
ØUML工具
1.面向对象概述
v对象：
代表客观世界中实际或抽象的事物
v客观世界是由各种对象组成的
v数据以及在其上的操作的封装体
v类：
一组相似的对象的共性抽象
v类是一组客观对象的抽象
v实现抽象数据类型的工具
v类与对象的关系
v抽象与具体的关系
v组成类的每个对象都是该类的实例
v实例是类的具体事物
v类是各个实例的综合抽象
•面向对象概述
--面向对象的基本特征
⏹面向对象的基本特征
⏹抽象
⏹在某个重要的或想关注的方面来表示某个物体或概念
⏹忽略主题中与当前目标无关的方面
⏹封装
⏹把操作和数据包围起来，对数据的访问只通过已定义的接口来完成
⏹继承
⏹类之间的“isa”或“islike”关系
⏹类层次，定义一个新类，可以从现有的类中派生出来
⏹子类可以从父类继承方法和属性
⏹多态
⏹不同类的对象可以对同一消息作出响应，执行不同的处理
•面向对象概述
--面向对象开发的优点
2.UML简介
⏹UnifiedModelingLanguage
⏹近10多年来OOSE最重要的成果
⏹贡献者：
GradyBooch，IvarJacobson，JimRumbaugh
⏹中文网站
⏹http:
//www.
⏹
UML的组成
⏹UML的模型元素
⏹表示模型中的某个概念
⏹类、对象、构件、用例、结点（node）、接口（interface）、包（package）和注释（note）
⏹表示模型元素之间的关系
⏹关联、泛化、依赖、实现、聚合和组合
⏹UML的元模型结构
⏹元元模型层
⏹元模型层
⏹模型层
⏹用户模型层
UML的组成
⏹图
⏹静态图
⏹用例图、类图、对象图、构件图和部署图
⏹动态图
⏹状态图、时序图、协作图和活动图
⏹视图
⏹用例视图
⏹从用户的角度看到的系统应有的外部功能
⏹逻辑视图
⏹描述系统的静态结构和对象间的动态协作关系
⏹进程视图
⏹展示系统的动态行为及其并发性
⏹构件视图
⏹展示系统实现的结构和行为特征
⏹部署视图
⏹显示系统的实现环境和构件被部署到物理结构中的映射
UML的特点
⏹统一标准
⏹面向对象
⏹表达能力强大
⏹可视化
UML的应用
⏹用于描述系统开发的不同类型于不同阶段
⏹从需求分析到软件设计到软件测试及维护
⏹可视化问题描述，帮助理解问题
⏹帮助建立各阶段的文档
⏹获取和交流有关应用问题求解的知识
⏹辅助构建系统
3.静态建模
⏹静态建模
⏹用例图、类图和对象图
⏹用例模型
⏹用例图表示
⏹从最终用户的角度描述系统功能
⏹类和对象模型
⏹类图和对象图表示
用例图与用例模型
⏹用例图的组成符号
建立用例图
用例之间的关系
⏹扩展关系
⏹根据指定的条件，一个用例中有可能加入另一个用例的动作
⏹包含关系
⏹一个用例的行为包含另一个用例的行为
类图ClassDiagram
对象图ObjectDiagram
类图表示类间关系
⏹关联关系（Association）
⏹类之间存在的语义上的关系
⏹普通关联、递归关联、多重关联等
⏹聚集关系（Aggregation）
⏹特殊的关联：
整体-部分
⏹组合关系（Composition）
⏹特殊的聚集：
整体强烈拥有部分
⏹泛化关系（Generalization）
⏹继承
⏹依赖关系（Dependency）
⏹对一个类/对象的修改会影响另一个类/对象
关联关系
聚集和组合
泛化关系
依赖关系
约束与派生
⏹约束和派生机制能应用与任何模型元素
⏹用花括号括起放在模型元素旁边
⏹典型的属性约束是该属性的取值范围
⏹派生属性可由其它属性通过某种方式计算得到，通常在派生属性前面加一个“/”表示
⏹关联关系可以被约束，也可以被派生
包图
4.动态建模
⏹消息（Message）
⏹状态图（StateDiagram）
⏹时序图（SequenceDiagram）
⏹协作图（CollaborationDiagram）
⏹活动图（ActivityDiagram）
消息
状态图StateDiagram
状态图之间发送消息
时序图（SequenceDiagram）
协作图（CollaborationDiagram）
活动图ActivityDiagram
5.物理架构建模
⏹逻辑架构和物理架构
⏹逻辑架构
⏹物理架构
⏹构件图
⏹配置图
构件图ComponentDiagram
部署图DeploymentDiagram
6.UML工具
⏹RationalRose
⏹StarUML
RationalRose
StarUML
小结
⏹面向对象开发按人的思维方式来理解和解决问题，将问题空间的概念直接映射到解空间。
面向对象的基本特征是抽象、封装、继承和多态。
⏹作为一种著名的建模语言，UML用图从不同的视角为系统建模，形成为不同的视图；每个视图代表系统完整描述中的一个抽象，显示这个系统中的一个特定的方面；每个视图由一组图构成，其中包含了强调系统中某一方面的信息。
第5章需求工程与需求分析
⏹软件需求过程
⏹需求分析与建模
⏹需求获取的常用方法
⏹需求模型
⏹软件需求描述
⏹需求管理
⏹需求建模示例
1.软件需求工程
⏹软件需求的定义
⏹一个软件系统必须遵循的条件或具备的能力
⏹系统的外部行为
⏹系统的内部特性
⏹软件需求三个层次
⏹业务需求
⏹用户需求
⏹功能需求
软件需求的层次关系
软件需求的特性
⏹功能性
⏹可用性
⏹可靠性
⏹性能
⏹可支持性
⏹设计约束
需求工程的由来
⏹代码编写-〉生存周期-〉需求工程
⏹软件需求工程
⏹可以定义为应用有效的技术和方法，合适的工具和符号，来确定、管理和描述目标系统及其外部行为特征的学科
2.需求分析与建模
⏹需求分析的步骤
⏹需求分析是迭代过程
3.需求获取的常用方法
⏹常规的需求获取方法
⏹联合分析小组
⏹用户代表、领域专家和系统分析员
⏹客户访谈
⏹充分准备，寻找共同语言
⏹循循序渐进、逐步逼近
⏹问题分析与确认
⏹多个来回
3.需求获取的常用方法
⏹用快速原型法获取需求
⏹利用各种分析技术和方法，生成一个简化的需求规格说明；
⏹对需求规格说明进行必要的检查和修改后，确定原型的软件结构、用户界面和数据结构等；
⏹在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试、改进；
⏹将原型提交给用户评估并征求用户的修改意见；
⏹重复上述过程，直到原型得到用户的认可。
4.需求模型
⏹需求模型概述
⏹结构化需求模型
⏹面向对象需求模型
⏹面向对象的需求建模
⏹画用例图
⏹写用例规约
⏹描述补充规约
⏹编写术语表
结构化需求模型
面向对象需求模型
用例建模
⏹确定参与者
⏹存在于系统外部、与系统交互的人、硬件、其他系统
⏹通过回答问题确定参与者
⏹系统开发完成之后，有哪些人会使用这个系统？
⏹系统需要从哪些人或其他系统中获得数据？
⏹系统会为哪些人或其他系统提供数据？
⏹系统会与哪些其他系统相关联？
⏹系统是由谁来维护和管理的？
用例建模
⏹确定用例
⏹考察每个参与者与系统的交互和需要系统提供的服务
⏹通过回答问题确定用例
⏹参与者为什么要使用该系统？
⏹参与者是否会在系统中创建、修改、删除、访问、存储数据？
如果是的话，参与者又是如何来完成这些操作的？
⏹参与者是否会将外部的某些事件通知给该系统？
⏹系统是否会将内部的某些事件通知该参与者？
用例建模
升级会员 