软件工程概念

1第1页，共65页，2023年，2月20日，星期二提示：设计与建模要点结构化分析建模：数据流图、实体关系图、状态迁移图、数据字典结构化设计建模：数据流图转换为系统结构图结构化程序设计：程序流程图、N-S图、PAD程序环路复杂性计算测试用例设计：逻辑覆盖、循环测试、基本路径覆盖、因果图可靠性分析：估算测试前程序中潜在错误OMT建模：对象模型、动态模型（状态图、事件追踪图）UML建模：用例图、类图、顺序图、活动图第2页，共65页，2023年，2月20日，星期二第一章软件工程概念1.1软件的定义与分类1.2软件的发展1.3软件工程定义1.4软件工程过程与软件生存周期模型1.5软件开发范型1.6软件工程原理和原则第3页，共65页，2023年，2月20日，星期二1.1软件的定义与分类软件的定义：软件由计算机程序、数据及文档组成。程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构文档是与程序开发，维护和使用有关的图文材料软件与硬件、数据库、人、过程等共同构成计算机系统。第4页，共65页，2023年，2月20日，星期二软件的特点软件是一种逻辑实体，而不是具体的物理实体。因而它具有抽象性软件的生产与硬件不同，在它的开发过程中没有明显的制造过程在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题软件的开发和运行常受到计算机系统的限制，对计算机系统有着不同程度的依赖性第5页，共65页，2023年，2月20日，星期二软件的开发至今尚未完全摆脱手工艺的开发方式软件本身是复杂的实际问题的复杂性程序逻辑结构的复杂性软件成本相当昂贵相当多的软件工作涉及到社会因素第6页，共65页，2023年，2月20日，星期二软件的分类按软件的功能进行划分：系统软件

操作系统数据库管理系统设备驱动程序通信处理程序等支撑软件文本编辑程序文件格式化程序第7页，共65页，2023年，2月20日，星期二程序库系统支持需求分析、设计、实现、测试和支持管理的软件应用软件

商业数据处理软件工程与科学计算软件计算机辅助设计／制造软件智能产品嵌入软件事务管理、办公自动化软件计算机辅助教学软件第8页，共65页，2023年，2月20日，星期二按软件规模进行划分：类别参加人员数研制期限源程序行数

微型 1 1～4周0.5k

小型1 1～6月1k～2k

中型2～5 1～2年5k～50k

大型5～20 2～3年50k～100k

甚大型100～10004～5年1M(=1000k)

极大型2000～50005～10年1M～10M

第9页，共65页，2023年，2月20日，星期二按软件工作方式划分：实时处理软件分时软件交互式软件批处理软件按软件服务对象的范围划分：项目软件产品软件第10页，共65页，2023年，2月20日，星期二按使用的频度进行划分：一次使用频繁使用按软件失效的影响进行划分：高可靠性软件一般可靠性软件第11页，共65页，2023年，2月20日，星期二1.2软件发展阶段程序设计阶段—1950至60年代 计算机软件发展的初期，其主要特征是程序生产方式为个体手工方式。主要采用批处理技术，没有任何其它形式的文档资料保留下来，开发出的程序根本无法维护。程序系统阶段—60至70年代 程序的规模已经很大，需要多人分工协作，软件的开发方式由“个体生产”发展到了“软件作坊”。第12页，共65页，2023年，2月20日，星期二 “软件作坊”基本上沿用了软件发展早期所形成的个体化的开发方式，软件的开发与维护费用以惊人的速度增加。许多软件产品根本不能维护，最终导致出现了严重的“软件危机”。软件工程阶段—70年代以后

软件的开发以工程化的思想为指导，用工程化的原则、方法和标准来开发和维护软件。 软件工程概念的出现源自软件危机。 软件危机的主要特征软件价格在整个项目投入中的比例不断升高;

第13页，共65页，2023年，2月20日，星期二软件开发成本严重超标;软件开发周期大大超过规定日期;软件质量难于保证；

软件修改、维护困难；

失败的根本原因在于：开发人员写出的东西达不到用户要求(人的问题、技术问题)为了解决软件危机，人们借鉴其他领域的经验和知识，从而认识到“摆脱软件危机的出路在于软件开发的标准化和工程化”，出现了“软件工程”的概念。第14页，共65页，2023年，2月20日，星期二1968年德国人Bauer在北大西洋公约组织会议上的定义："建立并使用完善的工程化原则,以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法"。1983年IEEE的软件工程定义："软件工程是开发，运行,维护和修复软件的系统方法"。1993年IEEE的一个更加综合的定义："将系统化的，规范的，可度量的方法应用于软件的开发,运行和维护的过程，即将工程化应用于软件中"。1.3软件工程定义第15页，共65页，2023年，2月20日，星期二软件工程框架可用性性性确正合算选取适宜的开发模型采用合适的设计方法提供高质量的工程支持重视软件工程的管理基本过程支持过程组织过程目标过程原则第16页，共65页，2023年，2月20日，星期二软件工程框架给出了软件工程三个主要方面。软件工程目标—包括可用性、正确性和合算性，规定了软件工程实践的结果（即软件）应具有的基本性质；软件工程过程—包含的基本活动有需求、分析与设计、实现、确认与测试、维护与支持；软件工程的四条原则--采用适宜的开发模型，使用恰当的开发方法，提供高质量的工程支持，实施有效的工程管理，从四个方面指导每一项工程的活动，以实现软件工程目标。第17页，共65页，2023年，2月20日，星期二软件工程的知识结构2001年5月ISO/IECJTC1发布了《SWEBOK指南V0.95（试用版）》，即GuidetotheSoftwareEngineeringBodyofKnowledge。SWEBOK把软件工程学科的主体知识分为10个知识领域。这10个领域包括：软件需求

软件设计软件构造

软件测试软件维护

软件配置管理软件工程管理

软件工程过程软件工程工具和方法

软件质量第18页，共65页，2023年，2月20日，星期二ISO9000定义：软件工程过程是把输入转化为输出的一组彼此相关的资源和活动。从软件开发的观点看，它就是使用适当的资源（包括人员、硬软件工具、时间等），为开发软件进行的一组开发活动，在过程结束时将输入（用户要求）转化为输出（软件产品）。1.4软件工程过程与软件生存周期第19页，共65页，2023年，2月20日，星期二软件工程过程定义了:方法使用的顺序、要求交付的文档资料、为保证质量和适应变化所需要的管理、软件开发各个阶段完成的里程碑。软件工程过程包含四种基本的过程活动：

plan:软件规格说明

do:软件开发

check:软件确认

action:软件演进第20页，共65页，2023年，2月20日，星期二软件生存周期包含三个阶段：软件定义、软件开发及软件运行维护。软件生存周期模型是软件工程思想的具体化，是跨越软件生存周期的系统开发、运行、维护所实施的全部活动和任务的过程框架。常用的软件生存周期模型有瀑布模型，演化模型，螺旋模型，增量模型，喷泉模型，快速应用开发（RAD）模型。第21页，共65页，2023年，2月20日，星期二瀑布模型各项活动按自上而下，相互衔接的固定次序，如同瀑布逐级下落，每项活动均处于一个质量环（输入-处理-输出-评审）中。阶段间具有顺序性和依赖性。推迟实现的观点。每个阶段必须完成规定的文档；每个阶段结束前完成文档审查。第22页，共65页，2023年，2月20日，星期二需求定义系统与软件设计集成与系统测试实现与单元测试运行与维护第23页，共65页，2023年，2月20日，星期二演化模型演化模型是迭代的，软件必须经过不断演化才能完善。演化模型先开发一个“原型”软件，完成部分主要功能，展示给用户并征求意见，然后逐步完善，最终获得满意的软件产品。业务和产品需求在变化中，采用线性开发方式是不实际的。快速实现和提交一个有限的版本，可以应付市场竞争的压力。第24页，共65页，2023年，2月20日，星期二需求的采集与细化客户评价原型快速设计建造原型加工原型产生样品停止开始第25页，共65页，2023年，2月20日，星期二螺旋模型螺旋模型将瀑布模型与演化模型结合起来，并且加入两种模型均忽略了的风险分析。螺旋模型沿着螺线旋转，自内向外每旋转一圈便开发出更完善的一个新版本。制定计划风险分析实施工程客户评估第26页，共65页，2023年，2月20日，星期二决定目标、方案和限制评价方案识别风险弱化风险

开发、验证、下一级产品

计划下一阶段集成测试第27页，共65页，2023年，2月20日，星期二增量模型增量模型是迭代和演进的过程。增量模型把软件产品分解成一系列的增量构件，在增量开发迭代中逐步加入。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。早先完成的增量可以为后期的增量提供服务。增量开发方法的新演进版本叫做"极限程序设计（eXtremeProgramming）"。第28页，共65页，2023年，2月20日，星期二定义基本需求将需求对应到各增量设计系统架构开发其中一个增量检验和确认该增量将增量集成到系统中确认集成后的系统第29页，共65页，2023年，2月20日，星期二日历时间分析增量1

增量1交付设计编码测试分析增量2增量2交付设计编码测试分析增量3增量3交付设计编码测试分析增量4增量4交付设计编码测试系统和信息工程第30页，共65页，2023年，2月20日，星期二喷泉模型体现了迭代和无间隙的特性。系统某个部分常常重复工作多次，相关对象在每次迭代中随之加入演进的软件成分。无间隙是指在各项开发活动，即分析、设计和编码之间不存在明显的边界。喷泉模型是对象驱动的过程。第31页，共65页，2023年，2月20日，星期二需求阶段分析阶段设计阶段编程阶段集成与测试阶段维护与演进阶段第32页，共65页，2023年，2月20日，星期二变换模型变换模型是一种基于形式化规格说明语言及程序变换的软件开发模型。它采用形式化的软件开发方法，对形式化的软件规格说明进行一系列自动的或半自动的程序变换，最终映射成为计算机系统能够接受的程序系统。多步程序变换过程的重要性质是：每一步程序变换的正确性仅与该步变换所依据的规范Mi以及对变换后的假设Mi+1有关。第33页，共65页，2023年，2月20日，星期二软件需求形式化说明(M0)软件设计形式化说明(M1)(M2)(Mn)……模型检查程序变换程序变换程序变换在此意义上，变换步骤独立于其他变换步骤。这称为变换的独立性。该模型只适合于软件的形式化开发方法；需要严格的数学理论和形式化技术支持；需要一整套开发环境（如程序变换工具、定理证明工具等）的支持。第34页，共65页，2023年，2月20日，星期二基于第四代技术的模型第四代语言(4GL)是在大型数据库管理系统的基础上发展起来的，是一种面向结果的非过程性语言。它独立于具体的处理机，有丰富的软件工具支持，能统一利用和管理各种数据资源并能适应不同水平用户的需要。以4GL为核心的软件开发技术成为第四代技术(4GT)，采用4GT的软件开发模型如图。软件开发人员在定义软件需求，给出需求规格说明之后，4GT工具可将该需求规格说明自动第35页，共65页，2023年，2月20日，星期二 转换为程序代码。这大大减少了分析、设计、编码和测试的时间。以4GL为核心的软件开发技术成为第四代技术(4GT)，采用4GT的软件开发模型如图。收集需求“设计”策略用“4GL”实现测试第36页，共65页，2023年，2月20日，星期二快速应用开发（RAD）模型快速应用开发模型是一种增量开发模型，该模型开发软件大量使用了可复用的构件。每一个增量的开发经历五个阶段：业务建模对业务功能的信息流建模。数据建模对业务的数据对象和关系建模。过程建模描述完成业务功能的数据变换。应用生成应用构件和自动化工具建造。测试与反复对新构件和接口进行测试。第37页，共65页，2023年，2月20日，星期二业务建模数据建模过程建模应用生成测试及反复小组1#业务建模数据建模过程建模应用生成测试及反复小组2#业务建模数据建模过程建模应用生成测试及反复小组3#60~90天第38页，共65页，2023年，2月20日，星期二Rational统一开发过程最佳软件开发实践

为了以一种更好的、迭代的、可预测的方式开发软件产品，总结了软件开发的最佳实践：迭代式软件开发；需求管理；基于构件的软件体系结构；建立软件可视化模型；不断验证软件质量；控制变更。第39页，共65页，2023年，2月20日，星期二Rational统一开发过程

软件开发过程的作用是：成为开发组活动顺序的向导。详细说明需要开发哪些制品，何时开发。指导每一个成员及整个开发组的工作。提供监控和度量项目产品和活动所依据的准则。如果没有一个良好定义的过程，开发组将各行其是，开发成功与否完全依赖个别优秀的人才，这不是能够长久的。第40页，共65页，2023年，2月20日，星期二Rational统一开发过程（RUP,RationalUnifyProcess）描述了如何在软件开发组织中严格分配任务和职责的方法。RUP是一个过程产品，"软件过程也是软件。"RUP采用二维的过程结构：横轴表明过程的生存周期，它反映了过程被激活时的动态情况，用周期、阶段、迭代和里程碑表示。纵轴表明过程的静态状况，通过过程构件、活动、工作流、制品和工作人员描述过程。第41页，共65页，2023年，2月20日，星期二初始细化构造移交阶段初始化细化#1细化#2构造#1构造#2构造#3移交#1移交#2迭代工作流业务建模需求

分析与设计实现测试实施配置和变更管理项目管理环境沿时间轴的组织结构沿内容轴的组织第42页，共65页，2023年，2月20日，星期二过程的静态描述：过程模型过程模型中的主要模型元素有4种：工作人员：谁做（Who）活动：怎么做（How）制品：做什么（what）工作流：何时做（when）过程的中心概念是工作人员，工作人员不是指某一个人，而是指完成工作的角色。工作人员定义人们应履行的行为和职责。第43页，共65页，2023年，2月20日，星期二活动定义了工作人员所执行的工作。有3类步骤：思考步骤执行步骤评审步骤制品是过程生产、修改或使用的一些信息。RUP的制品分为5个信息集。管理集：计划制品、操作制品需求集：构想文档、项目相关人员需求、用例模型和业务模型第44页，共65页，2023年，2月20日，星期二设计集：设计模型、软件体系结构描述、测试模型实现集：源代码和可执行程序、相关数据结构和数据文档实施集：安装资料、用户文档、培训材料工作流用来描述生成结果的活动序列，用以描述工作人员之间的交互。在RUP中共有9个核心过程工作流，包括6个核心工程工作流和3个核心支持工作流。第45页，共65页，2023年，2月20日，星期二业务建模工作流：描述业务过程的本质和执行情形。需求工作流：定义系统构想，使用用例模型和补充规格说明定义系统软件需求，管理系统范围和需求变更。分析和设计工作流：研究实现环境和系统构件的效用，定义软件的组织结构，把需求获取结果转化为实现规格。实现工作流:建立代码的分层结构，实现类和对象，进行单元测试和系统集成。第46页，共65页，2023年，2月20日，星期二测试工作流：根据事先定义的度量和准则检查产品，确认产品是否满足或者超出事先定义并被一致接受的需求。实施工作流：在实际使用环境中测试软件、包装要交付的软件、发布软件产品、培训最终用户及销售人员。核心支持工作流有项目管理工作流配置和变更管理工作流环境工作流第47页，共65页，2023年，2月20日，星期二过程的动态描述：迭代开发将一个大项目分解为可连续应用瀑布模型的几个小部分。在对一部分进行分析、设计、实现并确认后，再对下一部分进行分析、设计、实现和确认。以此进行下去，直到整个项目完成。在RUP中，迭代过程分为几个阶段。初始细化构造移交生存周期构架里程碑生存周期目标里程碑最初运行能力里程碑产品发布里程碑时间第48页，共65页，2023年，2月20日，星期二初始阶段：确定最终产品的构想及其用例，定义项目范围。细化阶段：计划需完成活动和资源，详细说明产品特性并设计软件体系结构。构造阶段：构造整个产品，逐步完善软件体系结构和计划，直到产品（完整的构想）已完全准备好交付给用户。移交阶段：移交产品给用户，包括制造，交付，培训，支持及维护产品。第49页，共65页，2023年，2月20日，星期二这4个阶段构成开发周期，周期结束时产生一代新的软件产品。软件产品产生于初始开发周期，随着重复执行同样的过程，软件发展到下一代产品，这一时期即为软件的进化周期。

IECT

IECT

IECT

V1V2V3初始开发周期进化周期第50页，共65页，2023年，2月20日，星期二Rational统一过程的特点：用例驱动的、以体系结构（架构）为中心的、迭代和增量的过程。用例建模技术可以用为大多数项目相关人员理解的形式来表述问题。参与者（Actor）用例（UseCase）场景（scenario）事件流（eventflow）Actorusecase第51页，共65页，2023年，2月20日，星期二用例和参与者的事例银行储户通过自动取款机（自动柜员机）提款，转账或检查账户余额。用一组用例表达如下：转账提款检察账户余额储户第52页，共65页，2023年，2月20日，星期二用例模型将整个系统或子系统的所有用例，以及与之交互的参与者集合起来构成系统的用例模型。用例模型给出系统预期功能模型和系统上下文环境模型，它成为开发人员和用户之间的契约。用例模型的目的是确保系统能处理所有的功能性需求。第53页，共65页，2023年，2月20日，星期二用例驱动的过程“用例驱动”指开发过程是基于用例，从一个工作流向下一个工作流，逐步前进的。开发初期，人们使用用例获取用户需求，建立用例模型，描述系统的全部功能。基于用例模型，人们创建一系列实现这些用例的分析模型、设计模型和实现模型。测试人员测试实现确保系统正确实现了用例。第54页，共65页，2023年，2月20日，星期二以体系结构为中心的过程用例的选择不是孤立的，它与软件的体系结构是密切相关的。软件体系结构的作用与一个建筑的体系结构类似。对于一个建筑，可以从框架结构、供热、上下水、供电、天然气、其他服务管线等不同角度来考察它。使得施工人员在施工前就能全面了解这个建筑。软件的体系结构也从不同角度描述了即将构造的系统，包括系统的静态特征和动态特征。第55页，共65页，2023年，2月20日，星期二每一种产品都有功能和表现形式两个方面。用例就是功能，体系结构就是表现形式。在开发过程中，必须兼顾功能和表现形式，做出适当权衡，才能得到好的产品。因此，用例和体系结构必须在迭代中并行演进。为了找到可以演进的体系结构，设计师必须从全面了解系统的主要功能（即主要用例）入手。第56页，共65页，2023年，2月20日，星期二1.5软件开发范型(Paradigm)范型又称为风范。通常认为范型就是开发模型(Model)或开发模式(Pattern)，实际上它与方法(Methodology)一样，都被视为一种开发技术。范型支配了设计方法、编码语言、测试和检验技术的选择。过程性范型把软件视为处理流，定义成由一系列步骤构成的算法。每一步骤都是带有输入和输出的一个过程，把这些步骤串联在一起可产生贯通于整个程序的控制流。第57页，共65页，2023年，2月20日，星期二面向对象范型把标识和模型化问题领域中的实体做为系统开发的起点，面向对象系统中的对象是数据抽象与过程抽象的综合。逻辑性范型是基于规则的，它把有关问题的知识分解成一组具体规则(如prolog语言)。面向进程范型把一个问题分解成独立执行的模块。让不只一个程序同时运行。这些进程互相配合，解决问题。面向存取范型是一种在构造用户界面方面很有用的技术。第58页，共65页，2023年，2月20日，星期二函数型范型是基于规则的，它把有关问题的知识分解成一组具体规则，用语言的“if_then”等结构来表示这些规则。

说明性范型。每种开发范型都有它的支持者和用户：