软件工程
2024-03-23 09:20:41 7 举报
AI智能生成
软件工程,PDL,UML,CMMI,RUP,SLCM
作者其他创作
大纲/内容
1章 软件工程
软件危机
定义
软件工程
定义
目的
发展
20世纪60-80初
成果
提出瀑布模型
开发很多过程语音(C语言,Pascal语言)
开发方法(jaskjson,结构化方法)
开发一些工具(调试工具,测试工具)
特征
前期主要研究实现技术
后期关注软件质量和软件工程管理
20世纪80年代以来
成果
软件生存周期过程
开展软件辅助工程(CASE 产品)
面向对象语言(C++,Smalltalk)
面向对象软件开发方法
特征
开展一系列软件生产技术
特别是软件复用技术和软件生产管理的研究和实践
软件开发
思想基础
正确认识软件开发
目标
本质
定义
不同抽象层术语之间的映射
不同抽象层处理逻辑之间的映射
实现方式
系统建模
运用所掌握的知识,通过抽象,给出系统的结构
遇到的问题
如何管理这样的映射,保障映射下有效性和正确性(这是管理层面上的问题)
包括(软件规划,组织,人员安排,控制和领导)
如何实现这样的映射(这是技术层面的问题)
解决方法
过程方向(求解软件开发逻辑)
过程途径(求解软件开发手段)
基本手段(问题建模)
产品
软件系统
软件系统模型
模型
定义
模型分类(分层)
动机目的
控制软件开发复杂性
分类
概念模型
定义
软件模型
设计模型
实现模型
部署模型
计算机软件
程序
文档
2章 需求和需求规约
需求
定义
一个需求描述待开发产品/系统,功能上的能力,性能参数和其他性质
性质
必要性
无歧义性
可跟踪性
可测试性
可测量性
分类
功能需求
需求的主体
应产生销售报表
应该有月销售统计报表
非功能需求
性能需求
在5分钟内计算出季度报表
功能信息对比误报率小于 1%~2%
外部接口需求
对要构建的账户系统,必须为财务状态系统提供更新信息
设计约束
必须用C++面向对象语言设计
任取1s,一个特定的应用消耗可用计算能力平均不超过的50%
质量约束
可靠性
软件系统在指定环境中没有失败,而正常运行的概率
存活性
当某部分不能运行了, 软件还能继续运行
可维护性
发现改正一个故障,对特定范围内进行的修改所需要的平均工作
用户友好性
学习和使用软件的一个难易程度
发现技术
自悟
需求人员把自己作为系统的最终用户,审视系统,并提出问题
观察
通过观察用户执行现有任务和过程,或者观察他们操作现有系统,了解系统运行环境
交谈
需求人员通过 提出问题/用户回答这一方式,直接询问用户需要一个什么样的系统
小组会
举行客户和开发人员的会议,与客户需求代表共同开发需求
提炼
复审技术文档,提出相关需求
首要任务
需求发现
需求分析
需要验证
需求规约
定义
是一个软件项目/产品/系统 所有需求陈述的正式文档,表达了一个软件产品. 系统的概念模型
性质
重要性
稳定性
按重要性,和稳定性,将需求进行分级。 分出基本需求 ,可选需求,期望需求
可修改的
在不过多的影响其他需求的基础上,可以修改一个单一需求
完整性
没有被遗漏的需求
一致性
不存在互斥的需求
需求规约文档
特定需求
是文档的技术核心
表达
非形式化需求规约
以一种自然语言来描述需求规约,
适合规模较小,复杂度不高的小型项目,在获取SRS 草案的时候用
半形式化需求规约
以半形式化符号体系来描述需求规约
针对大型复杂系统,组织一般使用系统化的需求获取,分析技术和工具
形式化需求规约
一种基于良构数学概念的符号体系来编制需求,一般有注释性的支持
针对质量, 安全性比较高的产品
作用
是软件开发组织和用户之间的一份技术合同书,是产品,系统,功能和环境的体现
对项目的大多数工作来说, 需求规约是一个管理的控制点
对产品系统设计来说, 需求规约是一个正式的受控的起始点
需求规约是创建产品测试,和用户系统操作指南的基础, 即需求规约会产生两个文档, 一个是初始测试计划, 一个是 用户系统操作指南
3章 结构化方法
结构化需求分析
三大挑战
问题空间的理解
人与人之间的通信
需求的变化性
解决方法
结构化方法
面向数据结构方法
面向对象方法
基本术语
数据流
数据流是数据的流动
加工
加工是数据的变换单元
数据存储
是数据的静态结构
数据源
数据源是数据流的起点
数据潭
数据潭是数据流的归宿地。
首要任务
建立系统功能模型
建模步骤
建立系统环境图,确定系统语境
自动向下,逐步求精,建立系统层次数据流图
定义数据字典
定义数据流图包含的所有数据流和数据存储的数据结构,直到给出构成以上数
据的各数据项的基本数据类型
据的各数据项的基本数据类型
描述加工
结构化自然语言
内层
自然语言
外层
顺序,选择,循环
判定表
条件类别
条件组合
操作
操作执行
判定树
工具
DFD图
基本手段
抽象
分解
结构化设计方法
主要任务
在结构化需求分析的基础上,确定 怎么做的问题
分类
总体设计
任务
将系统的功能需求,放在软件体系结构中,建立系统的模块结构
设计
步骤
将结构化需求分析阶段得到的DFD ,转换为初始 模块结构图
再基于 高内聚 低耦合的 设计原则 ,将初始模块结构图 转换为 供详细设计使用的模块结构图
设计模式
变换设计
目标
变形型数据流图转化模块结构图
基本步骤
设计准备,复审并精华需求
确定系统的输入, 变化,输出三部分的边界
第一级分解:系统模块结构图 顶层 和第一层的设计
第二级分解: 自顶向下逐步求精
事物设计
目标
事务型数据流图-- 模块结构图
基本步骤
设计准备,复审并精华需求
确定事务处理中心
第一级分解: 系统规模图的顶层和第一次设计
第二级分解: 自顶向下逐步求精
两个区别
依据的数据流程图不一样
一个是主控模块协调控制其他模块
一个是接受数据,选取和确定事物处理活动途径
两者结合设计步骤
在软件总体设计中,通常以变换设计为主,事务设计为辅,进行结构设计
先利用变换设计,把软件系统分为输入、中心变换和输出3个部分,设计上层模块
再根据各部分DFD图的结构特点,适当地利用变换设计和事务设计进行细化,得到初始模块结构图
最后按高内聚低耦合的原则,对初始的模块结构图进行精化,得到最终模块结构图
表示
Yourdon图
描述软件“宏观”结构的图形化工具
HIPO图
层次图+输入/处理/输出”
H图
阶段
初始阶段
将给定的数据流图转换为初始的模块结构图
精华阶段
高内聚低耦合”,精化模块结构图,设计数据结构和接口
复审阶段
对高层软件结构进行复审,精化
详细设计
目标
将总体设计的产生的系统高层模块结构图 映射为一些术语表达的低层模块结构图, 即系统的最终模块结构图
任务
具体描述模块结构图中每一个模块,给出实现模块功能的实施机制
包括一组例程和数据结构,精准的满足需求规约的结构
设计方法
结构化程序设计
模块化和启发式原则
模块化
定义
把一个待开发的软件分解成若干个,具有高内聚低耦合的模块的过程
目标
基于模块的“ 高内聚低耦合" 提高模块的独立性
设计工具
伪码
问题分析图
PAD
N-S盒图
模块
定义
是一个执行特定任务的过程 以及相关数据结构
父主题
接口
模块体
方法
分而治之
抽象
独立性的指标
耦合
定义
不同模块层之间相互依赖的度量
分类
内容耦合
一个模块直接操作和修改另一个模块的数据
公共耦合
两个和两个以上的模块共同引用一个全局数据项
控制耦合
一个模块通过接口向另一个接口 传递控制信号,接受信号的模块通过信号值进行适当动作
标记耦合
一个模块通过接口向模块B和C传递一个公共参数
数据耦合
模块之间通过参数来传递数据
设计原则
尽量使用数据耦合
少用控制耦合
控制公共耦合的范围
避免使用内容耦合
内聚
定义
一个模块内部各个成分之间相互关联的度量
分类
偶然内聚
单个模块成分之间不存在任何关系, 对系统进行修改,发生的错误率最高
逻辑内聚
几个逻辑相关的功能放在同一个模块中
时间内聚
一个模块完成的功能必须在爱同一时间内执行,这些功能只因为时间应是关联在一起
过程内聚
模块内的处理必须以特定的是次序执行
通信内聚
模块的所有成分,都操作 或生成同一个数据集
顺序内聚
一个成分的输出做为另一个模块的输入
功能内聚
模块的所有成分对完成单一功能都是基本的
术语
深度
控制的层数,能粗略的标志一个系统的规模和复杂度
宽度
同一层次上模块总数的最大值
对宽度影响最大的是扇出
扇入
表明有多少个上级模块调用它
扇出
一个模块直接调用下一个模块的数量
控制域
一个模块本身 和所有直接或者间接从属于他的模块的集合
作用域
受模块内一个判定所影响的所有模块的集合
启发式原则
改进模块接口,提高模块独立性
力求模块规模适中
力求模块的深度,宽度,扇入,扇出适中
尽力是模块的作用域在控制域之内
尽力降低磨快点复杂度
力求模块功能可以预测
结构化程序设计方法
定义
是一种基于结构编程的方法,采用 顺序结构, 选择结构,重复结构进行编程,每个结构只允许有一个出口和入口
实际上,可以用顺序和结构和重复结构 代替选择结构
设计工具
程序流程图
优点
对流程控制描述直观,适合初学者掌握
缺点
不是一个逐步求精的过程,影响甚至破坏系统好的结构,不宜用来表示数据结构
符号
顺序结构
选择结构
循环结构
盒图 N-S
支持 自顶向下逐步求精
符号
顺序
IF-THEN-ELSE
CASE型
循环
子主题
调用子程序P
PAD 图(问题分析图)
二维树形结构, 自上而下,从左至右
符号
顺序
选择
CASE型多分支
WHILE型循环
UNTIL型循环
语句标号
定义
类程序设计语言
符号
混合语言
使用自然语言的词汇
使用某结构化设计语言的关键字作为语法框架
4章 面向对象方法UML
UML 术语表
定义
一种可视化的建模工具,给出了表事物和食物之间的关系术语,以及表达模型工具
8个术语 表达客观事物的术语
类和对象
类
定义
一组具有相同属性,操作,语义和关联的对象的描述
对象
定义
是类的一个实例
接口
定义
是一个操作的集合,每一个操作,描述了子类,构件或子系统的一个服务
协作
定义
是一个交互,包括,交互各方,交互方式,交互内容,包括相互的作用和 协作的行为
用况
定义
是对一组对动作序列的描述,系统执行这些用况,能对参与者产生可见有值的结果
主动类
定义
是一种至少具有一个线程或者进程的类
构件
定义
是系统设计中的一种模块化部件,通过外部接口隐藏他的实现
制品
定义
是系统中包含的物理信息,可替代的物理组件
节点
定义
是运行时存在的物理元素,通常用于表达具有记忆能力了和处理能力的资源
表达事物的关系
关联
定义
是类目间的一种结构关系,描述了具有一组相同结构,相同链的描述
链
对象之间的特定语义关系抽象,实现后的链,通常称为对象之间的连接
术语
关联名
用户描述关联的一定内涵
导航
对于一个给定的类目,可以找到与之关联的另一个类目
角色
关联一端的类目对另一端类目的呈现
可见性
多重性
类中对象参与一个关联的数目,称为关联的 多重性
限定符
是一个关联的属性或者属性表,
聚合
是关联的一种特殊形式,表达了整体/部分的关系
组合
是聚合的一种特殊形式
整体类的实例,包含一部分类的实例,而且该整体类的实例负责创建和销毁部分类的实例
泛化
定义
一般性类目和特较为特殊性类目之间的一种关系,有时称为 is a kind of
特点
子类可以继承父类的属性和操作, 并且可以拥有更多的属性和操作
子类可以替换父类的声明
子类可以覆盖父类的操作和实现
可以在其他类目之前创建泛化
表示法
分离表示法
共享表示法
特点
基类(父类)
叶子类(子类)
多继承
术语
完整
表明已经在模型中给出了泛化中的所有子类,尽管在表达的图形中有所省略,但 也不允许增加新的子类。
不完整
表明在模型中没有给出泛化中的所有子类,因此可以增加新的子类
互斥
表明父类的对象最多允许该泛化中的一个子类作为它的类型。
重叠
表明父类的对象可能具有该泛化中的多个子类作为它的类型
细化
定义
细化是类目之间的语义关系,其中一个类目规约了保证另一个类目执行的契约。
表示
使用 虚线带空箭头表示
依赖
定义
依赖是一种使用关系,用于描述一个类目使用另一类目的信息和服务。
表示
使用虚线实线箭头表示
特点
按照UML的观点,客观世界一切事物之间的关系都可以用依赖来规约
关系
关联、泛化、细化都是一类特定的依赖
表达组合关系的术语
包
定义
为控制信息组织的复杂性,UML提供了组织信息的一种通用机制—包,支持形成一些可管理的部分。 换言之,包可以作为“模块化”和“构件化”的一种机制。
UML模型表达格式
UML的图形化工具
结构图
作用
表达系统或系统成分的 静态结构模型, 给出系统或者系统成分的说明类信息
分类
类图
可视化的表达系统静态结构模型.
包含 类,接口 ,泛化 ,依赖 等关系
步骤
模型化待建系统中的概念,形成类图中的基本元素
模型化待建系统中的各种关系,形成该系统的初始类图
模型化系统中的协作,给出该系统的最终类图
模型化逻辑数据库模式
对象图
包图
构件图
部署图
组合结构图
行为图
作用
表达系统或系统成分的动态结构模型, 或给出系统和系统成分的行为信息
分类
用况图(use case)
定义
表达系统功能模型的图形化工具
作用
1.可以对系统建模,描述系统功能结构
2.可以对业务建模,描述企业和组织 业务过程结构
业务模型和系统模型之间具有“整体/部分”关系, 即业务模型是整体,而系统模型是业务模型的一个组成部分。
模型元素
主题
用户
参与者
关联
泛化
依赖
活动图
状态图
定义
状态图是显示一个状态机的图,其中强调了从一个状态到另一状态的控制流。
一个状态机是一种行为,规约了一个对 象在其生存期间因响应事件并作出响应 而经历的状态
作用
创建系统的动态模型 和场景模型
可用于创建有关系统的行为生存周期模型,给出生存期内的阶段信息
状态
定义
类目的一个实例在其生产中的一种条件和情况。所具有对外呈现和能提供的服务
分类
初态
圆点表示
终态
圆点带环
正常态
圆角矩形
事件
定义
在确定的时空内发生有意义的事件
分类
内部事件
指系统内对象之间传送的事件,例如溢出异常等。
外部事件
指系统和它的参与者之间所传送的事件,如按一下按钮,或传感器的一个中断
类型
信号事件
调用事件
调用表示对象接受到一个操作的请求。
时间事件
时间事件是表示推移一段时间的事件
变化事件
变化事件表示状态的一个变化,或表示某一条件得到满足
状态转移
是两个状态间的一种关系,意指一个对象在一个状态中将执行一些确定的动作,当规约的事
件发生和规约的条件满足时,进入第二个状态。
件发生和规约的条件满足时,进入第二个状态。
交互图
顺序图
定义
是一种交互图,即由一 组对象以及按时序组织的对象 之间的关系组成,其中还包含 这些对象之间所发送的消息。
作用
支持系统交互建模的图形化工具
通信图
交互概观图
定时图
5章 面向对象方法RUP
RUP
特点
以用况为驱动,体系结构为中心的迭代增量式开发
用况驱动
以用况作为基础,驱动系统有关人员对要建立系统的功能需求进行交流,
驱动系统分析、设计、实现和测试等活动
驱动系统分析、设计、实现和测试等活动
体系结构中心
指在系统的生存周期中,开发的任何阶段都要给出相关模型视角下有关体系结构的描述,作为构思、
构造、管理和改善系统的主要制品
构造、管理和改善系统的主要制品
作用
并给出了实现各层模型之间映射的基本活动以及相关的指导
经历的阶段
初始阶段
精华阶段
构造阶段
移交阶段
核心工作流
需求获取层
工具
采用usecase技术获取
目标
使用UML中的用况、参与者及依赖等术语抽象客观实际问题,形成系统的需求获取模型
展开的工作
列出候选需求
特征列表
理解系统语境
领域模型
使用类图表达 (捕获系统语境中的一些重要领域对象)
领域类的三种形态
业务对象
实体对象
事件
业务模型
用况图表达
业务对象的用况
工作人员
业务实体
工作单元
捕获功能需求
用况模型
是系统的一种概念模型,是对系统功能的抽象,包括系
统参与者、系统用况以及它们之间的关系。
统参与者、系统用况以及它们之间的关系。
捕获非功能需求
补充需求/针对一些特定需求的用况
分析层
目的
在系统用况模型的基础上,创建系统分析模型及在
该分析模型视角下的体系结构描述
该分析模型视角下的体系结构描述
分析模型
定义
是系统的一种概念模型,解决系统用况模型中 存在的二义性和不一致性等问题,以一种系统化的形式准 确表达用户需求。
主要活动
体系结构分析
用况分析
类的分析
包的分析
基本术语
分析类
边界类
封装一些重要的通信接口和用户界面机制
实体类
封装问题域中的一个重要现象
控制类
封装一些重要的定序
用况细化
一个协作。针对一个用况,其行为用多个分析类间相互作用来细化,记为用况细化
分析包
一种控制信息组织复杂性的机制,提供分析制品的一种组织手段,形成可管理的部分。
分析模型的表达
分析模型由“分析系统”定义,该分析系统包含一组具有层次结构的包,每个包中可包含一些分 析类和用况细化
分析类和用况细化[分析]可单独出现在分析模型中,以凸显其在系统体系结构方面的作用
设计层
目标
定义满足系统/产品分析模型所规约需求的软件结构。
术语
设计类
用况细化
设计子系统和接口
设计模型
作用
RUP设计的主要结果设计模型,尽量保持该系统已有的分析模型。并作为系统实现的输入
元素
设计子系统 服务子系统
设计类
用况细化
体系结构描述
部署模型
主要活动
体系结构设计
用况设计
类的设计
子系统的设计
实现和测试层
目标
基于设计类和子系统生成构件
对构件进行单元测试、集成、连接
把可执行的构件映射到部署模型
实现活动
6章 软件测试
软件评估
静态评估
评审
走查
形式化证明
动态评估
软件测试
软件测试
目标
首要目标
预防错误
第二目标
发现错误
认识阶段
软件测试和软件调试没有区别
软件测试表明软件能正常工作
软件测试表明软件不能正常工作
软件测试只是将已察觉的错误和风险降低到可接受的程度
软件测试不仅仅是一种行为,而是一种理念,即软件试是产生低风险软件的一种训练
概念
使用人工和自动化手段, 运行和测试某个系统的过程,检验系统是否满足规定的需求,清楚了解预期结果和实际结果之间的差异
好的测试方案
能够发现迄今为止没有发现的错误
成功的测试
发现了迄今为止未发现的错误
和调试的区别
软件测试
从侧面证明程序员的失败
从已知条件开始, 使用预先定义的程序,能够预知结果
有计划的,并且进行测试设计
是一个发现错误,改进错误,重新调试的过程
执行是有规程的
由独立的组在不了解软件设计的条件下完成
多数的测试执行和设计有工具支持
软件调试
为了证明程序员的正确
从未知的内部条件开始,结果是不可预知的
不受时间约束
是一个推理过程
执行要求程序进行必要的推理
必须由了解详细设计的程序员完成
能利用的工具主要是调试器
软件测试过程模型
测试设计
测试执行
测试结果比较
软件测试技术
黑盒测试
概念
定义
将被测软件看作盒子,只通过外部输入、输出发现软件错误,完全 不考虑程序内部结构。
别称
功能测试技术
依据
软件行为的描述
建模工具
事务流程图
事务
从系统用户角度出发,所见到的一个功能,由一系列操作组成
事务流程图
一种表达被测软件模型的工具
组成
操作
分支
节点
链
因果图
典型测试技术
事物流测试
等价类划分
边界值分析
等价类划分
定义
把软件所有可能输入数据划分成若干部分,一个部分中各数据发现软件错误的概率一样
边界值分析
定义
使用等于、小于或大于边界值的数据对软件进行测试,发现错误的概率较大。 故在设计测试用例时应选择一些边界值
因果图
生产测试用例的步骤
分析软件需求规格说明书,找出每个模块的原因和结果,并赋予标记
白盒测试
概念
别称
结构测试技术
依据
程序的逻辑结构
建模工具
控制流程图
组成
过程块
判定
节点
链
路径
和程序流程图的差异
控制流程图, 控制块不显示细节
程序流程图,着重显示过程块的属性和细节
典型测试技术
路径测试技术
路径测试技术
概念
用控制流程图表达被测程序模型,揭示程序的控制结构
合理选择一组穿过程序的路劲,达到某种测试度量
测试策略
路径覆盖
执行所有可能穿过程序控制流程的路径
所有穿过程序的路径都走一遍
条件组合覆盖
每个判定中所有可能的条件取值组合至少执行一次
所有条件TF 都组合一次
条件覆盖
每个判定中为真假的条件取值至少执行一次
每个条件的TFTF 都执行一次
分支覆盖
至少将程序中的每一分支执行一次
每个分支的TF执行一次
语句覆盖
至少执行程序中所有语句一次
所有为T的分支走一遍
7章 软件生存周期 SLCM
软件生存周期过程
基本过程
获取过程
供应过程
开发过程
运行过程
维护过程
支持过程
文档过程
配置管理过程
质量保证过程
验证过程
确认过程
联合评审过程
审计过程
问题解决过程
组织过程
管理过程
基础设施过程
培训过程
改进过程
软件生存周期模型
瀑布模型
定义
迭代过程
系统需求
软件需求
需求分析
设计
编码
测试
运行
作用
支持结构化软件开发
控制软件复杂性
促进软件开发工程化
适用
需求已经被很好理解,且开发组织非常熟悉实现这一模型所需要的过程
不支持需求变更
增量模型
定义
迭代过程
分析
设计
编码
测试
交付
适用
技术驱动的软件开发,常被工业界所以采用
优点
第一个可交付的版本所需要的时间和成本比较少
减少用户需求变更
可增量投资
缺点
初始增量可能会对后期增量造成不稳定性
一些增量可能需要重新开发
增大管理的成本,超出组织能力
演化模型
定义
迭代过程
需求
设计
编码
测试
集成
适用
事先不能完整定义需求的软件
螺旋模型
定义
迭代过程
制定计划
风险分析
实施工程
客户评估
适用
项目的开发风险很大
客户不能确定系统需求
喷泉模型
定义
迭代过程
分析
设计
实现
确认
维护
演化
适用
支持面向对象的软件开发
软件项目过程管理
过程建立
项目管理计划
过程管理
软件工程管理 SEMP
软件配置管理 SCMP
软件质量管理 SQAP
软件验证和确认 SVVP
软件度量 SMP
SLCM建立步骤
标识项目可用SLCM
标识那些会影响SLCM的属性
标识为选择SLCM所需要的约束
评估所选择的SLCM
选择最能满足项目属性和约束的SLCM
过程评估
过程改进
8章 集成化能力成熟度模型CMMI
基本思想
源模型
软件CMM
产品集成开发CMM
系统工程CMM
主要模型部件
改善途径
能力等级
定义
组成
等级划分
0.未完成级
1.已执行级
2.已管理级
3.已定义级
4.已定量管理级
5.持续优化级
成熟度等级
定义
组成
等级划分
1 初始级
2 已管理级
3.已定义级
4.已定量管理级
5.持续优化级
两个等级关系
汇总图
数据流图
用况图
类图
状态图
顺序图
结构化设计工具
PAD图
YourDon图
子主题
N-S盒图
H图
IPO图
结构化需求分析
数据字典符号
判定表
判定树
0 条评论
下一页