复习,软件工程学概述 可行性分析与需求分析 总体设计 详细设计 实现 维护 面向对象方法学引论 面向对象分析 面向对象设计,上海大学计算机学院,1,软件工程学概述,软件危机 定义：指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 典型表现： 开发成本和进度的估计常常很不准确； 用户对“已完成的”软件系统不满意； “闭门造车”；软件质量不可靠； 软件常常是不可维护的； 软件成本的比例逐年上升； 软件产品“供不应求”； 产生软件危机的原因 软件的规模加大、复杂性提高、性能增强; 软件是逻辑产品, 尚未完全认识其本质和特点; 缺乏系统的开发、维护大型软件项目的技术手段和管理方法； 用户和软件开发人员的理解鸿沟； 错误的认识和作法,上海大学计算机学院,2,软件工程学概述,软件工程 定义 软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它。 本质特性 软件工程的中心课题是控制复杂性 和谐地合作是开发软件的关键 ,上海大学计算机学院,3,软件工程学概述,软件工程的7条基本原理 用分阶段的生命周期计划严格管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 结果应能清楚地审查 开发小组的人员应该少而精 承认不断改进软件工程实践的必要性,上海大学计算机学院,4,软件工程学概述,软件生命周期是软件产品或系统一系列相关活动的全周期。 软件生命周期的3个大阶段 软件定义: 确定软件开发总目标；确定工程的可行性；导出实现策略及系统功能；估计资源和成本，并且制定工程进度表。 问题定义、可行性研究、需求分析 软件开发: 具体设计和实现在前一个时期定义的软件 总体设计、详细设计、编码和单元测试、综合测试 软件维护: 使软件持久地满足用户的需要,上海大学计算机学院,5,软件工程学概述,生命周期中各阶段的任务 1. 问题定义： “要解决的问题是什么?”； 确定用户要求解决的性质、工程的目标和规模。 2. 可行性研究： “对于上一个阶段所确定的问题有行得通的解决办法吗?”， 经济可行性、技术可行性、法律可行性、不同的方案 3. 需求分析： “为了解决这个问题，目标系统必须做什么”， 确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景。 4. 总体设计（概要设计）： “概括地说，应该怎样实现目标系统?”； 设计出实现目标系统的几种可能的方案。推荐一个最佳方案。 5. 详细设计： “应该怎样具体地实现这个系统呢?”； 设计出程序的详细规格说明。 6. 编码和单元测试： 写出正确的容易理解、容易维护的程序模块； 仔细测试编写出的每一个模块。 7. 综合测试： 集成测试和验收测试，现场测试或平行运行 8. 软件维护： 使系统持久地满足用户的需要。包括： 改正性维护，适应性维护，完善性维护，预防性维护。,上海大学计算机学院,6,软件工程学概述,生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。 典型的过程模型 瀑布模型(Waterfall model) 快速原型开发模型(Rapid Prototyping model) 增量模型(Incremental model) 螺旋模型(Spiral model) 喷泉模型 其它模型 极限编程XP(eXtreme Programming) RUP(Rational Unified Process) 建造修补模型(Build-and-fix model),上海大学计算机学院,7,软件工程学概述,瀑布模型 特点 阶段间具有顺序性和依赖性 推迟实现的观点 清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现。 质量保证的观点(文档驱动) 每个阶段都必须完成规定的文档 每个阶段结束前都要对所完成的文档进行评审 缺点 开发过程一般不能逆转，否则代价太大。 规格说明很难理解：“我知道这是按我的要求做的，但不是我想要的样子。” 软件的实际情况必须到项目开发的后期客户才能看到。,上海大学计算机学院,8,软件工程学概述,增量模型 把软件产品作为一系列增量构件来设计、编码、集成和测试。 优点 每个阶段交付一个可用的产品。 减少一个全新产品给客户带来的心理上的影响。 分阶段地交付产品不需要大的资金支出。 需求经常变化，增量模型的灵活性使其具有更加优越的适用性。 缺点 需要一个开放的结构，方便构件的加入。,上海大学计算机学院,9,软件工程学概述,上海大学计算机学院,10,可行性分析与需求分析,需求分析的任务 准确地回答“系统必须做什么?” “分析软件需求和书写软件需求规格说明书” 软件需求 用户解决问题或达到目标所需要的条件或能力； 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力 反映上述两个定义中所描述的条件或能力的文档说明 需求层次：业务需求用户需求功能与非功能需求 具体任务 确定对系统的综合要求功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束、逆向需求、扩展需求 分析系统的数据要求 导出系统的逻辑模型 书写软件需求规格说明书 修正系统开发计划,上海大学计算机学院,11,需求分析,数据流图 数据流图（DFD）符号 数据源点/数据终点 数据流 数据存储 加工/处理 根据描述画数据流图,上海大学计算机学院,12,总体设计,总体设计的任务 “概括地说，系统应该如何实现？” 系统划分:即确定组成系统的程序、文件、数据库、人工过程和文档等 设计软件的结构：即确定每个程序是由哪些模块组成，以及这些模块相互间的关系。,上海大学计算机学院,13,总体设计,设计原理 模块化 模块化的根据 C（P1P2） C（P1） C（P2） E（P1P2） E（P1） E（P2） 抽象 抽象就是抽出事物的本质特性而暂不考虑它们的细节 逐步求精 为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。 信息隐藏和局部化 信息隐藏原理：应该这样设计和确定模块，使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的。 局部化: 把一些关系密切的软件元素物理地放得彼此靠近。 模块独立 每个模块完成一个相对独立的子功能，并且与其它模块间的接口简单。 模块独立性的衡量标准 模块内聚（Cohension） ：模块内各元素交互的程度 模块耦合（Coupling） ：模块间交互程度,上海大学计算机学院,14,总体设计,各种耦合的含义 设计时力争做到低耦合。应该采取的设计原则是：尽量使用数据耦合，少用控制耦合和特征耦合，限制公用耦合的范围，完全不用内容耦合。,上海大学计算机学院,15,耦合 内容耦合 共用耦合 控制耦合 印记（特征）耦合 数据耦合,总体设计,各种内聚的含义 设计时力争做到高内聚，并且能够辨认出低内聚的模块，通过修改设计提高模块的内聚程度。,上海大学计算机学院,16,内聚 偶然性内聚 逻辑性内聚 时间性内聚 过程性内聚 通信性内聚 顺序内聚 功能性内聚 信息性内聚,总体设计,启发规则 改进软件结构提高模块独立性 模块规模应该适中 深度、宽度、扇出和扇入都应适当 模块的作用域应该在控制域之内 模块的作用域：受该模块内一个判定影响的所有模块的集合。 模块的控制域：模块本身以及所有直接或间接从属于它的模块的集合。 所有受判定影响的模块应该都从属于做出判定的那个模块，最好局限于做出判定的那个模块本身及它的直属下级模块。 力争降低模块接口的复杂程度 设计单入口单出口的模块 模块功能应该可以预测,上海大学计算机学院,17,总体设计,上海大学计算机学院,18,模块的判定作用范围 (a) 差的结构图； (b) 不理想的结构图； (c) 理想的结构图,总体设计,结构图 描述软件系统的模块层次结构，清楚地反映出程序中各模块之间的调用关系和数据传递。,上海大学计算机学院,19,选择调用,循环调用,总体设计,面向数据流的设计方法 基本思想： DFD 结构图 两种信息流类型 变换流：掌握从变换流到初始结构图的转换 事务流,上海大学计算机学院,20,详细设计,详细设计的任务 不是具体地编写程序，而是设计程序的“蓝图”，确定每个模块的处理过程。 结构程序设计 自顶向下逐步求精； 具有单入、单出的控制结构（取消GOTO语句）； 结构化定理：任何单入口单出口的程序都可以由“顺序”、“选择”和“循环”三种基本结构实现。 过程设计的工具（重点是画图） 程序流程图 盒图 PAD图 判定表,上海大学计算机学院,21,详细设计,程序流程图的基本符号,上海大学计算机学院,22,详细设计,PAD图的基本符号,上海大学计算机学院,23,详细设计,判定表,上海大学计算机学院,24,实现,编码风格 编码风格的作用就是使代码容易读； 风格良好的代码更容易阅读和理解，错误更少； 使用一致和有意义的标识符名 用缩进显示程序结构 用加括号的方式排除二义性 避免大量使用循环嵌套和条件嵌套 当心运算符的副作用 把数定义称常量 利用sizeof()计算对象的大小 清晰的代码，而非最巧妙的代码 程序的注释 序言性注释和功能性注释 对一段程序注释，而不是每一个语句 使用数据结束标记（EOF、BOF），不要指定数据的数目来判断文件的结束。,上海大学计算机学院,25,实现,测试 测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。测试是为了发现程序中的错误而执行程序的过程。 调试的目的是诊断并改正错误。 对软件规格说明、设计和编码的最后复审。 开发总工作量的40%以上，极端情况下，其他开发步骤总成本的3倍到5倍。 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。 成功的测试是发现了至今为止尚未发现的错误的测试。 测试只能查找出程序中的错误，不能证明程序中没有错误。 Pareto原理：80%的错误很可能是20%的模块造成的。 从“小规模”测试逐步到“大规模”测试。 穷举测试是不可能的。 为了达到最佳的测试效果，应该由独立的第三方从事测试工作。,上海大学计算机学院,26,实现,测试方法 黑盒测试：又称功能测试或数据驱动测试 白盒测试：又称结构测试或逻辑驱动测试 测试步骤 模块测试（单元测试） 在这个测试步骤中所发现的往往是编码和详细设计的错误 子系统测试 模块放在一起形成一个子系统来测试 着重测试模块的接口 系统测试 经过测试的子系统装配成一个完整的系统来测试 发现的往往是软件设计中的错误，也可能发现需求说明中的错误 验收测试（确认测试） 它的目标是验证软件的有效性（如果软件的功能和性能如同用户所合理期待的那样，软件就是有效的） 用户积极参与，可能主要使用实际数据进行测试 发现的往往是系统需求说明书中的错误 平行运行,上海大学计算机学院,27,实现,回归测试 回归测试是指重新执行已经做过的测试的某个子集，以保证变化（程序改错、新模块加入等）没有带来非预期的副作用。 () Alpha测试 Alpha测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。总之，Alpha测试是在受控的环境中进行的。 () Beta测试 软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，是在开发者无法控制的环境下进行的软件现场应用。,上海大学计算机学院,28,实现,集成测试方法 非渐增式集成 先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序。 先进行单元测试，再进行集成测试 渐增式集成将单元测试与集成测试结合在一起，把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。 自顶向下（Top-Down）集成 自底往上（Bottom-Up）集成 三明治式（Sandwich）集成,上海大学计算机学院,29,实现,几种集成测试方法的优缺点,