软件工程培训-基础篇

泰思通研发中心软件工程培训泰思通软件（上海）有限公司上海研发中心 讲座提纲基础篇 第一章 软件工程概念第二章 软件开发模型 第三章 软件开发技术管理篇 第四章 软件风险管理 第五章 软件项目管理与计划第六章 软件过程改进现代篇 第七章 面向对象开发方法及过程 第八章 软件复用技术 第九章 分布式部件技术 基础篇第一章 软件工程概念软件发展现状软件危机软件工程及其发展阶段软件工程框架软件发展趋势（软件产业化）1.1 软件发展现状（1）已经存在大量正在运行的软件。金融、电信、航空航天等（2）软件的应用范围不断扩大。商务、交通、家电等，软件无处不在。（3）软件的规模与复杂性持续增加非常大规模系统：从50万行增加到1000万行，扩大了20倍；复杂性：a.子系统数目越来越多；b.计算机应用从数值计算开始发展到几百万条指令的大型企业业务应用，再发展到几千万终端用户直接交互工作的网络应用。（4）出现了大量与软件相关的标准。CORBA、UML、XML、TMN、CWM等。（5）软件危机仍然存在（软件脱节）1968-2000：软件效率、质量、进度、预算无法控制。1.1 软件发展现状问题：1.没有“计算机”和“软件”，世界会是什么样子？人们的生活已经无法离开计算机软件。2.如何更多、更快、更方便、更好地开发出软件？工程化地管理软件开发。（1968年NATO提出软件工程的概念）SE：倡导以工程的原理、原则和方法进行软件开发，以期解决当时出现的“软件危机”。3.如何重用过去的经验呢？软件体系结构风格、设计模式、部件等。4.在分布式网络环境下如何提高软件的适应能力呢？CORBA、COM/DCOM、Java Beans等；EAI。1.2 软件危机1.什么是软件危机？指在计算机软件开发和维护过程中所遇到的一系列问题。（1）软件开发无计划性：不能正确估计软件开发成本和进度，无法估计工作量，难于控制开发进度。（2）软件需求不充分：需求是设计的基础，需求不充分直接导致软件产品不可靠，满足不了用户的需求，甚至无法使用。（3）软件开发过程无规范性：各行其是，没有文档。（软件工程过程中的四个基本活动：规格说明、开发、确认、演进）（4）软件无评测手段：软件质量无法保证。（软件产品质量度量、软件过程质量控制和保证）1.2 软件危机2.什么原因导致软件危机的？（1）软件的固有特征：软件是复杂的。实际问题的复杂性、感知接受的复杂性、理性表达的复杂性。（另外，软件规模不断扩大。）（2）外部原因：软件开发范型（模型）软件设计方法（方法）软件开发支持（工具）软件开发管理（过程）1.3 软件工程及其发展阶段软件工程是一类求解软件的工程，它应用计算机科学、数学（用于构造模型和算法）和管理科学（用于计划、资源、质量和成本等的管理）等原理，借鉴传统工程（用于制定规范、设计范型、评估成本、权衡结果）的原则和方法，创建软件以达到提高质量、降低成本的目的。软件工程是一门指导计算机软件开发和维护的工程学科。1.3 软件工程及其发展阶段软件工程经历了30多年的历史，其发展大致可以划分为两个阶段：1、60年代末80年代初状况：软件系统的规模、复杂性以及在关键领域的广泛应用，促进了软件开发过程采纳工程化的方法进行管理。研究：开发模型、支持工具、开发方法。成果：瀑布模型、结构化语言（pascal等）、结构化方法、各种管理方法（如费用估算、文档复审）。事件：前期主要研究系统实现技术；后期则开始强调管理和软件质量。焦点：软件项目 1.3 软件工程及其发展阶段2、80年代初现在状况：“软件工厂”的概念已经提出。研究：软件生产技术，特别是软件复用技术和软件生产管理的研究和实践。成果：提出了具有广泛应用前景的面向对象方法和相关的编程语言。事件：软件过程改进。在工业实践中建立起一种量化的评估程序，判定软件组织成熟的程度。焦点：软件过程 1.3 软件工程及其发展阶段近几年：研究从过程管理转向产品开发，更加注重新的程序开发范型和软件生产。范围：面向agent语言、复用技术、需求分析规格说明的形式化研究、高智能高自动化的CASE成为热点。1.4 软件工程框架软件工程的框架是由软件工程目标、软件工程活动和软件工程原则三个方面的内容构成的。开发范型设计方法支持过程管理过程需求设计实现确认支持可用性正确性合算性软件工程活动维软件工程目标维软件工程原则维 1.4.1 软件工程目标目标：生产具有正确性、可用性以及开销适宜的软件产品。正确性：软件产品达到预期功能的程度。可用性：软件基本结构、实现及文档为用户可用的程度。开销适宜：软件开发、运行的整个开销满足用户要求的程度。决定了：软件过程、过程模型和工程方法的选择。1.4.2 软件工程活动活动：生产一个最终满足需求且达到工程目标的软件产品所需要的步骤。1、需求：问题分析：需求获取和定义，又称软件需求规约。需求分析：生成软件功能规约。2、设计：概要设计：建立整个软件的体系结构，包括子系统、模 块以及相关层次的说明、每一模块的接口定 义等。详细设计：产生程序员可用的模块说明，包括每一模块 中数据结构说明及加工描述。3、实现：把设计结果转换为可执行的程序代码。4、确认：贯穿整个开发过程，对完成的结果进行确认，保证产品 满足用户的要求。5、支持：修改和完善活动。1.4.3 软件工程原则软件工程的四条基本原则：1、采取适宜的开发模型，控制易变的需求；2、采用合适的设计方法：需要软件模块化、抽象与信息隐藏、局部化、一致性以及适应性等，需要合适的设计方法的支持。3、提供高质量的工程支持：软件工具和环境对软件过程的支持。4、重视开发过程的管理：有效利用可用的资源、生产满足目标的软件产品、提高软件组织的生产能力等。1.5 软件发展趋势（1）遗留(legacy)软件将继续发挥作用。（2）软件应用范围将继续扩大，成为信息社会的基础设施。（3）网络化软件将是发展重点。（4）软件的可靠性与安全性日趋重要。（5）工业化生产是必由之路。1.5 软件发展趋势软件工业化生产时代的基础技术：软件过程技术：以软件过程改进为中心 软件过程成熟度模型CMM 个体软件过程PSP 群体软件过程TSP 建造支持软件过程的环境 面向对象技术 构件重用技术 基础篇第二章 软件开发模型软件生命周期瀑布模型演化模型螺旋模型喷泉模型 2.1 软件生命周期软件生命周期：制定计划、需求分析和定义、软件设计、程序编写、软件测试、运行/维护等六个步骤。软件开发模型：是从软件项目需求定义直至软件经使用后废弃为止，跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。2.2 瀑布模型 2.2 瀑布模型1970年，W.Royce提出瀑布模型。特征：活动的输入来自上一活动的输出；完成该项活动的内容；活动的输出传给下一活动；对活动的实施工作进行评审。适合：需求明确的任务。优点：以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证了软件产品及时交付，并达到预期的质量要求。缺点：成品时间长；缺乏灵活性。2.3 演化模型项目开发初始阶段对需求的认识不够清晰，使得开发工作出现再开发在所难免。经验告诉我们：开发“两次”后的软件能较好地满足用户的要求。第一次：试验开发，目的是探索可行性，弄清楚项目的需求。第二次：在第一次的原型基础上进行开发，从而获得较为满意的软件产品。2.3 演化模型适合：事先不能清晰和完整定义需求的软件开发。需求分析软件设计程序编码软件测试软件集成软件评审需求分析软件设计程序编码软件测试软件集成软件评审反馈“第一次”“第二次”2.4 螺旋模型对于大型项目而言，事先不能完整清晰地定义需求是常事，而且开发一个原型是远远不能解决问题的，需要开发内容逐步丰富的多个原型。大型项目的规模和复杂性增加，软件开发过程中必然存在着许多风险问题，风险分析是保证项目成功的必要手段。2.4 螺旋模型 2.4 螺旋模型 2.5 喷泉模型软件开发的固有特征：1、迭代 多次重复、演进。2、无间隙 各阶段间无明显的界限。支持分析和设计结果的自然复用。适用：面向对象的软件开发过程。2.5 喷泉模型 基础篇第三章 软件开发技术软件开发过程软件开发的基本原则需求分析软件体系结构软件设计软件测试软件维护 3.1 软件开发过程定义：软件过程是指将用户的要求转变成软件产品的过程，是人们用于开发和维护软件及其相关产品（项目计划、设计文件、编程代码、测试、用户手册）的一系列活动、方法、实践和改造。软件过程的规划由不同开发机构针对不同应用项目确定，是由一组有组织的活动组成，通常包括四种基本的活动：1.软件规格说明：规定软件的功能及其运行限制；2.软件开发：产生满足规格说明的软件；3.软件确认：确认软件能够完成客户提出的要求；4.软件演进：为满足客户的变更要求而进行演进。3.1 软件开发过程软件过程的研究重点：软件生产和管理。因此，不仅要有工程的观点，还要有系统的、管理的、运行的、用户的观点。软件过程的分类：1.基本过程：与软件生产直接相关的过程 2.支持过程：支持软件生产的过程 3.组织过程：与软件生产组织有关的过程 4.剪裁过程：将上述过程和活动剪裁到具体应用中 的过程。3.1.1 基本过程类过程名执行者活动内容获取过程项目委托方确定需求；招标；签订合同；对供应方的监督；验收完成。供应过程项目承包方理解需求；投标；签订合同；计划；实施；控制；评审评价；交付。开发过程软件开发人员过程实施准备；系统需求分析；系统结构设计；软件需求分析；软件体系结构设计；软件详细设计；软件编码和测试；软件集成；软件合格测试；系统集成；系统合格测试；软件安装；验收支持。运行过程用户运行准备；运行测试；产品转移；运行；运行支持；运行评价。维护过程维护人员过程实施准备；问题分析和修改设计；修改实施；对维护的评审和验收；软件移植；软件退役。3.1.2 支持过程类过程名执行者活动内容文档过程1.由软件开发组织自己实施。2.由独立的第三方机构实施。3.作为一种服务由客户实施。制订文档编制计划；设计和开发文档；制作和发行文档；文档维护。配置管理过程确定软件配置项和基线；控制配置项的修改和交付；记录配置项的完成和修改情况；保证配置项的完整、相容和正确性；控制配置项的存储和提交。质量保证过程软件产品质量保证；软件过程质量保证。验证过程合同验证；过程验证；需求验证；设计验证；代码验证；集成验证；文档验证。确认过程类似于验证的活动，区别是：确认针对软件是否正确地满足客户的要求，验证针对软件是否按照规范要求开发。评审过程项目管理评审；技术评审审计过程问题解决过程 3.1.3 组织过程类过程名执行者活动内容管理过程 软件开发组织进度管理；成本管理；质量管理；人员管理；资源管理；标准化管理。基础设施过程定义、建立和维护各开发过程中所需要的基础设施。改进过程评估相关过程并实施分析、改进。运行过程运行准备；运行测试；产品转移；运行；运行支持；运行评价。培训过程制定培训计划；实施培训过程；控制培训质量。3.1.4 剪裁过程类定义：针对特定领域的软件工程，对选定的过程模型和标准进行剪裁，以形成这一工程的模型及标准，形成该工程的各个软件过程和活动。步骤：1.指明工作环境；2.收集信息；3.选取任务、活动、过程；4.编制文档。3.2 软件开发的基本原则原则是指有关软件工程的一些基本事实、规则和一些假定，超越具体技术、工具和语言之上，普遍适用。原则涉及软件开发过程，也涉及软件产品本身。仅有原则不够，软件开发还需要技术方法、方法学、工具的支持。3.2 软件开发的基本原则严格性和形式化原则：约束创造性。分隔原则：时间、质量指标、视图、规模、产品与开发方法分离。模块化原则：功能、逻辑、状态三个属性。抽象原则：过程、数据和控制抽象。预期变动原则：算法、数据结构、体系结构、外部设备、社会环境。通用/复用性原则：软件重用。递增式原则：不要求在开发前就有一个完整的需求定义。3.3 需求分析需求分析任务需求分析的过程需求分析的方法结构化分析方法面向对象分析方法需求分析方法的比较 3.3.1 需求分析的任务当前系统目标系统物理模型物理模型逻辑模型模型化具体化抽象化实例化怎么做做什么导出理解需求表达需求参考当前系统建立目标系统模型逻辑模型 3.3.2 需求分析的过程需求获取 确定客户或用户的要求是什么的信息收集过程。研究可行性分析报告和系统实施计划，明确系统的目标要求。建立分析所需要的通信途径，保证需求获取得顺利进行。客户和用户系统分析员开发者：设计人员、编程人员、项目管理者SRS 3.3.2 需求分析的过程需求分析 从用户最初的非形式化需求到满足用户要求的软件产品需求的映射过程。功能性需求：说明系统各功能部件与环境之间的相互作用的本质。非功能性需求：反映系统质量和特性的额外要求。过程需求产品需求外部需求交付需求；实现方法需求；标准需求等。可用性需求；效用需求；可靠性需求；可移植性需求；可重用性需求；安全保密性需求等。法规需求；费用需求；互操作性需求；开放性需求等。3.3.2 需求分析的过程编写需求分析文档 清晰准确地表达已经确定下来的需求。软件需求规格说明书：功能和性能要求数据要求说明书：软件输入输出的要求初步的用户手册：用户界面和使用要求 3.3.2 需求分析的过程需求分析评审验证 对需求的正确性、完整性和清晰性以及其他需求给予评价。SRS应该具备的质量：正确性；无二义性；完整性；可验证性；一致性；非计算机人员能够理解；可修改性；可跟踪性；注释。3.3.3 需求分析方法按照信息的流向、结构、和内容三个方面可以将现有的需求分析方法划分为：面向信息流向：结构化分析方法面向信息结构：Jackson分析方法面向信息内容：面向对象分析方法描述系统需求时可以从系统的功能、行为和信息三个方面进行，侧重点可以不一样。3.3.4 结构化分析方法结构化分析（Structured Analysis，SA）由美国YOURDON公司提出。采用自顶向下、逐层进行功能分解的系统分析方法来定义系统的需求。适用于分析大型的数据处理系统。方法的特点：利用数据流图（Data Flow Diagram，DFD）来帮助理解问题，对问题进行分析。一般工具：DFD、数据字典、结构化英语、判定表、判定树等。3.3.4 结构化分析方法功能分析工具：DFD、DD、结构化英语、判定表和判定树。行为分析工具：状态迁移图、Petri网等。数据分析工具：ER图或者EER（扩展ER）图。SA主要针对数据处理领域，因此，系统分析的侧重点在于功能分析和数据分析，而行为分析使用得较少。3.3.4 结构化分析方法结构化分析方法的一些弊病：基于功能分析和数据分析，将功能和数据分离，与人类现实世界环境不一样，和人的自然思维也就不一致了。以功能为主，数据只是被动的信息载体。当系统行为发生变化时，系统维护非常困难。DFD中不涉及系统的控制信息，因此，SA不适合于分析以控制信息为主的系统需求。3.3.5 面向对象分析方法面向对象分析不是从功能上进行系统分解，而是从系统的组成上来进行分解。利用类和对象作为基本构造单元，以更接近人类思维的方式建立问题域模型。面向对象思想的一些基本性质：抽象（继承）性、封装（信息隐藏）性、多态性、滞后联编等。3.3.5 面向对象分析方法面向对象分析的一般思路：进行需求获取，建立系统问题域模型（domain model）。从问题域中抽取对象，发现对象之间的各种关系（聚集、概括、关联），建立对象模型。从一些重要的活动场景的描述中发现对象间的协作关系，了解对象的责任。并针对重要的对象建立状态模型。表达静态建模和动态建模的结果。3.3.5 面向对象分析方法面向对象分析方法的种类：WirfsBrock的责任驱动分析方法：CRC（类责任协作）卡进行系统建模。Rumbaugh的OMT（对象建模技术）：建立系统的对象模型、动态模型和功能模型。Booch的Booch-93方法Jacobson的OOSE：强调以Use Case分析系统的实际操作入手，逐步展开系统分析过程。Coad与Yourdon的OOA按照主题、类和对象、结构、属性、服务等5个层次建立问题域模型。3.3.6 需求分析方法的比较结构化分析方法以系统的功能分析为主，而功能是易变的；面向对象分析方法以组成系统的对象分析为主，而对象是比较稳定的。结构化分析方法主要针对数据处理领域，而面向对象分析方法同样适用于以控制为主的系统。面向对象分析具有更好的扩展性，因为对象的结构和关系相对于系统的功能而言更稳定，功能的变化通过更新对象的操作加以适应。3.4 软件体系结构软件体系结构的概念为什么要研究软件体系结构？软件体系结构研究角度基本的软件体系结构风格基于软件体系结构的开发模式 3.4.1 软件体系结构的概念 Dewayne Perry和Alexander Wolf于1992年正式提出软件体系结构的概念：软件体系结构是具有一定形式的结构化元素。结构化元素包括：进程元素、数据元素和连接元素。Mary Shaw和David Garlan于1993年提出：软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。1997年，Bass,Clements和Kazman在使用软件体系结构一书中的定义：一个程序或计算机系统的软件体系结构包括一个或一组软件部件、软件部件的外部可见特性及其相互关系。3.4.1 软件体系结构的概念 对软件体系结构定义的总结分析：软件体系结构定义了软件部件(Component)，包括部件间交互的定义，特别强调省略和部件相互关系无关的内容信息(content information)。软件体系结构并不说明什么是部件、什么是部件的相互关系。每一个软件系统都有自身的体系结构，即由软件部件及其相互关系组成。软件体系结构中每一部件的行为是体系结构的一部分，反映部件间如何进行交互。软件体系结构的基本元素是部件，部件的描述信息包括：（1）计算功能：部件所实现的整体功能；（2）额外功能特性：描述部件的执行效率、处理能力、环境假设和整体特性；（3）结构特性：描述部件如何与其他部件集成在一起，以构成系统信息；（4）家族特性：描述了相同或相关部件之间的关系。3.4.2 为什么要研究软件体系结构？软件体系结构是软件抽象技术发展的结果；抽象数据类型数据结构与算法软件结构研究的开始高级程序设计语言程序族软件体系结构汇编语言、宏替换；高级语言编译器、数据类型。程序数据结构算法（算法抽象）软件划分与构造，方便系统的开发与维护。（模块抽象）数据类型抽象、封装、信息隐藏、多态性等。一个家族的程序，在信息隐藏和软件结构设计上具有相同的模式。（设计模式抽象）软件体系结构可以看作是要把程序族中的成员的结构化信息组织起来，使系统在体系结构级达到重用。（体系结构抽象）3.4.2 为什么要研究软件体系结构？软件体系结构是软件工程技术发展的要求；程序设计阶段早期软件工程阶段手工作坊软件危机1.软件开发无计划性；2.软件需求不充分；3.软件开发过程无规范；4.软件开发产品无评测手段。如何更多、更好、更方便、更快地开发软件？工程化管理软件开发以满足功能需求为主问题定义；需求分析；概要设计；详细设计；编码；测试；维护瀑布模型；演化模型；螺旋模型；喷泉模型；增量模型；原型模型；组装可重用构件模型。？1.为什么专家和新手在使用软件开发模型和软件工程方法时，表现出来的软件效率和效果不一样？专家的经验应用环境问题要求空间问题求解空间如：设计模式 框架注意：经验的抽取与表达独立于具体的功能要求。？2.为什么应用软件开发模型和软件工程方法解决大规模、复杂问题时，软件系统的质量和效率无法得到保证？非功能性需求1.系统性能要求，可用性要求；2.系统可适应性和可移植性要求；3.系统可靠性和安全保密性要求；4.系统可重用性要求等。解决方法：在系统的局部算法结构设计之前，着重进行系统的整体结构设计。软件体系结构设计 软件概要设计的主要任务就是进行系统结构设计，是不是就是软件体系结构设计？概要设计结构化设计面向对象设计注意：以往的概要设计中的功能实体（构件）的设计是首位的，也是显式的，构件间的连接并没有单独作为实体显式地设计，而是作为构件的附属形式出现。而软件体系结构设计将部件、部件连接、连接规范和原则单独作为实体显式定义。3.4.2 为什么要研究软件体系结构？分布式网络环境下软件的适应性和开放性要求；适应性：要求软件从整体上适应不断发生的变化。如：移动营帐系统要求对新业务、新套餐、新费率的适应支持。开放性：要求软件提供良好的接口定义以使外部的接插件能方便地和本系统协同工作。3.4.2 为什么要研究软件体系结构？软件体系结构研究的重要性。软件体系结构是系统开发中不同参与者进行交流和信息传播的媒介。它代表了系统公共的高层次抽象。软件体系结构代表了早期的设计决策成果。早期的决策最难处理、最难于改变、影响范围也最大。软件体系结构可以作为一种可变换的模型。3.4.3 软件体系结构研究角度1.软件角度从不同角度描述软件的体系结构，有利于全面清晰地了解软件的全貌，也能满足不同参与者的需求。目前常用的“4+1”角度模式：支持模块的组织与管理(软件的静态结构)系统的并发与同步等控制结构，支持系统的非功能性需求。描述软件和硬件的映射问题对系统中的重要活动的抽象，使四个角度有机地联系起来。支持软件的功能需求(系统的功能抽象)3.4.3 软件体系结构研究角度2.软件风格(style)角度 描述了对软件设计成分如何进行整理和安排，并且对这些整理和安排加以限制，从而形成一种设计软件的特定模式。描述软件体系结构的四方面属性：词汇表：定义部件和连接类型 系统拓扑限制 语义解释 性能分析 3.4.4 基本的软件体系结构风格出发点：侧重于软件体系结构的结构模型，即观察软件部件、连接件、部件及连接件组合的约束条件。1.管道和过滤器(pipes and filters)2.数据抽象和面向对象组织(data abstraction and OO-organization)3.基于事件的隐式调用(event-based,implicit invocation)4.分层系统(layered systems)5.仓库系统(repositories)：数据库、黑板6.表格驱动的解释器(table driven interpreters)：规则基系统7.其它类型的体系结构：客户/服务器、基于数据共享的主从程序 3.4.5 基于软件体系结构的开发模式提炼特定应用领域的稳定需求和易变需求，建立可复用的领域模型。在特定领域模型的基础上提炼特定应用领域的软件体系结构。进行体系结构设计分配系统功能到相应的构建和连接件上存放设计模式、对象或其它可重用的设计构件。设计构件和连接件复用/存储 3.5 软件设计软件设计的目的软件设计的任务软件设计的过程软件设计的要求结构化设计面向对象设计 3.5.1 软件设计的目的需求分析阶段理解并表达了系统的需求，确定了系统“做什么”。软件设计就是要实现软件需求，解决“如何做”的问题。软件设计应该包括高层设计和低层设计：高层设计指软件体系结构的设计，从整体上满足系统性能要求。低层设计指软件体系结构约束下的部件和连接件的具体设计。3.5.2 软件设计的任务从管理的角度将软件设计划分为：概要设计和详细设计。概要设计：将软件需求转化为数据结构和软件的系统结构。详细设计：对数据结构和系统结构进行细化，得到系统的详细的数据结构和算法。3.5.2 软件设计的任务从技术角度将软件设计划分为数据设计、系统结构设计、过程设计。数据设计：侧重于系统数据结构的设计。系统结构设计：定义软件系统各主要成分之间的关系。过程设计：将系统结构成分变换为软件的过程性描述。3.5.3 软件设计的过程制定设计规范软件体系结构设计软件系统结构的总体设计数据结构设计编写概要设计阶段的文档：概要设计说明书、数据库设计说明书、用户手册、初步的测试计划。概要设计评审确定软件各个组成部分内的算法以及各部分的内部数据组织结构。选定某种过程的表达形式来描述各种算法。进行详细设计的评审。3.5.4 软件设计的要求设计的成果应该做到：满足需求制定的功能规格说明；符合明确或隐含的性能、资源等非功能性需求；符合明确或隐含的设计条件的限制；满足设计过程的限制（如经费、时间及工具等）。3.5.5 结构化设计主要思想：软件系统是由一组功能操作构成的。设计初期：只关注模块之间的组织结构，而是模块为功能“黑盒子”；设计后期：再关注每个模块具体实现的逻辑算法。结构化设计还包含一系列的设计评价方法，如评价模块本身质量的相对效果（内聚度），评价模块间关系的相对效果（耦合度）。3.5.5 结构化设计目标：将软件设计为结构相互独立、功能单一的模块，建立系统的模块结构图。优点：通过划分独立模块来减少程序的设计复杂性，并且增加软件的可重用性，以减少开发和维护计算机程序的费用。适用范围：适合于确定程序中的对象和输入输出数据格式，无助于文件设计、输入输出控制、访问方式选择、运行环境设计等。3.5.5 结构化设计SA和SD的关系：结构化分析的结果结构化设计的结果数据流图系统结构图数据字典模块内部数据结构加工逻辑描述模块内部算法实体关系图数据模型 3.5.5 结构化设计缺点：由于模块间的控制作用只能通过上下之间的调用关系来进行，当系统中模块间的控制作用有重要影响时，会造成信息传递路径过长、效率低、易受干扰，甚至出错。由于数据结构和功能分离，当不同的数据结构的差别细微时，系统往往难以维护。而且限制了软件的可重用性。3.5.6 面向对象设计面向对象设计与面向对象分析没有严格的界限，面向对象设计继承面向对象分析的成果，在分析阶段识别出的与问题有关的类和类间关系的基础上，加上与解决方案有关的类，并对类与类间关系进行优化调整，然后，对类进行编码和测试，得到结果。面向对象设计基本上沿袭了概要设计和详细设计的阶段划分思路。高层设计阶段完成系统体系结构设计，低层设计完成对象设计工作。3.5.6 面向对象设计Rumbaugh的OMT：设计分为系统设计和对象设计阶段。Coad和Yourdon的OOD：仍然按照OOA的5个层次（主题、类和对象、结构、属性、服务）描述增加的用户界面部分、任务管理部分、数据管理部分等的设计，并对原来的问题域部分识别的对象及其关系进行调整。Jacobson的OOSE：构造阶段完成设计工作。3.6 软件测试定义：在软件投入运行之前，对软件需求分析、设计规格说明和编码的最终复审，是SQA的关键步骤。测试阶段与分析、设计阶段间的关系需求分析软件设计程序编码确认测试集成测试单元测试 3.6 软件测试策略：单元测试：模块接口测试；局部数据结构测试；路径测试；错误处理测试；边界测试。集成测试：对相关的系统体系结构的构造进行测试。确认测试：验证软件的功能和性能是否和用户的要求一致。包括：有效性测试；软件配置复查；测试和测试；验收测试。3.6 软件测试测试用例设计方法：黑盒测试：等价类划分；边界值分析；错误推测法；因果图；功能图等。白盒测试：逻辑覆盖；基本路径覆盖等。3.7 软件维护定义：软件投入运行后对软件产品所进行的修改就是维护。种类：改正性维护（corrective maintenance）适应性维护（adaptive maintenance）完善性维护（perfective maintenance）预防性维护（preventive maintenance）