1、11.1 11.1 软件发展与软件发展与软件工程软件工程第1页/共52页软件危机软件危机:软件需求量不断增大，软件开发的软件需求量不断增大，软件开发的复杂度和成本越来越高，软件的开发效率却越复杂度和成本越来越高，软件的开发效率却越来越低，软件的质量越来越难以保证，这种现来越低，软件的质量越来越难以保证，这种现象称为软件危机。象称为软件危机。出现软件危机的原因：出现软件危机的原因：u软件本身所固有的复杂性；软件本身所固有的复杂性；u软件开发方法和软件开发过程不正确。软件开发方法和软件开发过程不正确。第2页/共52页软件工程：采用工程的概念、原理、技术和方软件工程：采用工程的概念、原理、技术和方法
2、，把经过时间考验并行之有效的管理技术和法，把经过时间考验并行之有效的管理技术和成熟的软件开发方法结合起来，以指导计算机成熟的软件开发方法结合起来，以指导计算机软件的开发和维护。软件的开发和维护。软件开发过程：需求分析、软件设计、编码软件开发过程：需求分析、软件设计、编码实现、测试、运行与维护。实现、测试、运行与维护。第3页/共52页(1)(1)第一代软件工程第一代软件工程初步形成了软件工程的基本原理、技术和框架。初步形成了软件工程的基本原理、技术和框架。也称为传统的软件工程。也称为传统的软件工程。软件工程的发展：软件工程的发展：(2)(2)第二代软件工程第二代软件工程面向对象方法成为软件开发主
3、流。也称为对面向对象方法成为软件开发主流。也称为对象工程。象工程。第4页/共52页软件工程的发展：软件工程的发展：(4)(4)第四代软件工程第四代软件工程基于构件的开发方法。也称为构件工程。基于构件的开发方法。也称为构件工程。(3)(3)第三代软件工程第三代软件工程软件过程管理。也称为软件过程工程。软件过程管理。也称为软件过程工程。第5页/共52页11.211.2 软件开发软件开发模型模型第6页/共52页软件开发模型：软件开发过程的各个阶段和任软件开发模型：软件开发过程的各个阶段和任务的总体框架，明确规定了要完成的主要活动务的总体框架，明确规定了要完成的主要活动和任务。和任务。11.2.1 1
4、1.2.1 瀑布模型瀑布模型软件生命周期：从用户需求开始，经过开发、软件生命周期：从用户需求开始，经过开发、交付使用，在使用过程中不断增补修订，直交付使用，在使用过程中不断增补修订，直至软件报废的全过程。即软件从提出开发开至软件报废的全过程。即软件从提出开发开始到最终灭亡所经历的时期始到最终灭亡所经历的时期第7页/共52页 将软件开发过程模仿成阶梯瀑布。将软件开发过程模仿成阶梯瀑布。软件生存周期由立项、需求分析、策划、概要设计、详细设计、编程、测试、发布、软件生存周期由立项、需求分析、策划、概要设计、详细设计、编程、测试、发布、维护、退役等阶段所组成，把每个阶段当作瀑布中的一个台阶。维护、退役
5、等阶段所组成，把每个阶段当作瀑布中的一个台阶。开发人员按照阶段开发，管理人员按照阶段管理。开发人员按照阶段开发，管理人员按照阶段管理。11.2.1 11.2.1 瀑布模型瀑布模型第8页/共52页开发开发时期时期运行运行时期时期计划计划时期时期(目标与范围说明书目标与范围说明书)(可行性论证论告可行性论证论告)(维护报告维护报告)(测试报告测试报告)(程序程序)(设计文档设计文档)(需求说明书需求说明书)第9页/共52页问题定义问题定义可行性研究可行性研究需求分析需求分析设计设计编码编码测试测试运行与维护运行与维护带反馈的瀑布模型第10页/共52页 以某个软件原型为参照模型的开发方法，叫原型法。
6、以某个软件原型为参照模型的开发方法，叫原型法。在初步需求分析之后，马上向客户展示一个软件产品原型，让客户试用，在试用中在初步需求分析之后，马上向客户展示一个软件产品原型，让客户试用，在试用中收集客户意见，修改原型，再让客户试用，反复循环，直到客户确认为止。收集客户意见，修改原型，再让客户试用，反复循环，直到客户确认为止。特点：原型驱动。因此，开发者必须先有一个原型，至少要有一个原型的核心。特点：原型驱动。因此，开发者必须先有一个原型，至少要有一个原型的核心。11.2.2 11.2.2 原型模型原型模型第11页/共52页部署交付和反馈部署交付和反馈构建原型构建原型交流交流快速设计方式建模快速设计
7、方式建模快速计划快速计划原型模型原型模型第12页/共52页原型模型的形式：原型模型的形式：(1)(1)废弃型。原型的用途是获取用户的真正需求。废弃型。原型的用途是获取用户的真正需求。当用户对原型认可以后，原型即被废弃，后续的工当用户对原型认可以后，原型即被废弃，后续的工作仍然按照瀑布模型开发。作仍然按照瀑布模型开发。(2)(2)渐进型。原型作为最终产品的一部分，能够满渐进型。原型作为最终产品的一部分，能够满足用户的部分需求。用户使用后，提出对系统的进足用户的部分需求。用户使用后，提出对系统的进一步精化要求。开发者根据反馈，进行迭代开发，一步精化要求。开发者根据反馈，进行迭代开发，将系统需要具备
8、的功能逐步添加上去。如此反复，将系统需要具备的功能逐步添加上去。如此反复，直到用户需求全部满足为止。此时的原型就是最终直到用户需求全部满足为止。此时的原型就是最终的软件产品。的软件产品。11.2.2 11.2.2 原型模型原型模型第13页/共52页 增量模型将软件产品看作一组增量构件，每次设计、实现、集成、测试和交付一块增量模型将软件产品看作一组增量构件，每次设计、实现、集成、测试和交付一块构件，直到所有构件全部实现为止。构件，直到所有构件全部实现为止。要开发一个大的软件系统，先开发其中的一个核心模块，后再开发其他模块，这样要开发一个大的软件系统，先开发其中的一个核心模块，后再开发其他模块，这
9、样一个个模块地增加上去，直至整个系统开发完毕为止。一个个模块地增加上去，直至整个系统开发完毕为止。优点：(1)(1)将软件划分成多个小模块，可以降低开发风险，以及开发难度；将软件划分成多个小模块，可以降低开发风险，以及开发难度；(2)(2)可以分阶段提交产品。可以分阶段提交产品。11.2.3 11.2.3 增量模型增量模型第14页/共52页增量模型增量模型项目日历时间项目日历时间软软件件功功能能性性和和特特征征1 12 23 34 45 5第第2 2次增量发布次增量发布增量增量2 21 12 23 34 45 5第第n n次增量发布次增量发布增量增量n n1 12 23 34 45 5第第1
10、1次增量发布次增量发布增量增量1 15 5部署（发布，反馈）部署（发布，反馈）4 4构造（编码，测试）构造（编码，测试）3 3建模（分析，设计）建模（分析，设计）2 2计划计划1 1交流交流第15页/共52页瀑布模型和增量模型结合，并增加风险分析瀑布模型和增量模型结合，并增加风险分析螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动：螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动：制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件 风险分析：评价所选的方案，识别风险，消除风险风险分析：评价所选的方案，识别风险
11、，消除风险 工程实施：实施软件开发，验证工作产品工程实施：实施软件开发，验证工作产品 客户评估：评价开发工作，提出修正建议客户评估：评价开发工作，提出修正建议11.2.4 11.2.4 螺旋模型螺旋模型第16页/共52页 第17页/共52页11.3 11.3 软件开发软件开发过程过程第18页/共52页需求分析、设计、实现、测试、运行及维护需求分析、设计、实现、测试、运行及维护11.3.1 11.3.1 需求分析需求分析需求分析的主要任务是确定待开发系统的功能、性需求分析的主要任务是确定待开发系统的功能、性能需求和运行环境约束，编写软件需求规格说明书，能需求和运行环境约束，编写软件需求规格说明书
12、，即需求分析是要明确系统是即需求分析是要明确系统是“做什么做什么”的。的。软件功能需求软件功能需求:对软件系统应提供的服务、功能，以对软件系统应提供的服务、功能，以及系统在特定条件下的行为的描述。及系统在特定条件下的行为的描述。软件的性能需求软件的性能需求:对软件系统的可用性、可靠性、可对软件系统的可用性、可靠性、可移植性、效率和存储等方面的需求。移植性、效率和存储等方面的需求。第19页/共52页结构化分析方法采用自顶向下逐层分解、由粗到细、结构化分析方法采用自顶向下逐层分解、由粗到细、由复杂到简单的求解方法。由复杂到简单的求解方法。1.1.结构化分析方法结构化分析方法分解分解:将大问题分解成
13、若干小问题，然后分别解决将大问题分解成若干小问题，然后分别解决抽象抽象:抓住问题的主要方面而忽略问题的次要方面，抓住问题的主要方面而忽略问题的次要方面，集中精力解决问题的主要方面。集中精力解决问题的主要方面。第20页/共52页分层数据流图由顶层、中间层和底层组成。分层数据流图由顶层、中间层和底层组成。顶层抽象地描述了整个系统，底层具体给出系统的细顶层抽象地描述了整个系统，底层具体给出系统的细节部分，中间层完成从抽象到具体的逐步过渡。节部分，中间层完成从抽象到具体的逐步过渡。通过分解，将一个复杂的系统分解成许多简单的基本通过分解，将一个复杂的系统分解成许多简单的基本加工，当数据流过系统时，被系统
14、进行加工变换。加工，当数据流过系统时，被系统进行加工变换。结构化分析方法以分层数据流图，加上数据字典和加工说明结构化分析方法以分层数据流图，加上数据字典和加工说明来构建分析模型。来构建分析模型。(数据流)：表示数据的流动方向。(加工)：表示对数据流进行操作或处理(数据存储)：暂存的数据。(外部实体)：数据流的起点和终点，系统外的实体。第21页/共52页当客户发出订单时，系统根据图书目录对订单进行验当客户发出订单时，系统根据图书目录对订单进行验证。验证通过的订单，被保存在订单文件中。系统每证。验证通过的订单，被保存在订单文件中。系统每天要对订单进行分类汇总，并保存订单存根，然后将天要对订单进行分
15、类汇总，并保存订单存根，然后将汇总订单发往出版社。请为系统画出顶层数据流图。汇总订单发往出版社。请为系统画出顶层数据流图。【例【例11.111.1】图书预定系统的数据流图图书预定系统的数据流图第22页/共52页面向对象分析对问题域和系统责任进行分析和理解，面向对象分析对问题域和系统责任进行分析和理解，找出描述它们的类和对象，以及类之间的关系，最终找出描述它们的类和对象，以及类之间的关系，最终获得一个符合用户需求，并能够反映问题域和系统责获得一个符合用户需求，并能够反映问题域和系统责任的面向对象分析模型。任的面向对象分析模型。2.2.面向对象的分析方法面向对象的分析方法面向对象分析的基本步骤：面
16、向对象分析的基本步骤：(1)(1)获取用户需求。采用用例图获取用户需求。获取用户需求。采用用例图获取用户需求。(2)(2)标识类和对象。标识类和对象。(3)(3)定义类的结构和层次。定义类的结构和层次。(4)(4)建立对象之间的关系。建立对象之间的关系。第23页/共52页自动售货机为顾客提供自动售货机为顾客提供2424小时服务，顾客通过自动售货机可小时服务，顾客通过自动售货机可以买到灌装饮料。每隔一段时间供货人员补充一部分货物，以买到灌装饮料。每隔一段时间供货人员补充一部分货物，收银员也会定期将售货款取走。请画出自动售货机的用例图收银员也会定期将售货款取走。请画出自动售货机的用例图【例【例11
17、.211.2】自动售货机的用例图】自动售货机的用例图第24页/共52页主要任务：将需求需求转换为计算机中可实现的系统，主要任务：将需求需求转换为计算机中可实现的系统，完成系统的体系结构设计，以及系统内部结构设计，完成系统的体系结构设计，以及系统内部结构设计，最终产生软件设计说明书。即解决怎么做的问题最终产生软件设计说明书。即解决怎么做的问题11.3.2 11.3.2 设计设计概要设计主要完成软件系统的总体结构设计、确定概要设计主要完成软件系统的总体结构设计、确定各模块间的关系、全局数据库或数据结构设计、定各模块间的关系、全局数据库或数据结构设计、定义各个功能模块的接口，最终产生概要设计说明书义
18、各个功能模块的接口，最终产生概要设计说明书详细设计主要完成各子系统的公用模块设计、专用模详细设计主要完成各子系统的公用模块设计、专用模块设计，以及模块内部结构设计，最终产生详细设计块设计，以及模块内部结构设计，最终产生详细设计说明书。说明书。第25页/共52页结构化设计的基本思想是将软件系统设计成由若干个结构化设计的基本思想是将软件系统设计成由若干个相对独立、功能单一的模块组成的系统。相对独立、功能单一的模块组成的系统。1.1.结构化设计结构化设计概要设计的任务是确定软件系统的结构，进行子系概要设计的任务是确定软件系统的结构，进行子系统划分，确定子系统的模块结构，以及每个模块的统划分，确定子系
19、统的模块结构，以及每个模块的功能。功能。详细设计对概要设计产生的功能模块进行细化，确定详细设计对概要设计产生的功能模块进行细化，确定每个模块的内部细节，包括局部数据组织、控制流、每个模块的内部细节，包括局部数据组织、控制流、每一步的具体加工要求等。每一步的具体加工要求等。第26页/共52页面向对象方法的分析与设计之间并没有明显的界限，面向对象方法的分析与设计之间并没有明显的界限，它们之间所采用的概念、原理和方法是一致的。它们之间所采用的概念、原理和方法是一致的。2.2.面向对象设计面向对象设计分析与设计的侧重点有所不同，面向对象分析侧重分析与设计的侧重点有所不同，面向对象分析侧重于问题域和系统
20、责任，不考虑实现；面向对象设计于问题域和系统责任，不考虑实现；面向对象设计侧重于与实现有关的因素，对分析模型进行细化，侧重于与实现有关的因素，对分析模型进行细化，并添加与实现有关的部分。并添加与实现有关的部分。面向对象设计模型主要包括问题域子系统、人机交互面向对象设计模型主要包括问题域子系统、人机交互子系统、任务管理子系统和数据管理子系统。子系统、任务管理子系统和数据管理子系统。第27页/共52页【例【例11.311.3】图书预定系统的类图】图书预定系统的类图第28页/共52页使用人工和自动手段来运行或测试某个系统的过程，使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规
21、定的需求或弄清预期结其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。果与实际结果之间的差别。11.3.3 11.3.3 测试测试软件测试步骤软件测试步骤:第29页/共52页完成每个单元的测试任务，检查每个模块是否完成指完成每个单元的测试任务，检查每个模块是否完成指定的功能，发现模块是否存在编码或算法错误。定的功能，发现模块是否存在编码或算法错误。1.1.单元测试单元测试2.2.集成测试集成测试集成测试是在单元测试的基础上，将所有模块按照设集成测试是在单元测试的基础上，将所有模块按照设计要求组装在一起，形成一个完整的系统，针对该系计要求组装在一起，形成一个完整的系统，针对该
22、系统所进行的测试。主要检查软件体系结构问题。统所进行的测试。主要检查软件体系结构问题。第30页/共52页确认测试用于检查软件的功能与性能是否符合需求规确认测试用于检查软件的功能与性能是否符合需求规格说明书的要求。格说明书的要求。3.3.确认测试确认测试4.4.系统测试系统测试系统测试是指把已确定的软件与系统其它部分系统测试是指把已确定的软件与系统其它部分(如硬如硬件、其它支持软件、数据等件、其它支持软件、数据等)集成在一起所进行的测集成在一起所进行的测试。试。第31页/共52页白盒测试主要检查程序白盒测试主要检查程序(模块模块)内部逻辑结构，对逻辑内部逻辑结构，对逻辑路径、内部控制结构和数据结
23、构进行测试。路径、内部控制结构和数据结构进行测试。5.5.白盒测试白盒测试白盒测试方法主要有语句覆盖、判定覆盖、条件覆白盒测试方法主要有语句覆盖、判定覆盖、条件覆盖、判定盖、判定/条件覆盖和条件组合覆盖。条件覆盖和条件组合覆盖。(1)(1)语句覆盖语句覆盖使程序中的每个语句至少执行一次。使程序中的每个语句至少执行一次。第32页/共52页if(a1)&(b=0)if(a1)&(b=0)x=x+5;x=x+5;if(a=2)|(x1)if(a=2)|(x1)y=x/3;y=x/3;请使用语句覆盖法进行白盒测试。请使用语句覆盖法进行白盒测试。【例【例11.411.4】已知程序段】已知程序段测试用例：
24、测试用例：a=2a=2，b=0b=0，x=5x=5。第33页/共52页使被测程序每个判定至少取一次使被测程序每个判定至少取一次“真真”值和一次值和一次“假假”值。值。(2)(2)判定覆盖判定覆盖【例例11.511.5】对例对例11.411.4的程序段执行判定覆盖的程序段执行判定覆盖测试用例测试用例1 1：a=2a=2，b=0b=0，x=5x=5；测试用例测试用例2 2：a=1a=1，b=0b=0，x=1x=1。第34页/共52页使被测程序每个判定中的每个条件都至少取值一次。使被测程序每个判定中的每个条件都至少取值一次。(3)(3)条件覆盖条件覆盖【例例11.611.6】对例对例11.411.4
25、的程序段执行条件覆盖的程序段执行条件覆盖测试用例测试用例1 1：a=2a=2，b=0b=0，x=5x=5；测试用例测试用例2 2：a=1a=1，b=1b=1，x=1x=1。第35页/共52页使被测程序的判定中每个条件的所有可能至少出现一使被测程序的判定中每个条件的所有可能至少出现一次，且每个判定本身的判定结果也至少出现一次。次，且每个判定本身的判定结果也至少出现一次。(4)(4)判定判定/条件覆盖条件覆盖【例例11.711.7】对例对例11.411.4中的程序段执行判定中的程序段执行判定/条条件覆盖件覆盖测试用例测试用例1 1：a=2a=2，b=0b=0，x=5x=5；测试用例测试用例2 2：
26、a=1a=1，b=1b=1，x=1x=1。第36页/共52页使被测程序每个判定中的条件的各种可能组合都至少使被测程序每个判定中的条件的各种可能组合都至少出现一次。出现一次。(5)(5)条件组合覆盖条件组合覆盖【例例11.811.8】对例对例11.411.4中的程序段执行条件组中的程序段执行条件组合覆盖合覆盖测试用例测试用例1 1：a=2a=2，b=0b=0，x=5x=5；测试用例测试用例2 2：a=2a=2，b=1b=1，x=1x=1。测试用例测试用例3 3：a=1a=1，b=1b=1，x=1x=1；测试用例测试用例4 4：a=1a=1，b=0b=0，x=5x=5。第37页/共52页黑盒测试不
27、考虑程序内部的逻辑结构和处理过程，依黑盒测试不考虑程序内部的逻辑结构和处理过程，依据需求规格说明书，测试程序是否满足功能要求。据需求规格说明书，测试程序是否满足功能要求。6.6.黑盒测试黑盒测试黑盒测试方法主要有等价分类法、边界值分析法、黑盒测试方法主要有等价分类法、边界值分析法、错误推测法和因果图法。错误推测法和因果图法。第38页/共52页软件维护是指软件系统交付使用后，为了纠正软件运软件维护是指软件系统交付使用后，为了纠正软件运行中的错误或者满足用户对软件提出的新要求而修改行中的错误或者满足用户对软件提出的新要求而修改软件的过程。软件的过程。11.3.4 11.3.4 维护维护软件维护分为
28、：纠错性维护、完善性维护、软件维护分为：纠错性维护、完善性维护、适应性维护、预防性维护适应性维护、预防性维护第39页/共52页11.4 UML11.4 UML简介简介第40页/共52页UMLUML（Unified Modeling LanguageUnified Modeling Language）统一建模语言。）统一建模语言。是一种国际标准，是一种通用建模语言，具有创建系是一种国际标准，是一种通用建模语言，具有创建系统的静态结构和动态行为等多种结构模型的能力统的静态结构和动态行为等多种结构模型的能力11.4.1 UML11.4.1 UML的构成的构成UMLUML建模语言的描述方式以标准的图形
29、表示为主，建模语言的描述方式以标准的图形表示为主，由视图、图、模型元素和通用机制构成的层次关系由视图、图、模型元素和通用机制构成的层次关系第41页/共52页用例图从用户角度描述系统功能，并指出各功用例图从用户角度描述系统功能，并指出各功能的操作者。能的操作者。11.4.2 11.4.2 用例图用例图 个 人 登 记 团 体 登 记 旅 客 导 游 旅 游 系 统 行 李 处 理 第42页/共52页【例【例11.1111.11】在项目管理系统中，删除项目】在项目管理系统中，删除项目用例与查找项目用例之间的关系用例与查找项目用例之间的关系第43页/共52页【例【例11.1211.12】改变购书数量
30、与检查信用间的关系】改变购书数量与检查信用间的关系用户在网上订购图书时，系统需要对用户的信用进行检查，用户在网上订购图书时，系统需要对用户的信用进行检查，检查输入的信用卡号是否正确，信用卡是否有足够的资金支检查输入的信用卡号是否正确，信用卡是否有足够的资金支付本次订购。当用户需要改变购书数量时，系统要检查是否付本次订购。当用户需要改变购书数量时，系统要检查是否真正改变了购书数量，如果确实改变了购书数量，则需要对真正改变了购书数量，如果确实改变了购书数量，则需要对用户的信用进行检查；如果购书数量不变，则不需要检查信用户的信用进行检查；如果购书数量不变，则不需要检查信用。请根据需求画出用例图。用。
31、请根据需求画出用例图。检查信用订购用户改变购书数量第44页/共52页11.4.3 11.4.3 类图类图第45页/共52页(1)(1)关联关系关联关系2.2.类之间的关系类之间的关系关联关系表示类之间具有某种语义联系。关联关系表示类之间具有某种语义联系。第46页/共52页聚集关系表示类之间的整体与部分关系。聚集关系表示类之间的整体与部分关系。(2)(2)聚集和组合关系聚集和组合关系组合关系是聚合关系中的一种特殊情况，是更强形组合关系是聚合关系中的一种特殊情况，是更强形式的聚合，其部分对象与整体对象共存亡。式的聚合，其部分对象与整体对象共存亡。第47页/共52页泛化关系是类之间的一般与特殊关系泛
32、化关系是类之间的一般与特殊关系(3)(3)泛化关系泛化关系第48页/共52页顺序图描述了对象之间动态的交互关系，着重体现对顺序图描述了对象之间动态的交互关系，着重体现对象之间传送消息的时间顺序。象之间传送消息的时间顺序。11.4.4 11.4.4 顺序图顺序图第49页/共52页状态图主要用于描述一个对象在其生存期间的动态行状态图主要用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移为，表现一个对象所经历的状态序列，引起状态转移的事件，以及因状态转移而伴随的动作。的事件，以及因状态转移而伴随的动作。11.4.5 11.4.5 状态图状态图 在 一 楼 向 上 升 向 下 降 空 闲 向 一 楼 移 动 去 指 定 楼 层 到 达 指 定 楼 层 到 达 指 定 楼 层 去 指 定 楼 层 去 指 定 楼 层 到 达 一 楼 超 时 第50页/共52页活动图用于系统动态行为建模，它可以描述系统的工活动图用于系统动态行为建模，它可以描述系统的工作流程或者完成一个任务所需要的活动。作流程或者完成一个任务所需要的活动。11.4.6 11.4.6 活动图活动图第51页/共52页谢谢您的观看！第52页/共52页
