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