第1章软件工程概述

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
28
构件组装模型 软件体系结构被建立后,必须用构件去充实,这些构 件可从复用库中获得,或者根据专门需要而开发。整个过程 可以演化地进行,面向对象方法给予技术上的支持。
29
构件技术目前主要有三种流行标准: • OMG的CORBA: 对象管理组织发布的公用对象请求代理体系 结构(Common Object Request Broker Architecture)。通过一个对象请求代理(ORB) 提供一系列服务,使得一个构件和其他构件通信, 而不管它们在系统中的位置,实现了远程对象通 过接口进行通信的机制。 为了解决CORBA对象引用不透明、缺少多 重接口、系统过于复杂等问题,专家们又开发了 新一代面向对象中间件平台 ICE Fra Baidu bibliotek Internet Communications Engine—互联网通信引擎)。 使构建分布式应用系统更容易、性能和伸缩性更 好。
25
形式化过程模型的一个扩展,称为净室软件工程 (cleanroom software engineering)或净室模型, 它除了强调分析和设计上的严格性,以及使用基于数 学的正确性证明来对设计模型的每个元素进行形式化 验证外,还强调了统计质量控制技术。 基本思想: 力求在分析和设计阶段就消除错误,确保正确, 然后在无缺陷或“洁净”的状态下实现软件的制作。
特点: • 提供了软件过程模型的基本框架(模板)。 • 强调了每一阶段活动的严格顺序。 • 质量保证观点:以经过评审确认了的阶段工 作产品(文档)驱动下一阶段的工作,便于 管理。 • 是一种整体开发模型,程序的物理实现集中 在开发阶段的后期,用户在最后才能看到自 己的产品。 • 适合于用户需求明确、完整、无重大变化的 软件项目开发。
14
原型的分类: • 抛弃型:主要用于需求分析阶段,针对开 发目标模糊、用户与开发者对项目都缺乏经验 的情况。建立原型的目的是为了搞清用户的需 求,确定所期望的特性,探索各种方案的可行 性。产生完整、一致、准确的需求说明。 • 实验型:主要用于设计阶段,通过原型验 证设计方案的可行性。原型或成为设计结果的 一部分或抛弃。 • 演化型:用于整个开发阶段。原型经过不 断扩充,演化为最终的软件系统。
21
(5) 形式化方法模型
是基于形式化语言和程序变换的模型,因 此,也称变换模型。从软件需求形式化说明开 始,经过一系列的数学变换和正确性证明,最 终得到系统的目标程序。形式化方法使开发者 应用一个严格的数学符号体系来表示、构造和 验证系统,从而大大提高软件的可靠性。 模型见下图:
22
变换模型
形式化开发记录
2
软件的特征
软件是一种逻辑实体,不是具体的物理
实体

软件与硬件的生产方式不同 软件与硬件的维护不同 软件是复杂的 软件成本相当昂贵
3
软件危机
60年代中期,随着硬件技术的发展,软件应用 范围的扩展,软件越来越大型化、复杂化,产生了 上万行的源程序。 当发现错误时需要对这些程序进行修改; 当用户需求发生变化时需要修改; 当硬件环境更新时需要修改。 1968年10月,北大西洋公约组织(NATO)的 科学委员会提出了软件危机问题:将大型软件开发 中普遍存在的费用高、开发过程不易控制、工作量 估计困难、软件质量低、软件项目失败率高、无法 判断大型系统能够正常工作以及软件维护任务重等 现象,归结为“软件危机”。
19
20
螺旋的第一圈可能产生产品的规格说明, 再下面的螺旋可能用于开发一个原型,随后可 能是软件的更完善的版本。每一圈还要根据用 户评估的反馈对项目计划(包括进度、费用) 进行调整。 特点: • 适合于大型系统的软件开发,随着过程 的进展演化,开发者和用户能够更好的识别和 对待每一个演化级别上的风险。 • 需要相当丰富的风险评估经验和专门知识, 使该模型的应用受到一定限制。 • 随着迭代次数的增加,工作量加大,软件 开发成本增加。
关键技术: • 基于统计过程控制之下的增量开发。 • 基于函数的规范、设计、验证。
• 统计测试和软件认证。
26
日本东京法政大学刘少英教授针对于形式化 工程设计了一种SOFL ( Structured Objectoriented Formal Language)语言。 SOFL = Language + Method + Process model . 结合VDM-SL (VDM specification language) 、Petri Nets、DFD的特点,设计了含 有控制的DFD(CDFD),并提出了可将其转换为 形式化的需求规约的匹配技术,该需求规约直接 为下层编码奠定了基础。还开发了SOFL的GUI原 型和需求规约测试工具的原型。
6
软件工程的基本原理

软件工程专家B.W.Boehm提出了软件工程的7条基本原理 : 1. 用分阶段的生存周期计划严格管理 2. 坚持进行阶段评审 3. 实行严格的产品控制 4. 采用现代程序设计技术 5. 结果应能清楚地审查 6. 开发小组的人员应少而精

7. 承认不断改进软件工程实践的必要性
5
软件工程的定义 根据IEEE(The Institute for Electrical and Electronic engineers) 定义: 软件工程是使用系统化的、规范的、可量 化的方法指导软件开发、运行和维护的一门学 科,它涉及到计算机科学(构造模型和算法)、 工程科学(制定规范、降低成本及确定权衡)、 管理科学(计划、资源、质量及成本等管理)、 数学等领域的综合性知识及实践的应用,它的 目的是建造用户满意的高质量的软件。
16
(3) 增量模型 是一种渐进地开发逐步完善的软件版本的模型。
17
特点: • 反复的应用瀑布模型的基本成分和原型模 型的迭代特征,每一个线型过程产生一个“增 量”的发布或提交,该增量均是一个可运行的 产品。 • 早期的版本实现用户的基本需求,并提供 给用户评估的平台。
18
(4) 螺旋模型 对于复杂的大型软件,开发一个原型往往 达不到要求。螺旋模型将瀑布模型和增量模型 结合起来,加入了风险分析。在该模型中,软 件开发使一系列的增量发布,早期的迭代中, 发布的增量可能是一个纸上的模型或原型,在 以后的迭代中,逐步产生系统更加完善的版本。 螺旋模型将开发过程划分为几个螺旋周期, 每个周期有三到六个任务区域,见下图。
第1章 软件工程概述


本章主要内容
软件的发展、定义及特征;软件危机的 表现及解决途径;软件工程的定义及三要素, 软件工程的基本原理及目标;软件生存周期 的概念和内容;软件开发模型;软件开发方 法和开发工具;传统软件工程和面向对象软 件工程。
1
第1章 软件工程概述



本章结构: 1.1 软件与软件危机 1.2 软件工程 1.3 软件生存周期 1.4 软件开发模型 1.5 软件开发方法和软件开发 工具 1.6 传统软件工程和面向对象 软件工程
27
(6)构件组装模型 构件(component)也称为组件,是一段 实现一系列有确定接口的程序体,具有自己的 功能和逻辑,能同其他构件组装起来协调工作。 该模型支持软件重用,对缩短软件开发周 期、降低项目成本有重要的现实意义。同时, 建造符合某应用领域体系结构标准的构件,可 以用来搭建分布式的、跨越不同操作平台的软 件,扩展了软件的应用前景,促进了软件标准 化、商品化的发展。 因此,在此基础上专家们又提出了“基于 构件的软件工程”(CBSE)。 构件组装模型如下图所示:
与需求比 较后修正
变换n

形式化 规格说明 系统需求
变换2 变换1
测试 目标系统
23
两种技术: • 基于模型的规格说明及其变换技术 基于模型的技术使用数学上的结构如集合和 函数为系统建模。它们能展现系统的状态以简化 对某些行为的描述。基于模型的描述语言及方法 如Z、VDM(Vienna Definition Method)、B、 Petri Nets等。 • 基于代数结构及其变换技术 代数方法适合于对接口的描述。这里接口被 定义为一组对象类或抽象数据类型的集合,用接 口操作之间的关系来刻画系统。
24
特点:
• 该模型迫使对系统需求的分析在软件开发 的早期阶段完成。在这个阶段改正错误比在系 统被交付之后修改错误要经济得多。 • 形式化描述是对非形式化描述技术的补充。 可以用来精化非形式化的详细的系统需求描述。 描述是精确的和无二义的,避免了由于语言误 解而产生的一些问题。 • 最适合用于安全性、可靠性和保密性等性 能要求极高的系统。 • 开发成本较高。 • 需要严格的数学理论和开发环境的支持。 • 难以与用户进行通信。
7

软件工程的基本目标 付出较低的开发成本; 达到预期的软件功能; 取得较好的软件性能; 使软件易于移植;
需要较低的维护费用; 能按时完成开发工作,及时 交付使用。 互补关系:
互斥关系: 低开发成本

易于维护
按时交付
高可靠性
高性能
图 1.1 软件工程目标之间的关系
9
过程: 定义一系列活动: 技术方法的采用, 工程产品(模型、文档、数据)的产生, 里程碑(milestone)的建立, 质量的保证及变更的管理。 该层构成了软件项目的管理控制的基础。 方法:提供了建造软件在技术上“如何做”。 方法覆盖了一系列任务:需求分析、设计、 编程、测试和支持(如纠错、适应、增强、预 防)。
工具: 对过程和方法提供了自动或半自动的支持。
10
软件过程模型 将软件生存周期划分为: 软件定义、需求分析、软件设计、编码、 测试及软件运行与维护等几个阶段。 每一阶段有明确的任务,把规模大、结 构复杂、管理复杂的软件开发变得容易控制和 管理。 各个阶段的活动如何衔接,开发过程中采 用什么样的策略,应遵守什么样的规定和制约, 将这些活动框架(忽略不必要的细节)用一种 模型表示出来,称为软件过程模型(或软件开 发模型)。
15
存在的问题: ⑴ 为了使原型尽快的工作,没有考虑软件 的总体质量和长期的可维护性。 ⑵ 为了演示,可能采用不合适的操作系统、 编程语言、效率低的算法,这些不理想的选择 成了系统的组成部分。 ⑶ 开发过程不便于管理。 有效的使用原型模式是: 建造原型仅是为了定义需求,之后就被 抛弃(或被部分抛弃),实际的软件在充分考 虑了质量和可维护性之后才被开发。
4
为了克服软件危机,科学家们从其他产 业(如机械制造、建筑等)的工程化生产得到 启示,于1968年在NANO的学术会上提出了 “软件工程”的概念。 克服软件危机的努力: (1)从管理的角度: 软件开发过程的研究 文档的标准化以及人们的交流方式 (2)软件开发中分析设计方法的研究 面向过程的开发 面向对象的开发
30
• 微软的COM / DCOM: 微软开发了构件对象模型(Component Object Model),它提供了运行于windows之上 的单个应用系统使用不同厂商生产的构件的规 约。基于分布式环境下的COM称为DCOM (Distribute COM)。 • SUN的 EJB ( Enterprise JavaBean ): 随着Java在企业级应用的地位日趋重要, Sun提出了一个统一的企业级Java平台—J2EE (Java 2 Enterprise Edition)。在J2EE中, EJB负责最核心的业务处理。它为服务器端的应 用程序提供了一种与厂商无关的Java接口,让 任何符合EJB规范的构件都可以运行在每一台这 样的服务器上。
13
(2) 原型模型 在用户不能给出完整、准确的需求说明,或者开发 者不能确定算法的有效性、操作系统的适应性或人机交互 的形式等许多情况下,可以根据用户的一组基本需求,快 速建造一个原型(可运行的软件),然后进行评估,进一 步精化、调整原型,使其满足用户的要求,也使开发者对 将要做的事情有更好的理解。
11

(1) 瀑布模型
瀑布模型规定了各项软件工程活动,包括:制定开发计 划、需求分析和说明、软件设计、程序编码、测试、运行 维护。并且规定了它们自上而下、相互衔接的固定次序, 如同瀑布流水,逐级下落。如图1.2所示。

计划 定义 阶段 需求分析
开 发 阶 段
设计
编码
测试 维护阶段 运行、维护 图 1.2 瀑布模型
相关文档
最新文档