《软件工程复习重点收集》由会员分享，可在线阅读，更多相关《软件工程复习重点收集（57页珍藏版）》请在金锄头文库上搜索。
1、建筑工程 | 参考借鉴三大块内容：软件危机与软件工程传统软件开发方法面向对象方法一、 软件危机与软件工程：软件、软件危机、软件生存期、软件开发模型、软件管理1、 软件： 软件是能够完成预定功能和性能的可执行的计算机程序 +使程序正常运行所需要的数据 +描述软件开发过程及其管理、程序的操作和使用的有关文档。文档：分开发、管理、用户、维护文档，作用是记录及解决不可视性、通信与交流、管理与维护、用户效劳2、 软件危机a) 表现：软件本钱高、难于控制开发进度、软件工作量估计困难、软件质量低、软件修改维护困难b) 原因：需求问题(描述不准确、理解不一致)、管理问题、方法和工具问题、软 件本身的特点3、
2、软件生存期：a) 三个时期： 定义时期(软件方案、需求分析)开发时期(软件设计、编码实现、测试)使用和维护时期(维护)b) 六个阶段：软件方案需求分析设计编码测试使用与维护c) 生命周期方法特点：顺序性、依赖性，推迟程序的物理实现、质量保证的观点(利于尽早发现错误，如阶段文档、评审)4、 软件开发模型a) 瀑布模型：文档驱动 i. 阶段划分、分而治之、控制开发过程的复杂性ii. 自顶向下、由抽象到具体，顺序进展 优点：标准管理开发过程、文档驱动 缺点：初期系统的需求难以完全确定、文档驱动、周期长b) 原型模型：i. 针对：软件开发初期需求难以确定ii. 根本思想：快速建立原型，完善用户需求ii
3、i. 优点：用户参与、快速iv. 缺点：快速弱功能、对开发环境要求高c) 螺旋模型(风险驱动)d) 增量模型(模块、功能驱动)e) 迭代模型f) 喷泉模型5、 软件管理a) 区别于其他工业产品生产管理的特点b) 主要内容：开发方案与进度管理、文档管理、人员组织管理、本钱管理、质量管理二、 传统软件工程方法：a) 软件方案i. 问题定义ii. 可行性研究1. 经济可行性2. 技术可行性3. 法律可行性b) 需求分析i. 构造化分析SAii. 面向数据流的分析方法1. DFD四个组成局部(表示方法、命名)2. DFD作图：需求描述DFD3. 层次分解法(保持父图和其子图的平衡)4. 数据字典(符号
4、)c) 软件设计i. 总体设计1. 模块独立性：高内聚2. 作用域是控制域的子集3. 单入单出4. 规模、深度、宽度、扇入、扇出适当ii. 传统设计方法1. 面向数据流的设计方法(数据流图)a) 构造化设计SD-对应有SD构造化需求分析、SP构造化实现b) DFD软件构造(层次图)i. 变换设计ii. 事务设计c) 优缺点2. 面向数据构造的设计方法a) Jackson方法b) Jackson图i. 三种元素间的逻辑关系：顺序、选择、重复ii. 可描述两种数据构造:数据构造、程序构造c) 思想：数据构造与程序处理过程相互转换d) 步骤：I/O DS对应关系Program Structure细化
5、求精e) 优缺点：i. 数据入手ii. 简化数据处理程序的设计iii. 模块与独立性原那么没有给予应有的重视iv. 求提供对复杂系统设计过程的支持3. Parnas方法iii. 详细设计1. 构造化程序设计SPa) 高效率-良构造b) 三种根本控制构造、单入单出2. 过程设计的工具d) 实现/编码i. 语言1. 功能等价2. 描述问题方便性有差异a) 例如：OOPL-非OOPLii. 程序设计风格e) 软件测试i. 目标ii. 方法1. 正确性证明2. 静态测试3. 动态测试a) 黑盒(功能)测试i. 等价类划分ii. 边界值分析iii. 错误推测b) 白盒(构造)测试i. 语句覆盖ii. 判
6、定覆盖iii. 条件覆盖iv. 判定条件覆盖v. 条件组合覆盖iii. 步骤f) 软件维护i. 四种类型1. 校正性2. 适应性3. 完善性4. 预防性ii. 提高可维护性的措施三、 面向对象方法(Object-oriented Method)a) OOM与CM比照：区别优点i. 思维方式 iv. 稳定性ii. 可重用性 v. 可维护性iii. 大型软件b) OOSE方法i. 三个阶段、五个模型、ii. USE CASE第二章传统软件工程方法：软件方案具体任务：工程定义、可行性分析、软件方案其中：可行性分析：1、 可行性研究实质：可行性研究试一次大大压缩和简化了的系统分析和设计过程，也就是在较
7、高层次上以较抽象的方式进展的系统分析和设计过程。2、 主要内容： a) 经济可行性:资金有无落实、本钱效益分析b) 技术可行性:开发的风险、资源的有效性、技术方案c) 操作可行性:用户组织内的管理制度、人员素质、操作方式等是否可行。d) 法律及社会可行性e) 开发方案的选择:折衷手段权衡。3、 可行性研究的主要步骤：a) 复查系统规模b) 研究正在使用的旧系统c) 导出高层逻辑模型d) 重新定义问题e) 导出多种解法f) 推荐行动方针g) 草拟开发方案h) 书写文档并提交审查系统流程图(物理建模工具)：会读、读懂。数据流图：概述 描绘系统的逻辑模型的工具 DFD: Data Flow Diag
8、ram 描绘信息流和数据从输入移动到输出的过程中所经受的变换数据从哪里来，到哪里去，经过怎样的处理，保存在哪里 没有任何具体的物理部件，只是描绘数据在软件中流动和被处理的逻辑过程。是系统逻辑功能的图形表示。是分析员和用户沟通的工具 是后期设计的出发点DFD的绘制一般采用自顶向下、逐步细化的方法，主要步骤如下：明确系统界面。识别出那些不受系统控制但又影响系统运行的外部环境。绘制根本系统模型。根本系统模型由假设干源点、终点和一个根本处理组成，说明系统对数据加工变换的根本功能。逐层细化根本系统模型得到功能级DFD和详细DFD。下面即分层数据流图。假设一家工厂的采购部每天需要一张定货报表，报表按零件编
9、号排序，表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据；零件编号零件名称、定货数量、目前价格、主要供给者和次要供给者。 零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。从问题描述中提取数据流图的四种成分。首先考虑数据的源点和终点： “采购部每天需要一张定货报表 “通过放在仓库中的CRT终端把事务报告给定货系统可知：采购员是终点仓库管理员是源点接下来考虑处理： “采购部每天需要一张定货报表 -采购部需要报表 “零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。 -事务的
10、后果是改变库存量可知：产生报表是一个处理处理事务是另一个处理最后考虑数据流和数据存储： 系统把定货报表送给采购部-定货报表 事务需要从仓库送到系统中-事务-需把事务数据存储起来产生报表和处理事务在时间上不匹配, 当某种零件的库存数量少于库存量临界值时就应该再次定货，而每天打印一次定货报表-需把定货信息存储起来可知：定货报表、事务是数据流(数据流如报表包含零件编号零件名称、定货数量、目前价格、主要供给者和次要供给者等信息。事务包含零件编号、事务类型、数量等。)库存清单、定货信息是数据存储根本系统模型：功能数据流图：注意符号进一步分解处理事务：命名1为数据流(或数据存储)命名 名字应代表整个数据流
11、(或数据存储)的内容，而不是仅仅反映它的某些成分 不要使用空洞的、缺乏具体含义的名字(如“数据、“信息、“输入之类) 如果在为某个数据流(或数据存储)起名字时遇到了困难，那么很可能是因为对数据流图分解不恰当造成的2 为处理命名 通常先为数据流命名，然后再为与之相关联的处理命名，表达了人类习惯的“由表及里的思考过程 名字应该反映整个处理的功能 名字最好由一个具体的及物动词，加上一个具体的宾语组成。 通常名字中仅包括一个动词 如果在为某个处理命名时遇到困难，那么很可能是发现了分解不当的迹象，应考虑重新分解应注意的问题1 是数据流不是控制流画数据流不是控制流；数据流图反映系统“做什么，不反映“如何做
12、，因此箭头上的数据流名称只能是名词或名词短语，整个图中不反映加工的执行顺序。2 一般不画物质流数据流反映的是能用计算机处理的数据，并不是实物，因此系统的数据流图上一般不要画物质流。3 加工的画法每个加工至少有一个输入数据数据流图的用途：1建立新系统逻辑模型的工具2作为与用户和开发人员交流信息的工具3作为分析、设计乃至维护的依据数据字典：概念 数据字典是关于数据的信息的集合 DD: Data Dictionary 是对DFD中包含的所有元素的定义的集合 在分析、设计和维护过程中供查阅用内容1数据流2数据流分量即数据元素3数据存储4处理IPO图或PDL更加方便是对上述四类元素的定义具体信息 名字数
13、据、控制项、数据存储或外部实体的主要名称 别名该元素等价的其他名字，尽量减少 使用地点与方式使用数据或控制项的处理的列表，以及使用这些对象的方式(例如作为处理的输入，从处理输出， 作为数据存储，作为外部实体) 内容描述描述数据或控制项内容的符号 补充信息关于数据类型、预置值、限制等的其他信息 软件工程的量化估算n 本钱估算 & 工作量估算n 工程进度安排行本钱估算 阶段本钱估算甘特图：历史悠久、应用广泛的进度方案工具进度安排的任务网络图优点：简单，能动态地反映开发进展缺点：难以反映多个任务间的逻辑关系第三章传统软件工程方法：需求分析需求分析n 1 目标和任务n 2 需求获取技术n 3 需求内容
14、n 4 需求建模方法需求分析任务n 问题分析n 需求描述n 需求评审需求建模方法1. 面向数据流的分析方法2. 面向对象的分析方法3. 面向数据构造的分析方法需求工程的任务需求开发包含四个过程：需求获取、需求整理与分析、需求定义、需求验证。需求分析的具体任务：需求获取、确定和分析需求、开发原型系统、编写SRS、需求验证、变更管理、修正方案软件需求及需求的分类软件需求：以一种清晰、简洁、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对系统的约束。表达做什么而不描述如何做。Requirement is the Basics of Quality，软件需求的作用：分理解现实中的业务问题，并作为软件设计的根底；为软件工程的本钱、时间、风险估计提供准确的依据；少开发工作量，防止将时间与资源浪费在设计与实现错误的需求上；通提供需求文档和需求基线，来有效的管理系统演化与变
