软件工程
2020-06-02 11:36:17 1 举报AI智能生成
软件工程知识点汇总
作者其他创作
大纲/内容
第一章 软件工程概述
1.1 计算机软件
1. 软件的定义
软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合
程序是按事先设计的功能和性能要求执行的指令序列
数据是使程序能正常操作信息的数据结构
文档是与程序开发，维护和使用相关的图文材料
2. 软件的特点
逻辑实体
软件的开发是一种逻辑思维成熟的过程，无明显制造过程
在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题，但却存在退化问题
开发依然很原始，无法完全使软件开发过程自动化
软件是高度复杂的逻辑体
软件的开发和运行常常受到计算机系统的限制，对计算机系统有着不同程度的依赖性
成本相当昂贵
相当多的软件工作涉及到社会因素
3. 软件的分类
按功能层次
系统软件
中间件软件
应用软件
按服务对象
通用软件
定制软件
可配置软件
按软件使用方式
单机软件
服务器软件
客户端软件
按软件功能划分
按规模划分
按工作方式划分
实时处理软件
分时软件
交互式软件
批处理软件
1.2 软件的发展和软件危机
软件危机
由于落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象
表现
软件开发计划难以制定
费用和进度失控
无法让用户满意
质量难以保证
没有适当的文档资料
通常是不可维护的
成本在计算机系统总成本中所占比例逐年增加
解决途径
软件工程
1.3 软件工程
主要思想
按照工程化的原理、原则和方法开发、运行、维护软件
三要素
方法
为软件开发提供了“如何做”的技术。它包括了多方面的任务，如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等
工具
为软件工程方法提供了自动的或半自动的软件支撑环境
过程
将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。过程定义了方法使用的顺序、要求交付的文档资料、为保证质量和协调变化所需一的管理、及软件开发各个阶段完成的里程碑
目标
在给定成本、进度的前提下，开发出满足用户需求且具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性的软件产品
研究内容
软件开发技术
软件工程管理
基本原则
选取适宜的开发模型
采用合适的设计方法
提供高质量的工程支持
重视开发过程的管理
一般原理
抽象
信息隐藏
模块化
局部化
确定性
一致性
完备性
可验证性
基本原理
用分阶段的生命周期计算严格管理
坚持进行阶段评审，尽早发现并排除错误
实行严格的产品控制：控制需求变动的影响
采用现代程序设计技术，提高开发和维护效率
结果应能清楚地审查
开发小组的人员少而精
承认不断改进软件工程实践的必要性
1.4 知识体系
第二章 软件生命周期模型
2.1 软件工程过程
软件规格说明
软件开发
软件确认
软件演进
2.2 软生命周期
指软件产品从考虑其概念开始，到该软件产品不再使用为止的整个时期，一般包括概念阶段、分析与设计阶段、构造阶段、移交阶段等不同时期
六个基本活动
制定计划
需求分析和定义
软件设计
程序编写
软件测试
运行/维护
2.3 软件过程模型
工作流模型
数据流模型
角色/动作模型
2.4 传统软件生命周期模型
1. 瀑布模型
特征
本活动的工作对象来自于上一项活动的输出
根据本阶段的活动规程执行相应的任务
产生本阶段活动相关产出——软件工件，作为下一活动的输入
对本阶段活动执行情况进行评审
优点
阶段划分不仅降低了软件开发的复杂程度，还提高了开发过程的透明性，便于将软件工程过程和软件管理过程有机地融合在一起，从而提高软件开发过程的可管理性
推迟了软件实现，强调在软件实现前必须进行分析和设计工作
一项目的阶段评审和文档控制为手段有效的对整个开发过程进行指导，保证阶段之间的额正确衔接，能够及时发现并纠正开发过程中的缺陷，从而是产品达到预期的质量要求
缺点
缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题，这是最突出的缺点。因此，瀑布模型只适合于需求明确的软件项目。
风险控制能力较弱。成品时间长；体系结构的风险和错误只有在测试阶段才能发现，返工导致项目延期
软件活动是文档驱动的，文档过多会增加工作量，文档完成情况会舞蹈管理人员
2. V模型和W模型
V模型——瀑布模型变种
瀑布模型将测试作为软件实现只有的一个独立阶段，没有强调测试的重要性
其价值在于纠正人们不重视测试阶段重要性的错误认识，将测试分等级，并和前面的开发阶段对应起来
W模型——瀑布模型变种
V模型仍然将测试作为一个独立的阶段，所以并没有提高模型的抗风险能力
将测试广义化，增加了确认和验证内容，并贯穿整个软件生命周期
由两个V模型组成，分别代表测试与开发过程，同步进行
3. 原型方法
瀑布模型无法适应需求的变化
概述
原型：指模拟某种产品的原始模型。软件原型是一个早起可以运行的版本，它反映最终系统的部分重要特性
种类
探索型：弄清对目标系统的要求
实验型：系统实现前考察系统的可行性
进化型：将原型扩展到开发过程，通过原型开发逐步是吸纳所有系统功能
策略
废弃策略
追加策略
优点
有助于增进软件人员对系统服务需求的理解
提供了有力的学习手段
容易确定系统的性能、服务的可应用性、设计的可行性和产品的结果
原型的最终版本可作为最终产品或最终系统的一部分
缺点
文档容易被忽略
建立原型的许多工作会被浪费
项目难以规划和管理
过程
快速分析
快速构造
用户使用
评价反馈
修改，迭代
4. 演化模型
第一次试验开发，目的是探索可行性，弄清楚项目的需求。第一次得到的试验性产品称为原型
第二次在第一次的原型基础上进行开发，从而获得较为满意的软件产品
缺点
可能会抛弃瀑布模型的文档控制优点，开发过程不透明
探索式演化模型可能会导致最后的软件系统的系统结构较差
可能会用到一些不符合主流、不符合要求或者不成熟的工具和技术
可能会抛弃瀑布模型的文档控制优点，开发过程不透明
5. 增量模型
结合了瀑布模型和演化模型的优点
允许用户的需求可以逐步提出来，每一次“增量”需求的划分与“增量”实现的集成是以不影响系统体系结构为前提的
优点
增强了用户使用系统的信心，逐步提出对后续增量的需求
项目总体失败的风险较低
增量从高到低的优先级确定保障了系统重要功能部分的可靠性
同一个体系结构提高了系统的稳定性和可维护性
缺点
增量的粒度选择问题
确定所有的基本业务服务比较困难
6. 螺旋模型
针对大型软件项目
事先不能完整清晰地定义需求是常事，而且设计方案、技术事先方案不允许出现问题，也需要经过多次试验才能明确下来，开发一个只明确需求的原型是远远不能解决问题的，需要开发内容逐步丰富的多个原型
综合瀑布模型和演化模型，并加入了风险分析
四个活动
指定计划
风险分析
实施工程
客户评估
7. 喷泉模型
固有的本质特征
迭代
多次重复、演进
无间隙
各阶段无明显的界限。支持分析和设计结果的自然复用
适用
面向对象的软件开发过程。
8. 构件组装模型
本质上是演化的，开发过程是迭代的
五个阶段
需求定义和分析
软件体系结构设计
构件开发
应用软件构造
测试和发布
9. 快速应用开发模型
一种增量型的软件开发过程模型，采用构件组装方法进行快速开发
阶段
业务建模
数据建模
过程建模
应用生成
测试及迭代
2.5 新型软件生命周期模型
1 统一软件开发过程RUP
2 敏捷模型 AM
AM只是一种态度，不是一种说明性过程，它描述了一种建模风格
价值观
沟通
简单
反馈
勇气
谦逊
核心原则
主张简单
拥抱变化
....
3 敏捷开发
一种以人为核心、迭代、循序渐进的开发方法
敏捷宣言
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
相应变化 胜过 遵循计划
第三章 系统需求分析及可行性分析
基于计算机系统的系统分析
计算机系统
软件
硬件
人员
文档
数据库
过程
计算机系统工程
是一个问题求解的过程，目的是揭示、分析所期望的功能、性能、接口、设计限制和信息结构的表示，并把他们分配到各个系统元素中去
包括硬件工程、软件工程、人类工程和数据库工程
系统分析
一组统称为计算机系统工程的活动，着眼于所有的系统元素，而不仅仅是软件
目标
识别用户要求
系统的可行性分析
吧功能分配给系统元素
建立成本和进度限制
生产系统规格说明，形成后续工程的基础
可行性分析
目的不是解决问题，而是确定问题是否值得去解决
可行性分析的任务和步骤
针对项目确定问题域并对问题域进行概要的分析和研究，初步确定项目的规模、约束和限制条件
针对问题域中的关键和核心问题进行简要的需求分析，抽象出问题域的逻辑结构，并构建逻辑模型
从逻辑模型出发，通过小规模的设计和技术实现论证，探索出若干种可供选择的解决方案，并对每种方案进行可行性方面的论证
四个步骤
经济可行性
成本/效益估计，是否超了
成本估算技术
普遍存在的问题是成本估算往往偏低，其结果是一次次地追加费用，造成骑虎难下的局面
效益度量方法
有形效益
货币的时间价值
将未来的收益按照通用率折算到现在
投资回报率
P = F1/(1+j)+F2/(1+j)^2+...
解出方程即可求出投资回报率
已知现在的投资额，并且已经估计出将来每年可以获得的经济效益，那么，给定软件的使用寿命之后怎样计算投资回报率
纯收入
累计经济效益（折合成现在值）与投资之差
投资回收期
使累计的经济效益等于最初的投资费用所需的时间
无形效益
长期-短期利益分析
短期利益容易把握，风险较低，但利益较少，甚至没有利益
长期利益难以把握，风险较大
技术可行性
开发风险
资源可用性
技术条件
法律可行性
方案的选择
系统分析的总结
系统规则说明书
可行性分析说明书
第四章 软件需求分析
需求定义
针对待开发的软件产品，软件开发人员通过对软件产品的有拥有者和使用者的交流和调研，获取相关的业务职能、业务知识和业务流程等信息，并对这些信息进行分析和整理后形成的有关该软件产品必须提供的功能和性能等指标的规格描述
软件需求分析的目标及任务
目的：研究一种无二义性的表达工具，它能为用户和软件人员双方都接受，并能够把“需求”严格地、形式地表达出来。
任务：借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题
软件需求分析建模原则和方法
分析建模的操作性原则
问题的信息域必须被表示和理解
软件将完成的功能必须被定义
软件的行为（作为外部事件的结果）必须被表示
描述信息、功能和行为的模型必须被划分，使得可以用层次的方法揭示细节
分析过程应该遵从自顶向下，逐层细化的原则
数据模型
信息内容和关系
信息内容表示个体数据和控制对象，它们可和其他的数据和控制对象关联
信息流
信息流表示了数据和控制在系统中流动时变化的方式
信息结构
信息结构表示了各种数据和控制项的内部组织
功能模型
对进入软件的信息和数据进行编号和处理的模块，至少完成三个常见功能
输入
处理
输出
行为模型
基于功能模型的结果，进一步解释这些功能在系统中如何运行
计算机的一个功能总是处于某个状态：一种外部可观测的行为模式，它仅当某事件发生时才被改变
软件需求工程
需求开发
目的是通过调查与分析，获取用户需求并定义软件需求
3个主要活动
需求获取
需求分析
需求定义
产生文档
用户需求说明书
软件需求规格说明书
需求管理
目的是在客户与软件开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更
3个主要活动
需求确认
需求跟踪
需求变更控制
产生文档
需求评审报告
需求跟踪报告
需求变更控制报告
软件需求分析过程
需求分析阶段的工作分为7个方面
需求沟通
需求获取
用户需求说明书
需求分析与综合
需求建模
面向数据流的结构化分析方法SA
面向数据结构的Jackson方法
面向对象的分析方法OOA
建立动态模型的状态装换图、PetriNet等
制定需求分析规格说明
软件需求规格说明书
需求确认和需求评审
系统定义目标是否与用户的要求一致
文档资料是否齐全
描述是否完整、清晰、准确反映用户要求
所有其他系统成分的重要接口是否都已经描述
开发项目的数据流与数据结构是否足够，确定
图表是否清楚，不补充说明能否理解
是否已包括在规定的软件范围之内，是否已充分说明
约束条件或限制条件是否符合实际
技术风险是什么
是否烤炉过软件需求的其他方案
是否考虑了将来可能提出的软件需求
是否 详细制定检验标准，它们能否对系统定义是否成功进行确认
开发计划中的估算是否受到了影响
第六章 面向对象分析
面向对象分析综述
什么是OOA
运用面向对象的方法进行系统分析，是软件生命周期的一个阶段，具有一般分析方法共同具有的内容、目标及策略，强调运用面向对象方法，对问题域和系统职责进行分析和理解，找出描述问题域及系统职责所需的对象，定义对象的属性以及它们之间的关系，目标是建立一个符合问题域、满足用户需求的OOA模型
OOA 与 OOD 的职责划分
OOA针对现实世界中问题域与系统职责，用面向对象的方法建立起针对问题域和系统职责的模型，作为分析的结果
OOA模型不考虑与系统的具体实现相关的因素，独立于具体的实现环境
OOD则是针对系统的具体实现，运用OO方法进行系统设计
根据实现条件对OOA模型做必要的调整和修改，使其成为OOD模型的一部分
针对具体实现条件，建立人机界面、数据存储和控制驱动等模型
OOA过程
用例建模
利用用例以及用例图来捕获和描述用户的需求，从而建立系统的功能需求模型
创建领域模型
从业务需求描述和用例描述中提取“关键概念”，形成领域模型
绘制系统顺序图
从用例出发，将系统看做一个黑盒子，绘制系统顺序图
创建系统操作契约
从系统顺序图和领域模型出发，建立系统操作契约
用例建模
基本过程
1. 选择系统边界
系统边界是一个系统所包含的所有系统成分与系统以外各事物的分界线
系统边界以外是与系统进行交互的人员、设备、外部系统或组织
系统是由一条边界包围起来的未知空间，系统只通过边界上的有限个接口与外部交互
2. 识别主要参与者
概念和表示法
主要参与者
次要参与者
后台参与者
3. 识别主要参与者的目标。一般来说：第2和第3步是同时进行的
参与者可以是
人员
外部系统
设备
时钟
4. 根据参与者目标，定义用例
一个用例描述系统的一项功能，是参与者使用系统来达成目标时一组相关的成功场景和失败场景的集合
识别用例
企业级别的目标
如盈利、扩大目标市场
用户级别的目标
如取款、在线考试
子功能级别的目标
如验证用户身份
用例描述模板
用例编号
用例名称
范围
级别
主要参与者
项目相关人员及其兴趣
前置条件
后置条件
主要成功场景
拓展（或替代流程）
特殊需求
技术与数据的变化列表
发送频率
待解决的问题
用例之间的关系
包含关系
一部分行为经常会出现在多个用例中，为了避免重复，可以创建一个子功能级别的用例，并让其他的用例包含它
扩展关系
由于某种原因已有的用例文本不能被修改，但是可能又要为种种新的扩展场景和条件步骤不断修改用例
其思路是创建一个扩展或附加用例，在该用例中描述在什么情况下，从基用例什么地方开始扩展基用例的行为
继承关系
创建领域模型
领域模型就是用来描述业务领域重要概念及其相互关系的模型，一般用UML的类图来表达，其中概念用类来表示，概念之间的关系用关联、继承、聚合、组合等来表示
步骤
找出当前需求中的候选概念类
在领域模型中描述这些概念类
在概念类之间添加必要的关联来记录那些需要保存记忆的关系
在概念类中添加用来实现需求的必要属性
识别概念类
在迭代的开发过程中，经过多次迭代，可以增量地建立一个领域模型。在每一次迭代中，领域模型仅限于考虑先前和当前的场景
两种识别概念类的技巧
使用概念类分类列表
识别名词短语
添加关联
两个或多个类之间有关其实例链接的语义定义
关联常常与静态动词或动词短语相对应
指导原则
将注意力集中在需要知道型关联
识别概念类比识别关联更重要
太多的关联不仅不能有效地表示领域模型，反而容易使领域模型变得混乱
避免显示冗余或导出关联
添加属性
属性是对象的数据特性，例如重量、颜色和速度等。领域模型中的属性往往是需求建议或者暗示我们需要记忆的那些信息
绘制系统顺序图
一个系统顺序图用来表示在用例的一个特定场景中，外部参与者产生的事件、事件的顺序以及系统之间的事件
创建系统操作契约
系统事件的发生将会触发系统操作，系统操作可以通过发现系统事件来识别
系统操作使用和系统事件相同的名字，以明确表示是哪个系统事件引发的该系统操作。系统操作的参数同系统事件。
知道原则
首先从系统顺序图中识别系统事件，然后针对每一个系统事件设计对应的系统操作
对于复杂的、结果微妙的以及不清晰的系统操作，构造一个契约，作为用例的补充
要描述后置条件。描述关注下面三个方面
实例创建和删除
属性修改
关联形成和断开
后置条件的陈述应该采用过去时态的声明语气和被动语句，以强调系统状态所发生的变化
后置条件可在迭代开发中逐步完善
第七章 结构化需求分析
结构化分析发展简史
分析模型的结构
模型的核心是数据字典
实体-关系图
数据模型
数据流图
指明数据在系统中移动时如何被变换
描述对数据流进行变换的功能
功能建模
组成
数据词典
数据流此条描述
数据流名称
简要描述
数据流来源
数据流去向
数据流组成
备注
数据元素词条描述
数据元素名称
简要描述
类型
长度
取值范围
备注
数据文件词条描述
数据文件名称
简要描述
输入数据
输出数据
数据文件组成
存储方式
备注
加工逻辑词条描述
加工名称
简要描述
加工编号
输入数据流
输出数据流
加工逻辑
结构化英语
判定表
条件桩
条件项
动作桩
动作项
判定树
备注
外部实体词条描述
外部实体名称
简要描述
有关数据流
备注
状态迁移图
软件需求规格说明书
第八章 软件设计
软件设计概述
软件设计的目标
就是回答“概括地描述系统如何实现用户所提出来的功能和性能等方面的需求？”这个问题
软件设计的重要性
软件设计是开发阶段中最重要的步骤，它是软件开发过程中质量得以保证的关键步骤
将用户要求准确地转化成为最终的软件产品的唯一途径
是后续开发步骤及软件维护工作的基础
软件概要设计的步骤
1.制定设计规范
2. 软件系统结构的总体设计
按功能划分成模块的层次结构
确定每个模块的功能，建立与已确定的软件需求的对应关系
确定模块间的调用关系
确定模块间的结构，即模块间传递的消息。
优化已有结构使系统达到要求的性能指标
3. 处理方式设计
确定功能需求必须的算法
确定性能需求所必须的算法和模块间的控制方式
4. 数据结构的设计
文件系统的结构、数据库的模式、子模式，数据完整性和安全性的设计
5. 可靠性设计
质量设计
软件可靠性简言之是指程序和文档中出现的错误较少
考虑如何方便软件的修改和扩充的要求
6. 界面设计
7. 编写概要设计阶段的文档
概要设计说明书
系统目标
总体设计
数据设计
处理方法设计
运行设计
出错设计
数据库设计说明书
数据库简介、数据模式设计、物理设计
用户手册
制定初步的测试计划
8. 概要设计评审
可追溯性
接口
风险
实用性
技术清晰度
可维护性
质量
各种选择方案
限制
其他具体问题
软件详细设计的步骤
软件设计模型
静态结构
功能结构
数据结构
动态结构
以某种方式表示功能响应需求时处理数据的过程或条
取决于需求分析模型
软件设计原则
1. 抽象化
过程抽象
数据抽象
控制抽象
2. 模块化
3. 信息隐藏
4. 模块的独立性
单个模块的内聚
巧合内聚
几个模块内凑巧有一些程序代码相同，有没有明确表现出独立的功能，程序员为了减少存储吧这个代码独立出来建立一个新的模块。这是内聚程度最低的模块。缺点是模块的内容不易理解，不易修改和维护。
逻辑内聚
模块把几种相关的功能组合在一起，每次被调用时，由传送给模块的控制型参数来确定该模块应执行哪一种功能。逻辑内聚模块表明了各部分之间在功能上的相关关系。
时间内聚
又称为经典内聚。这种模块大多为多功能模块，但模块的各个功能的执行和时间有关，通常要求所有功能必须在同一时间段内执行。例如初始化模块和终止模块。
过程内聚
一个模块由几个子模块组成，且通过一定的次序执行。
流程图的某一部分划出组成模块，就得到过程内聚模块
仅包括完整功能的一部分，所以内聚程度仍然比较低，耦合程度比较高。
通信内聚
一个模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据。
通常通信内聚是通过数据流图来定义的。
序列内聚
一个模块中各个处理元素和同一个功能密切相关，而且这些处理必须顺序执行，通常前一个子模块的输出数据是后一个子模块的输入数据。
与过程内聚的区别在于过程内聚中的各个子模块之间不一定传递数据，而序列内聚子模块之间需传递数据‘’
功能内聚
一个模块中各个部分都是完成某一具体功能必不可少的组成部分，或者说一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的。
内聚性最强
优点是容易修改和维护
模块间的耦合
内容耦合
一个模块直接访问另一个模块的内部数据
一个模块不通过正常入口转到另一个模块内部
两个模块有一部分程序代码重叠
一个模块有多个入口
公共耦合
若一组模块都访问同一个公共数据环境
公共数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区
外部耦合
一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。
类似公共耦合，区别在于外部耦合中不存在依赖于一个数据结构内部各项的物理安排。
控制耦合
一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一个模块的功能
标记耦合
一组模块通过参数表传递记录信息
这个记录是某一个数据结构的子结构，而不是简单变量。
数据耦合
一个模块访问另一个模块，彼此之间是通过数据参数来交换输入、输出信息（不是控制参数、公共数据结构或外部变量）
非直接耦合
两个模块之间没有直接关系，完全通过主模块的控制和调用来实现
5. 降低模块间耦合度的方法
根据问题的特点选择适当的耦合类型
降低模块接口的复杂性
把模块的通信信息放在缓冲区
软件设计基础
1 自顶向下，逐步细化
2. 系统控制结构
3. 结构划分和结构图
水平划分
垂直划分
4. 数据结构
5. 软件过程
软件体系结构简介
三要素
程序构件的层级结构
构件之间的交互方式
数据的结构
第九章 面向对象设计
面向对象设计综述
设计过程
设计软件体系结构
设计用例实现方案
设计用户界面
模型层次化
1.用户界面层
实现要点
任何系统的用户界面能够以多少可能的形式出现，然而底层的业务逻辑却保持不变。
2. 控制器/处理器
作为完成用例任务的责任承担者，用于协调、控制其他类共同完成用例规定的功能或行为
3. 业务/领域层
实现与业务领域相关的概念，源于领域模型，如“学生”或“试卷”。它着眼于业务对象数据方面的因素，加上单个对象相关的行为。
4.持久化层
把永久存储、检索、更新和删除对象的能力封装起来，使底层的存储技术不暴露出来。
目的在于当数据存储机制或策略发送变化的时候，能减少维护工作。无论持久存储如何变化，业务/领域类都不会受影响，从而增加了应用程序的可维护性、可扩展性和可移植性
5. 系统层
为应用提供操作系统相关的功能，通过把特定于操作系统的特性包装起来，使软件与操作系统分离，这样增加了应用的可移植性。
面向对象设计原则
1. 单一职责原则SRP
就一个类而言，应该仅有一个引起它变化的原因
2. 开闭原则OCP
软件实体（类、模块、函数等）应该是可以扩展、但是不可修改的
主要特征
对于扩展是开放的
对于更改是封闭的
关键
使用抽象来识别不同类之间的共性和变化点，利用封装技术对变化点进行封装。
3. 里氏替换原则LSP
子类应当可以替换父类并出现在父类能够出现的任何地方
LSP作为一个检查工作来测试继承是否正确
4. 依赖倒置原则DIP
a. 高层模板不应该依赖于低层模板。二者都应该依赖于抽象
b. 抽象不应该依赖于细节。细节应该依赖于抽象
5. 接口隔离原则ISP
多用多个与特定客户类相关的结构比采用一个通用的涵盖多个业务方法的接口要好。
6. 组合/聚合复用原则CARP
在一个新对象里面使用一些已有对象，使之成为新对象的一部分；新对象通过向已有对象委托一部分责任而达到复用已有对象的目的。
首先考虑组合/聚合，其次才考虑继承
7. 迪米特法则LoD
最少知识原则：一个对象应到可能少的了解其他对象
设计用例实现方案
1. 创建系统动态结构。
分析出用例中的每个系统事件由哪些对象参与以及如何协同工作来完成
2. 创建系统静态结构。
根据动态结构模型，创建系统设计类图，确定类之间的调用关系和每个类应当具备的操作和方法。
往业务/领域层的类中增加属性、操作和方法，实现其从分析类到设计类的转变
设计类的来源
领域模型中的概念类
为实现而新增的一些类，如负责对象持久化的类、负责通信的类。
设计类的职责
了解型knowing职责
行为型doing职责
方法是对象操作的实现，是完成对象行为型职责的手段。
面向对象设计最关键的活动是正确地给对象分配职责
模式是面向对象软件的设计经验，是可重用的设计思想
1. GRASP设计模式，对象职责分配模式
信息专家
将职责分配给拥有履行职责所必需信息的类——即信息专家
创建者
控制器
低耦合
高内聚
多态
纯虚构
间接性
防止变异
2. 类职责分配（动态）
寻找对象职责的有效方法之一是绘制交互图。交互图体现了如何为对象分配职责。当一个对象接收了某条消息，就表明该对象具有处理该条消息的职责。
3. 持久化层设计
为每一个领域对象设计一个专门负责其持久化的类
4. 创建设计类图（静态）
第十章 结构化设计方法
系统功能结构图及数据流映射
1. 系统功能结构图结构
系统结构图中的模块
传入模块
传出模块
变换模块
协调模块
变换型数据流与变换型系统结构
取得数据
变换数据
给出数据
事务型数据流与事务型系统结构图
工作机理是接受一项事务，根据事务处理的特点和性质，选择分派一个适当的处理单元，然后给出结果。选择分派任务的部分叫做事务处理中心，或分派部件。
2. 变换映射
复审基本系统模型
复审和细化软件的数据流图
确定数据流图中含有变换流特征还是含有事务流特征
区分输入流、输出流和中心变换部分，即标明数据流的边界
进行一级“因子化”分解，设计顶层和第一层模块
进行二级“因子化”分解，设计中、下层模块
利用一些启发式原则（应用模块的独立性概念）来改进系统的初始结构图，直到得到符合要求的结构图为止。
3. 事务映射
复审基本系统模型
复审和细化软件的数据流图
确定数据流图中含有变换流特征还是含有事务流特征。
识别事务中心和每一条操作路径上的流特征。
将数据流映射到事务型系统结构图上。
“因子化”分解和细化该事务结构和每一条操作路径的结构。
利用启发式原则来改进系统的初始结构图
4. 变换-事务混合型的系统结构图
5. 改进系统功能结构图的启发式原则
模块功能的完善化
消除重复功能，改善软件结构
模块的作用范围应在控制范围之内
控制范围
本身及其所有的从属模块
作用范围
模块内一个判定的作用范围
尽可能减少高扇出结构
避免或减少使用病态联接
直接病态联接（内容耦合）
公共数据域病态联接（公共耦合）
通信模块联接
模块大小要适中
设计功能可预测的模块，避免过分受限制的模块
软件包应满足设计约束和可移植性
数据设计和文件设计的原则
设计的后处理
详细设计
界面设计
第十一章 软件实现、测试和维护
软件实现
软件测试基础
1. 软件测试概述
定义
软件测试时为了发现错误而执行“程序”的过程
目的
测试时执行程序的过程，目的在于发现错误
一个好的测试用例在于能发现至今未发现的错误
一个成功的测试是发现了至今未发现的错误的测试
2. 软件测试的原则
3.软件测试的对象
现代软件测试指为发现软件中存在的错误，对软件开发过程中形成的各项输出进行检查的过程。
三类具体活动
测试
确认
验证
4. 软件测试信息流
5. 软件测试步骤
单元测试
集成测试
确认测试
系统测试
验收测试
软件测试方法与技术
静态测试
动态测试
黑盒测试
检查错误
功能错误或遗漏
输入和输出接口的正确性
数据结构或外部信息访问错误
性能要求满足情况
初始化或终止性错误
等价类划分
等价类是指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的
有效等价类
无效等价类
错误推测法
因果图
白盒测试
检查
程序模块所有独立执行路径至少测试一次
所有逻辑判断分支至少测试一次
循环边界和运行界限内执行情况
程序内部数据结构的有效性
技术
逻辑覆盖
以程序内部的逻辑结构为基础的设计测试用例的一种白盒测试技术
语句覆盖
使得每一可执行语句至少执行一次
判定覆盖
使得程序中每个判断的取真分支和取假分支至少经历一次
条件覆盖
使得程序中每个判断的每个条件的可能取指至少执行一次
判定-条件覆盖
使得判断中每个条件的所有可能取指至少执行一次，同时每个判断本身的素有可能判断结果至少执行一次
条件组合覆盖
使得每个判断的所有可能的条件取值组合至少执行一次
路径覆盖
覆盖程序中所有可能的路径，这是最强的覆盖准则
基本路径测试
导出程序流程图的拓扑结构-流图
计算流图G的环路复杂度V(G）
环路复杂性定义为控制流图中的区域数
设E为控制流图的边数，N为图的结点数，则定义环路复杂性为V(G)=E-N+2
若设P为控制流图中的判定结点数，则有V(G)=P+1
确定只包含独立路径的基本路径集
设计测试用例
控制结构测试
基本路径测试技术是控制结构测试技术之一
其他测试技术
关于分支结构路径数的讨论
条件测试的策略
循环测试
软件测试过程
面向对象的测试方法
软件维护
在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程，即在软件运行/维护阶段对软件产品所进行的一切改动
分类
改正性维护
适应性维护
完善性维护
预防性维护
0 条评论
下一页
