计算机导论_第9章_笔记

第9章 软件工程主要内容软件工程的概念软件开发模型软件开发方法软件测试一、软件工程的概念1.1 软件及其特性软件是什么软件是计算机系统中与硬件相互依存的另一部分它是包括程序、数据及其相关文档的完整集合。程序按事先设计的功能和性能要求执行的指令序列数据使程序能正常操纵信息的数据结构文档与程序开发、维护和使用有关的图文材料软件的特性软件是一种逻辑实体而不是具体的物理实体因而它具有抽象性软件的生产与硬件不同在它的开发过程中没有明显的制造过程在软件的运行和使用期间没有硬件那样的机械磨损、老化问题软件的开发和运行常受到计算机系统的限制对计算机系统有着不同程度的依赖性软件本身是复杂的实际问题的复杂性程序逻辑结构的复杂性虽然整个工业向着基于构件的构造模式发展但是大多数软件是根据实际的顾客需求定制的软件的发展历程时期特点早期“Software” 将一系列指令组合在一起让计算机做有用的事1950年代后期计算机变得更便宜和普遍高级语言被发明1960年代早期只有少数专家完成大型软件项目1960年代中后期真正的大型软件系统开始尝试1968年以后软件工程Software Engineering诞生1.2 软件危机Software Crisis典型案例IBM 360操作系统美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这一项目花了5000人/年的工作量最多时有1000人投入开发工作写出了近100万行源程序。据统计这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。该项目负责人F. D. Brooks事后总结“正像一只逃亡的野兽落到泥潭中做垂死的挣扎越是挣扎陷得越深最后无法逃脱灭顶的灾难。程序设计工作正像这样一个泥潭……”软件危机的表现项目没有被很好地理解计划不周最终导致进度拖延没有充分的文档资料documentation软件可靠性reliability缺少度量的标准质量无法保证软件难以维护maintainability不易升级evolvability软件危机的根源与解决思路问题原因解决方法开发周期过长软件行业发展太快经验总结不足多实践积累成功和失败案例开发成本过高对自身处理能力认识不清总结、思考、提取经验难以发现所有错误——建立软件的模型和模式开发过程难以度量——更好的管理、团队组织、语言与工具、统一编码规范核心认识“软件” ≠ 编程它有自己的生命周期life cycle。大型软件系统的开发与建造桥梁、制造飞机、轮船等工程项目的开发同理。1.3 软件工程定义“软件工程”Software Engineering一词于1968年 NATO 会议德国 Garmisch上正式提出。定义软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。提出者/机构定义Boehm运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料IEEE软件工程是开发、运行、维护和修复软件的系统方法Fritz Bauer建立并使用完善的工程化原则以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法软件工程三要素要素说明方法完成软件开发各项任务的技术方法工具为方法的运用提供自动或半自动的支撑环境过程为开发高质量软件所规定的各项任务的工作步骤1.4 软件生存周期软件生存周期是指从用户需求开始经过开发、交付使用在使用中不断地增补修订直至让位于新的软件的全过程。一般包括阶段概念阶段 → 需求阶段 → 设计阶段 → 实现阶段 → 测试阶段 → 安装阶段 → 交付使用阶段 → 运行阶段 → 维护阶段注意软件成本应以软件生存期的全部费用作为计算标准。二、软件开发模型软件开发模型是软件开发全部过程、活动和任务的结构框架。它清晰、直观地表达软件开发全过程明确规定了要完成的主要活动和任务。2.1 瀑布模型Waterfall Model问题定义 → 可行性研究 → 需求分析 → 设计 → 编码 → 测试 → 运行与维护各阶段产出阶段产出物问题定义目标与范围说明书可行性研究可行性论证报告需求分析需求说明书设计设计文档编码程序测试测试报告运行与维护维护报告特点属于整体开发模型规定在开始下一个阶段的工作之前必须完成前一阶段的所有细节。2.2 增量模型Incremental Model定义概要需求 → 把需求分配给增量 → 设计系统结构 → 开发系统增量 → 验证增量 → 组装增量 → 验证系统 → 最终系统特点属于非整体开发模型推迟某些阶段或所有阶段中的细节从而较早地产生工作软件。瀑布模型 vs 增量模型对比维度瀑布模型增量模型开发方式整体开发非整体开发阶段推进前阶段完成所有细节后才能进入下一阶段推迟部分细节早期就能交付可用软件交付节奏晚期一次性交付早期逐步交付2.3 演化模型Evolutionary Model第一次试验性开发出的软件称为原型prototype。流程R1需求1→ D设计→ C/T编码/测试→ I/AS安装和验收支持→ 工作版本1 ↓ R2需求2→ D → C/T → I/AS → 工作版本2 ↓ …… ↓ Rn → 工作版本n逐步细化2.4 螺旋模型Spiral Model对于大型软件只开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来并加入了风险分析。每个螺旋周期的4个工作步骤确定目标、方案和限制条件评估方案、标识风险和解决风险开发确认产品客户评估计划下一周期工作三、软件开发方法3.1 评价软件开发方法的四个特征特征维度具体内容技术特征层次性、抽象性、并行性、安全性、正确性等使用特征易理解性、易修改性、可移植性、工具的支持、可复用性、任务范围、使用频度等管理特征易管理性、成本估算、配置管理等经济特征各种效益与代价3.2 软件开发方法分类注意由于软件与程序是不同的概念软件开发方法与程序设计方法是两个不同的概念。软件开发方法可以是针对局部的也可以是针对全局的。分类说明面向过程的开发方法典型包含分析、设计、实现、确认测试、演化维护等活动面向对象的开发方法以数据或信息为主线把数据和处理结合构成统一体——对象基于构件的开发方法使用可复用的软件构件构建系统3.3 面向过程的开发方法这类开发方法都典型地包含了分析、设计、实现、确认测试、演化维护等活动。典型的传统开发方法Jackson方法、结构化开发方法、原型化方法、HIPO法、IDEF法等。3.4 面向对象的开发方法OOSDOOSDObject-Oriented Software Development是80年代推出的一种全新的软件开发方法被誉为90年代软件的核心技术之一。核心概念对象Object 数据Attribute 操作Method对象内部的属性不允许外部用户直接改动只有当它提供了相应的**服务method时用户才能通过发送消息message**来提请它执行。面向对象方法OOM的四大要素要素说明例对象Object世界由对象构成一个邮局对象有 location、employee 等属性和 send、sell 等方法类Class物以类聚具有相同数据结构和相同操作的对象的集合class Post_office { ... }定义邮局类的模板继承Inheritance类可分层下层子类与上层父类有相同特征子类复用父类的定义无需修改父类消息Message对象间只能通过发送消息进行联系My_PO.Send(My_request, My_payment)代码示例classPost_office{private:loc_type location;emp_type employee;// ……public:voidsend(req_type request,money_type payment);voidsell(intgoods,money_type payment);// ……};main(){Post_office My_PO;req_type My_request;money_type My_payment;// ……My_PO.Send(My_request,My_payment);// ……}OOM 公式OOM Object Class Inheritance Communication with messages3.5 统一建模语言UMLUMLUnified Modeling Language诞生的初衷是统一面向对象领域中的多种方法形成大家一致认可的一套建模方法。UML 五大视图视图关注点包含模型图用例视图Use Case View系统外部功能描述、需求分析交互图、状态图、活动图逻辑视图Logical View设计词汇的逻辑结构、类/接口及其关系相当于电路原理图类图、对象图、交互图、状态图、活动图实现视图Implementation View物理部件组合成可运行系统部件图、交互图、状态图、活动图分布视图Deployment View软件在硬件和网络上的安装、分发、分布分布图、交互图、状态图、活动图进程视图Process View性能、稳定性、吞吐率——设计视图和进程视图又可被统一称为逻辑视图Logical View。3.6 软件复用和构件技术软件重用/复用Software Reuse将已有的软件成分用于构造新的软件系统。该技术是提高软件生产率和质量、降低成本的有效方法。软件构件软件构件是指在软件系统设计中能够重复使用的建构模块构件包装了一系列相互关联的操作和服务。与其他可复用软件模块的区别构件既能在设计时使用修改也能在二进制执行模块时使用或修改。构件特点构件优点高层对象技术独立于语言和面向应用程序提高开发速度只规定构件外部表现和接口不关心内部实现降低开发成本使用构件开发软件变得简单、快速和成本低廉增强应用程序灵活性使用构件必须解决复用和互操作问题降低软件维护费用四、软件测试4.1 软件测试的意义在软件开发的一系列阶段和步骤中出现错误的时机很多软件需求的描述可能有错和不完善软件的设计可能有错软件的编码可能有错结论为了发现软件缺陷软件测试必不可少。4.2 什么是软件测试定义一IEEE 标准使用人工或自动的手段来运行或测定某个系统的过程其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。定义二G.J. Myers《软件测试之艺术》“程序测试是为了发现错误而执行程序的过程。”测试的三个核心观点观点内容①测试是为了证明程序有错而不是证明程序无错误②一个好的测试用例在于它能发现至今未发现的错误③一个成功的测试是发现了至今未发现的错误的测试重要认识测试只能表明软件中存在错误不能表明软件中不存在错误。软件测试的目的是发现问题、对质量或可接受性做出判断。4.3 软件测试的流程测试需求分析 → 制定测试计划 → 设计测试用例 → 执行测试 → 提交缺陷报告 → 生成测试总结和报告步骤内容测试需求分析确定测试对象、测试范围等制定测试计划测试工作量估算、资源估算、进度安排、风险评估、制定策略等设计测试用例核心步骤针对要测试的内容设计一组测试用例执行测试——提交缺陷报告——生成测试总结和报告——4.4 测试用例测试用例 输入 预期输出组成部分说明输入输入和前提前置条件在测试用例执行之前已经存在的环境预期输出输出和后果后置条件在测试用例执行之后将产生的环境测试结果实际执行结果与预期结果是否一致4.5 测试方法按是否执行程序划分类型说明动态测试通过运行被测试程序来达到测试的目的静态测试不运行被测试程序仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性按是否查看代码划分类型别称说明黑盒测试功能性测试、基于规格说明的测试不关心内部结构只关注输入输出白盒测试结构性测试、透明盒测试、玻璃盒测试、基于程序的测试利用程序内部逻辑结构设计测试用例灰盒测试介于白盒与黑盒之间通过反编译等手段获得部分代码结构信息进行测试4.6 黑盒测试 —— 边界值测试示例三角形问题题目输入三个整数 a、b、c作为三角形三边的边长取值范围 [1, 200]输出由这三条边所确定的三角形类型等边三角形、等腰三角形、普通三角形或非三角形输入条件1 ≤ a ≤ 200 a b c 1 ≤ b ≤ 200 b a c 1 ≤ c ≤ 200 c a b变量的边界值设计取边界及附近值a {1, 2, 100, 199, 200}b {1, 2, 100, 199, 200}c {1, 2, 100, 199, 200}4.7 白盒测试利用程序内部的逻辑结构及有关信息设计或选择测试用例。一般原则保证模块中所有的独立路径至少被执行一次保证条件语句的每一个分支至少被执行一次保证循环语句都在边界条件和一般条件下至少被执行一次验证所有内部数据结构的有效性逻辑覆盖示例代码Procedure example(A, B: real; Var X: real) begin if (A 1) and (B 0) then X X / A; if (A 2) or (X 1) then X X 1; end程序包含4条路径路径路径走向L1a → c → eL2a → b → dL3a → b → eL4a → c → d语句覆盖SC — Statement Coverage定义保证被测试程序中的每一个语句至少执行一次特点语句覆盖是最弱的覆盖准则例满足语句覆盖的测试用例【(2, 0, 4)(2, 0, 3)】覆盖路径 L1a→c→e。因为所有可执行语句都在 L1 上选择 L1 设计测试用例即可覆盖所有语句。测试用例格式【输入的(A, B, X)预期输出的(A, B, X)】判定覆盖DC — Decision Coverage定义又称分支覆盖保证程序中每一个判断的取真分支至少经历一次取假分支至少经历一次例选择路径 L1 和 L2即可满足判定覆盖【(2, 0, 4)(2, 0, 3)】覆盖 L1a→c→e—— 真分支【(1, 1, 1)(1, 1, 1)】覆盖 L2a→b→d—— 假分支