软件工程对象模型(什么是UML系统建模)

2023-10-25 01:50:03 :31

软件工程对象模型(什么是UML系统建模)

各位老铁们好,相信很多人对软件工程对象模型都不是特别的了解,因此呢,今天就来为大家分享下关于软件工程对象模型以及什么是UML系统建模的问题知识,还望可以帮助大家,解决大家的一些困惑,下面一起来看看吧!

本文目录

什么是UML系统建模

UML

统一建模语言(UML是 Unified Modeling Language的缩写)是用来对软件密集系统进行可视化建模的一种语言。UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。

统一建模语言 (UML)是非专利的第三代建模和规约语言。 UML是在开发阶段,说明,可视化,构建和书写一个面向对象软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践,这些最佳实践在对大规模,复杂系统进行建模方面,特别是在软件架构层次已经被验证有效。

UML可以贯穿软件开发周期中的每一个阶段。被OMG采纳作为业界的标准。

UML最适于数据建模,业务建模,对象建模,组件建模。

UML作为一种模型语言,它使开发人员专注于建立产品的模型和结构,而不是选用什么程序语言和算法实现。当模型建立之后,模型可以被UML工具转化成指定的程序语言代码。

IBM的Rational Rose和MS的Visio都是UML工具。

一. 标准建模语言UML的出现

公认的面向对象建模语言出现于70年代中期。从1989年到1994年,其数量从不到十种增加到了五十多种。在众多的建模语言中,语言的创造者努力推崇自己的产品,并在实践中不断完善。但是,OO方法的用户并不了解不同建模语言的优缺点及相互之间的差异,因而很难根据应用特点选择合适的建模语言,于是爆发了一场“方法大战”。90年代中,一批新方法出现了,其中最引人注目的是Booch 1993、OOSE和OMT-2等。

Booch是面向对象方法最早的倡导者之一,他提出了面向对象软件工程的概念。1991年,他将以前面向Ada的工作扩展到整个面向对象设计领域。Booch 1993比较适合于系统的设计和构造。

Rumbaugh等人提出了面向对象的建模技术(OMT)方法,采用了面向对象的概念,并引入各种独立于语言的表示符。这种方法用对象模型、动态模型、功能模型和用例模型,共同完成对整个系统的建模,所定义的概念和符号可用于软件开发的分析、设计和实现的全过程,软件开发人员不必在开发过程的不同阶段进行概念和符号的转换。OMT-2特别适用于分析和描述以数据为中心的信息系统。

Jacobson于1994年提出了OOSE方法,其最大特点是面向用例(Use-Case),并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器,但用例贯穿于整个开发过程,包括对系统的测试和验证。OOSE比较适合支持商业工程和需求分析。

此外,还有Coad/Yourdon方法,即著名的OOA/OOD,它是最早的面向对象的分析和设计方法之一。该方法简单、易学,适合于面向对象技术的初学者使用,但由于该方法在处理能力方面的局限,目前已很少使用。

概括起来,首先,面对众多的建模语言,用户由于没有能力区别不同语言之间的差别,因此很难找到一种比较适合其应用特点的语言;其次,众多的建模语言实际上各有千秋;第三,虽然不同的建模语言大多类同,但仍存在某些细微的差别,极大地妨碍了用户之间的交流。因此在客观上,极有必要在精心比较不同的建模语言优缺点及总结面向对象技术应用实践的基础上,组织联合设计小组,根据应用需求,取其精华,去其糟粕,求同存异,统一建模语言。

1994年10月,Grady Booch和Jim Rumbaugh开始致力于这一工作。他们首先将Booch 93和OMT-2 统一起来,并于1995年10月发布了第一个公开版本,称之为统一方法UM 0.8(Unitied Method)。1995年秋,OOSE 的创始人Ivar Jacobson加盟到这一工作。经过Booch、Rumbaugh和Jacobson三人的共同努力,于1996年6月和10月分别发布了两个新的版本,即UML 0.9和UML 0.91,并将UM重新命名为UML(Unified Modeling Language)。

1996年,一些机构将UML作为其商业策略已日趋明显。UML的开发者得到了来自公众的正面反应,并倡议成立了UML成员协会,以完善、加强和促进UML的定义工作。当时的成员有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI以及Unisys。这一机构对UML 1.0(1997年1月)及UML 1.1(1997年11月17日)的定义和发布起了重要的促进作用。

UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。

面向对象技术和UML的发展过程可用上图来表示,标准建模语言的出现是其重要成果。在美国,截止1996年10月,UML获得了工业界、科技界和应用界的广泛支持,已有700多个公司表示支持采用UML作为建模语言。1996年底,UML已稳占面向对象技术市场的85%,成为可视化建模语言事实上的工业标准。1997年11月17日,OMG采纳UML 1.1作为基于面向对象技术的标准建模语言。UML代表了面向对象方法的软件开发技术的发展方向,具有巨大的市场前景,也具有重大的经济价值和国防价值。

软件工程XP模型简介

软件工程(Software Engineering,简称为SE)是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言,数据库,软件开发工具,系统平台,标准,设计模式等方面。 在现代社会中,软件应用于多个方面。典型的软件比如有电子邮件,嵌入式系统,人机界面,办公套件,操作系统,编译器,数据库,游戏等。同时,各个行业几乎都有计算机软件的应用,比如工业,农业,银行,航空,政府部门等。这些应用促进了经济和社会的发展,使得人们的工作更加高效,同时提高了生活质量。 软件工程师是对应用软件创造软件的人们的统称,软件工程师按照所处的领域不同可以分为系统分析员,软件设计师,系统架构师,程序员,测试员等等。人们也常常用程序员来泛指各种软件工程师。 软件工程(SoftWare Engineering)的框架可概括为:目标、过程和原则。 (1)软件工程目标:生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题,它们形成了对过程、过程模型及工程方法选取的约束。 (2)软件工程过程:生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义,又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构,包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明,包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程,实现完成后的确认,保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程,还有管理过程、支持过程、培训过程等。 (3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。一、软件工程概述 概念:应需而生 软件工程是一类工程。工程是将理论和知识应用于实践的科学。就软件工程而言,它借鉴了传统工程的原则和方法,以求高效地开发高质量软件。其中应用了计算机科学、数学和管理科学。计算机科学和数学用于构造模型与算法,工程科学用于制定规范、设计范型、评估成本及确定权衡,管理科学用于计划、资源、质量和成本的管理。 软件工程这一概念,主要是针对20世纪60年代“软件危机”而提出的。它首次出现在1968年NATO(北大西洋公约组织)会议上。自这一概念提出以来,围绕软件项目,开展了有关开发模型、方法以及支持工具的研究。其主要成果有:提出了瀑布模型,开发了一些结构化程序设计语言(例如PASCAL语言,Ada语言)、结构化方法等。并且围绕项目管理提出了费用估算、文档复审等方法和工具。综观60年代末至80年代初,其主要特征是,前期着重研究系统实现技术,后期开始强调开发管理和软件质量。 70年代初,自“软件工厂”这一概念提出以来,主要围绕软件过程以及软件复用,开展了有关软件生产技术和软件生产管理的研究与实践。其主要成果有:提出了应用广泛的面向对象语言以及相关的面向对象方法,大力开展了计算机辅助软件工程的研究与实践。尤其是近几年来,针对软件复用及软件生产,软件构件技术以及软件质量控制技术、质量保证技术得到了广泛的应用。目前各个软件企业都十分重视资质认证,并想通过这些工作进行企业管理和技术的提升。软件工程所涉及的要素可概括如下: 根据这一框架,可以看出:软件工程涉及了软件工程的目标、软件工程原则和软件工程活动。 目标:我的眼里只有“产品” 软件工程的主要目标是:生产具有正确性、可用性以及开销合宜的产品。正确性意指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜性是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多问题有待解决,它们形成了对过程、过程模型及工程方法选取的约束。 软件工程活动是“生产一个最终满足需求且达到工程目标的软件产品所需要的步骤”。主要包括需求、设计、实现、确认以及支持等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义,又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件体系结构,包括子系统、模块以及相关层次的说明、每一模块接口定义。详细设计产生程序员可用的模块说明,包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程,实现完成后的确认,保证最终产品满足用户的要求。支持活动包括修改和完善。伴随以上活动,还有管理过程、支持过程、培训过程等。 框架:四项基本原则是基石 软件工程围绕工程设计、工程支持以及工程管理,提出了以下四项基本原则: 第一,选取适宜开发范型。该原则与系统设计有关。在系统设计中,软件需求、硬件需求以及其他因素之间是相互制约、相互影响的,经常需要权衡。因此,必须认识需求定义的易变性,采用适宜的开发范型予以控制,以保证软件产品满足用户的要求。 第二,采用合适的设计方法。在软件设计中,通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现,以达到软件工程的目标。 第三,提供高质量的工程支持。“工欲善其事,必先利其器”。在软件工程中,软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。 第四,重视开发过程的管理。软件工程的管理,直接影响可用资源的有效利用,生产满足目标的软件产品,提高软件组织的生产能力等问题。因此,仅当软件过程得以有效管理时,才能实现有效的软件工程。 这一软件工程框架告诉我们,软件工程的目标是可用性、正确性和合算性;实施一个软件工程要选取适宜的开发范型,要采用合适的设计方法,要提供高质量的工程支撑,要实行开发过程的有效管理;软件工程活动主要包括需求、设计、实现、确认和支持等活动,每一活动可根据特定的软件工程,采用合适的开发范型、设计方法、支持过程以及过程管理。根据软件工程这一框架,软件工程学科的研究内容主要包括:软件开发范型、软件开发方法、软件过程、软件工具、软件开发环境、计算机辅助软件工程(CASE) 及软件经济学等。 作用:高效开发高质量软件 自从软件工程概念提出以来,经过30多年的研究与实践,虽然“软件危机”没得到彻底解决,但在软件开发方法和技术方面已经有了很大的进步。尤其应该指出的是,自80年代中期,美国工业界和政府部门开始认识到,在软件开发中,最关键的问题是软件开发组织不能很好地定义和管理其软件过程,从而使一些好的开发方法和技术都起不到所期望的作用。也就是说,在没有很好定义和管理软件过程的软件开发中,开发组织不可能在好的软件方法和工具中获益。 根据调查,中国的现状几乎和美国10多年前的情况一样,软件开发过程没有明确规定,文档不完整,也不规范,软件项目的成功往往归功于软件开发组的一些杰出个人或小组的努力。这种依赖于个别人员上的成功并不能为全组织的软件生产率和质量的提高奠定有效的基础,只有通过建立全组织的过程改善,采用严格的软件工程方法和管理,并且坚持不懈地付诸实践,才能取得全组织的软件过程能力的不断提高。 这一事实告诉我们,只有坚持软件工程的四条基本原则,既重视软件技术的应用,又重视软件工程的支持和管理,并在实践中贯彻实施,才能高效地开发出高质量的软件。

在软件工程中类和对象之间有什么类似之处

类只是为所有的对象定义了抽象的属性与行为。

对象和类是面向对象编程的概念。对象可以是一个变量,一个数据结构,或是一个函数。是面向对象中的术语,既表示客观世界问题空间中的某个具体的事物,又表示软件系统解空间中的基本元素。

类就是关于对象的抽象,例如人这个类,就是每一个具体人的抽象;交通工具类,就是自行车,汽车,飞机等的抽象。

扩展资料:

软件工程原理、软件工程过程、软件工程方法、软件工程模型、软件工程管理、软件工程度量、软件工程环境、软件工程应用、软件工程开发使用。运行时,能够提供所要求功能和性能的指令或计算机程序集合。程序能够满意地处理信息的数据结构。描述程序功能需求以及程序如何操作和使用所要求的文档。以开发语言作为描述语言,可以认为:软件=程序+数据+文档。

软件工程的开发方法包括面向用户的方法么

软件工程的开发方法包括面向用户的方法。

1.面向对象技术是软件技术的一次革命,在软件开发史上具有里程碑的意义。随着OOP(面向对象编程)向OOD(面向对象设计)和OOA(面向对象分析)的发展,最终形成面向对象的软件开发方法OMT(Object Modelling Technique)。

2.这是一种自底向上和自顶向下相结合的方法,而且它以对象建模为基础,从而不仅考虑了输入、输出数据结构,实际上也包含了所有对象的数据结构。

3.所以OMT彻底实现了PAM没有完全实现的目标。不仅如此,OO技术在需求分析、可维护性和可靠性这三个软件开发的关键环节和质量指标上有了实质性的突破,彻底地解决了在这些方面存在的严重问题,从而宣告了软件危机末日的来临。

扩展资料:

面向对象技术的几大特点:

1.自底向上的归纳

(1)OMT的第一步是从问题的陈述入手,构造系统模型。从真实系统导出类的体系,即对象模型包括类的属性,与子类、父类的继承关系,以及类之间的关联。类是具有相似属性和行为的一组具体实例(客观对象)的抽象,父类是若干子类的归纳。

(2)因此这是一种自底向上的归纳过程。在自底向上的归纳过程中,为使子类能更合理地继承父类的属性和行为,可能需要自顶向下的修改,从而使整个类体系更加合理。由于这种类体系的构造是从具体到抽象,再从抽象到具体,符合人类的思维规律,因此能更快、更方便地完成任务。

(3)这与自顶向下的Yourdon方法构成鲜明的对照。在Yourdon方法中构造系统模型是最困难的一步,因为自顶向下的“顶”是一个空中楼阁,缺乏坚实的基础,而且功能分解有相当大的任意性,因此需要开发人员有丰富的软件开发经验。

(4)而在OTM中这一工作可由一般开发人员较快地完成。在对象模型建立后,很容易在这一基础上再导出动态模型和功能模型。这三个模型一起构成要求解的系统模型。

2.自顶向下的分解

(1)系统模型建立后的工作就是分解。与Yourdon方法按功能分解不同,在OMT中通常按服务(Service)来分解。服务是具有共同目标的相关功能的集合,如I/O处理、图形处理等。这一步的分解通常很明确,而这些子系统的进一步分解因有较具体的系统模型为依据,也相对容易。

(2)所以OMT也具有自顶向下方法的优点,即能有效地控制模块的复杂性,同时避免了Yourdon方法中功能分解的困难和不确定性。

3.OMT的基础是对象模型

(1)每个对象类由数据结构(属性)和操作(行为)组成,有关的所有数据结构(包括输入、输出数据结构)都成了软件开发的依据。因此Jackson方法和PAM中输入、输出数据结构与整个系统之间的鸿沟在OMT中不再存在。

(2)OMT不仅具有Jackson方法和PAM的优点,而且可以应用于大型系统。更重要的是,在Jackson方法和PAM方法中,当它们的出发点--输入、输出数据结构(即系统的边界)发生变化时,整个软件必须推倒重来。但在OMT中系统边界的改变只是增加或减少一些对象而已,整个系统改动极小。

4.需求分析彻底

(1)需求分析不彻底是软件失败的主要原因之一。即使在目前,这一危险依然存在。传统的软件开发方法不允许在开发过程中用户的需求发生变化,从而导致种种问题。正是由于这一原因,人们提出了原型化方法,推出探索原型、实验原型和进化原型,积极鼓励用户改进需求。

(2)在每次改进需求后又形成新的进化原型供用户试用,直到用户基本满意,大大提高了软件的成功率。但是它要求软件开发人员能迅速生成这些原型,这就要求有自动生成代码的工具的支持。

(3)OMT彻底解决了这一问题。因为需求分析过程已与系统模型的形成过程一致,开发人员与用户的讨论是从用户熟悉的具体实例(实体)开始的。开发人员必须搞清现实系统才能导出系统模型,这就使用户与开发人员之间有了共同的语言,避免了传统需求分析中可能产生的种种问题。

5.可维护性大大改善

(1)在OMT之前的软件开发方法都是基于功能分解的。尽管软件工程学在可维护方面作出了极大的努力,使软件的可维护性有较大的改进。但从本质上讲,基于功能分解的软件是不易维护的。因为功能一旦有变化都会使开发的软件系统产生较大的变化,甚至推倒重来。

(2)更严重的是,在这种软件系统中,修改是困难的。由于种种原因,即使是微小的修改也可能引入新的错误。所以传统开发方法很可能会引起软件成本增长失控、软件质量得不到保证等一系列严重问题。正是OMT才使软件的可维护性有了质的改善。

(3)OMT的基础是目标系统的对象模型,而不是功能的分解。功能是对象的使用,它依赖于应用的细节,并在开发过程中不断变化。由于对象是客观存在的,因此当需求变化时对象的性质要比对象的使用更为稳定,从而使建立在对象结构上的软件系统也更为稳定。

软件工程的开发模型主要有什么模型

1.瀑布模型

瀑布模型的特点是:

阶段间具有顺序性和依赖性,前一阶段结束后才能开始后一阶段的工作,前一阶段的输出是厚意阶段的输入;推迟实现观点,尽可能推迟程序的物理实现;强调质量保证观点,每个阶段必须完成规定的文档,每个阶段结束前完成文档以便及早改正错误。

优点:

(1)原理简单,容易掌握。

(2)各阶段间都有验证和确认环节,以便进行质量管理。

(3)主要用于支持结构化方法

缺点:

(1)缺乏灵活性,不能适应用户的需求变化。

(2)缺乏演化性,返回上一级的开发需要付出十分高昂的代价

(3)是线性的软件开发模型,回溯性差。

使用场合:

(1)适合于软件需求比较明确或很少变化,且开发人员可以一次性获取到全部需求的场合

(2)适合开发技术比较成熟,工程管理比较严格的场合

(3)一般用于低风险的项目,适合开发人员具有丰富的经验。

2.快速原型模型

快速原型是快速建立起来的可以在计算上运行的程序,是软件的一个早期可运行的版本,它的功能是最终产品的子集。用途主要是获取用户的真正的需求。

优点:

(1)增强了开发者于用户间的交流,有助于满足用户的真实需求。

(2)用户可及早得到有用的产品,可及早发现问题,随时纠正错误,

(3)减小技术、应用风险,可降低开发费用,缩短开发时间

缺点:

(1)缺乏丰富而强有力的软件工具和开发环境

(2)对设计人员及开发环境要求较高

(3)难于做到彻底测试,更新文档较为困难

适用场合:

(1)预先不能确切定义需求的软件系统,或需求多变的系统

(2)开发人员对设计方案没信心或对将要采用的技术手段不熟悉或把握性不大

(3)原型模型可作为单独的过程模型使用,也常被作为一种方法或实现技术应用于其他的过程模型中。

3.渐增模型

渐增模型也叫增量模型,其实质上是分段的线性模型,是一种非整体开发模型,渐增模型把软件产品作为一系列增量构件来设计、编码、集成和测试,在项目开发过程中以一系列的增量方式来逐步开发系统。

优点:

(1)可分批次提交软件产品,方便用户及时了解软件开发进展情况,及早发现问题。

(2)以组件为单位进行开发,降低了软件开发的风险。

(3)开发顺序灵活,优先级最高的服务首先交付。

缺点:

(1)由于对整个软件系统的需求没有一个完整的定义,会给总体设计带来麻烦。

(2)在把每个新的增量构件集成到现有软件结构中时,必须不破坏原来已开发出的产品。

(3)软件的体系结构必须是开放的,即向产品中加入新构件的过程必须简单、方便。每次增量开发的产品都应当是可测试的,可扩充的。

适用场合:

(1)软件产品可以分批次地进行交互

(2)待开发的软件系统能够被模块化

(3)软件开发人员对应用领域不熟悉、难以一次性地进行软件开发时。

(4)项目管理人员把握全局的水平较高时

(5)对软件需求把握不准确、设计方案有一定风险的项目

4.喷泉模型

喷泉一词体现了迭代和无间隙特性,迭代是指开发软件系统时,某些部分经常要重复多次,相关功能在每次迭代中随之加入演进的系统。

特点:

(1)各阶段相互重叠,反映了软件过程的并行性

(2)以分析为基础,资源消耗呈塔形,在分析阶段消耗的资源最多。

(3)反映了软件过程迭代的自然特性,从高层返回低层无资源消耗

(4)强调增量开发,依据分析一点、设计一点为原则,不要求一个阶段完成,整个过程是一个迭代的逐步提炼过程。

5.螺旋模型

螺旋模型是在结合瀑布模型与快速原型模型基础上演变而成的 ,并且加入了风险分析。其基本思想是,使用原型及其它方法来尽量降低风险。

在螺旋模型中,将软件过程表示为一个螺旋线,在螺旋线上的每一个循环表示过程的一个阶段。整个过程的实现按以下四个步骤完成:

(1)指定计划

(2)风险分析

(3)工程实施

(4)客户评估

适用场合:

(1)适用于面向规格说明、面向过程和面向对象的软件开发方法。

(2)也适用于几种开发方法的组合和产生的组合模型。

缺点:

(1)要求开发人员必须具有丰富的风险评估经验和专门知识。

软件工程三种模型之间的关系

(1)动态模型描述了类实例的生命周期或运行周期。(2)动态模型的状态转换驱使行为发生,这些行为在数据流图中被映射成处理,在用例图中被映射成用例,它们同时与类图中的服务相对应。(3)功能模型中的用例对应于复杂对象提供的服务,简单的用例对应于更基本的对象提供的服务;有时一-个用例对应多个服务,也有一个服务对应多个用例的时候。(4)功能模型数据流图中的数据流,往往是对象模型中对象的属性值,也可能是整个对象;数据流图中的数据存储,以及数据的源点/终点,通常是对象模型中的对象。


软件开发模型有哪几种各有什么特点

软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。对于不同的软件系统,可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等,以及允许采用不同的软件工具和不同的软件工程环境。软件工程的主要环节包括人员管理、项目管理、需求分析、系统设计、程序设计、测试、维护等,如图所示。软件开发模型是对软件过程的建模,即用一定的流程将各个环节连接起来,并可用规范的方式操作全过程,好比工厂的生产线。

最早出现的软件开发模型最早出现的软件开发模型是1970年W•Royce提出的瀑布模型。 该模型给出了固定的顺序,将生存期活动从上一个阶段向下一个阶段逐级过渡,如同流水下泻,最终得到所开发的软件产品,投入使用。但计算拓广到统计分析、商业事务等领域时,大多数程序采用高级语言(如FORTRAN、COBOL等)编写。瀑布模式模型也存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的 需求等缺点。常见的软件开发模型还有演化模型、螺旋模型、喷泉模型、智能模型等。本段典型的开发模型典型的开发模型有:

1.边做边改模型(Build-and-Fix Model);

2.瀑布模型(Waterfall Model);

3.快速原型模型(Rapid Prototype Model);

4.增量模型(演化模型)(Incremental Model);

5.螺旋模型(Spiral Model);

6.喷泉模型(fountain model);

7.智能模型(四代技术(4GL));

8.混合模型(hybrid model);

9.RUP模型;

10.IPD模型

1.边做边改模型(Build-and-Fix Model)遗憾的是,许多产品都是使用"边做边改"模型来开发的。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。

在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止。

这是一种类似作坊的开发方式,对编写几百行的小程序来说还不错,但这种方法对任何规模的开发来说都是不能令人满意的,其主要问题在于:(1) 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改;(2)忽略需求环节,给软件开发带来很大的风险;(3)没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。

2.瀑布模型(Waterfall Model)

1970年Winston Royce提出了著名的"瀑布模型",直到80年代早期,它一直是唯一被广泛采用的软件开发模型。

瀑布模型中,如图所示,将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于:(1) 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量;(2) 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险;(3) 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。

我们应该认识到,"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非 线性"问题时,总是千方百计地将其分解或转化为一系列简单的线性问题,然后逐个解决。一个软件系统的整体可能是复杂的,而单个子程序总是简单的,可以用线性的方式来实现,否则干活就太累了。线性是一种简洁,简洁就是美。当我们领会了线性的精神,就不要再呆板地套用线性模型的外表,而应该用活它。例如增量模 型实质就是分段的线性模型,螺旋模型则是接连的弯曲了的线性模型,在其它模型中也能够找到线性模型的影子。

3.快速原型模型(Rapid Prototype Model)快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。

显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。

4.增量模型(Incremental Model)又称演化模型。与建造大厦相同,软件也是一步一步建造起来的。在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。

增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。但是,增量模型也存在以下缺陷:(1) 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。(2) 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。例如,使用增量模型开发字处理软件。可以考虑,第一个增量发布基本的文件管理、和文档生成功能,第二个增量发布更加完善的和文档生成功能,第三个增量实现拼写和文法检查功能,第四个增量完成高级的页面布局功能。

5.螺旋模型(Spiral Model)

1988年,Barry Boehm正式发表了软件系统开发的"螺旋模型",它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。

如图所示,螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:(1) 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;(2) 风险分析:分析评估所选方案,考虑如何识别和消除风险;(3) 实施工程:实施软件开发和验证;(4) 客户评估:评价开发工作,提出修正建议,制定下一步计划。螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。但是,螺旋模型也有一定的限制条件,具体如下:(1) 螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适应于内部的大规模软件开发。(2) 如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,因此,螺旋模型只适合于大规模软件项目。(3) 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险。一个阶段首先是确定该阶段的目标,完成这些目标的选择方案及其约束条件,然后从风险角度分析方案的开发策略,努力排除各种潜在的风险,有时需要通过建造原型来完成。如果某些风险不能排除,该方案立即终止,否则启动下一个开发步骤。最后,评价该阶段的结果,并设计下一个阶段。

6.喷泉模型(fountain model)(也称面向对象的生存期模型, OO模型)

喷泉模型与传统的结构化生存期比较,具有更多的增量和迭代性质,生存期的各个阶段可以相互重叠和多次反复,而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来,可以落在中间,也可以落在最底部。

7.智能模型(四代技术(4GL))

智能模型拥有一组工具(如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等),每个工具都能使开发人员在高层次上定义软件的某些特性,并把开发人员定义的这些软件自动地生成为源代码。这种方法需要四代语言(4GL)的支持。4GL不同于三代语言,其主要特征是用户界面极端友好,即使没有受过训练的非专业程序员,也能用它编写程序;它是一种声明式、交互式和非过程性编程语言。4GL还具有高效的程序代码、智能缺省假设、完备的 数据库和应用程序生成器。目前市场上流行的4GL(如Foxpro等)都不同程度地具有上述特征。但4GL目前主要限于事务信息系统的中、小型应用程序的 开发。

8.混合模型(hybrid model)过程开发模型又叫混合模型(hybrid model),或元模型(meta-model),把几种不同模型组合成一种混合模型,它允许一个项目能沿着最有效的路径发展,这就是过程开发模型(或混合模型)。实际上,一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。各种模型的比较每个软件开发组织应该选择适合于该组织的软件开发模型,并且应该随着当前正在开发的特定产品特性而变化,以减小所选模型的缺点,充分利用其优点,下表列出了几种常见模型的优缺点。各种模型的优点和缺点:模型优点缺点瀑布模型文档驱动系统可能不满足客户的需求快速原型模型关注满足客户需求可能导致系统设计差、效率低,难于维护增量模型开发早期反馈及时,易于维护需要开放式体系结构,可能会设计差、效率低螺旋模型风险驱动风险分析人员需要有经验且经过充分训练

9.RUP模型(迭代模型)

RUP(Rational Unified Process)模型是Rational公司提出的一套开发过程模型,它是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程,它们具有相同的结构,即相同的流程构架。RUP 为在开发组织中分配任务和职责提供了一种规范方法,其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。RUP具有两个轴,一个轴是时间轴,这是动态的。另一个轴是工作流轴,这是静态的。在时间轴上,RUP划分了四个阶段:初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上,RUP设计了六个核心工作流程和三个核心支撑工作流程,核心工作流轴包括:业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括:环境工作流、项目管理工作流和配置与变更管理工作流。RUP 汇集现代软件开发中多方面的最佳经验,并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型,它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂,因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。它具有如下特点:(1)增量迭代,每次迭代都遵循瀑布模型能够在前期控制好和解决风险;(2)模型的复杂化,需要项目管理者具有较强的管理能力。

10.IPD模型

IPD(Integrated Product Development)流程是由IBM提出来的一套集成产品开发流程,非常适合于复杂的大型开发项目,尤其涉及到软硬件结合的项目。

IPD从整个产品角度出发,流程综合考虑了从系统工程、研发(硬件、软件、结构工业设计、测试、资料开发等)、制造、财务到市场、采购、技术支援等所有流程。是一个端到端的流程。在IPD流程中总共划分了六个阶段(概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段),四个个决策评审点(概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点)以及六个技术评审点。

IPD流程是一个阶段性模型,具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。一定程度上,该模型是通过流程成本来提高整个产品的质量并获得市场的占有。由于该流程没有定义如何进行流程回退的机制,因此对于需求经常变动的项目该流程就显得不大适合了。并且对于一些小的项目,也不是非常适合使用该流程。

《软件工程》研究生复试知识点总结

title: 《软件工程》研究生复试知识点总结 categories: 计算机专业课 tags: "软件工程" "复试"

前言 :软件工程知识点总结,是在本人的另外两篇文章—— 《软件工程导论》期末知识点复习 和 《UML面向对象需求分析与建模教程》期末知识点总结复习 的基础上按常见复试大纲详细总结的。注:本书参考《软件工程导论》第六版,张海藩,红色的那本。

《--more--》

①瀑布模型特点:

②瀑布模型适用:在开发的早期阶段软件需求被完整确定 ③瀑布模型的优点: 可强迫开发人员采用规范的方法;严格规定了每个阶段必须提交的文档;要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证 ④瀑布模型缺点:瀑布模型是由文档驱动;最终产品不能真正满足客户的需求

①核心工作流 (纵轴代表核心工作流,横轴代表时间) 前6个为核心过程工作流, 后3个为核心支持工作流

②工作阶段

③RUP迭代式开发:RUP强调采用迭代和渐增的方式来开发软件,整个项目由多个迭代过程组成。

其优点:

其缺点:

①流图的表示:

②计算环形复杂度的方法:

①非结构化维护

①基本原则:尽可能模拟人类习惯的思维方式,是开发软件的方法和过程尽可能接近人类认识的世界解决问题的方法和过程 ②4个要点

①对象的定义

①三个子模型,按所解决的问题进行划分

②5个层次

③对象模型创建的步骤

关于本次软件工程对象模型和什么是UML系统建模的问题分享到这里就结束了,如果解决了您的问题,我们非常高兴。

软件工程对象模型(什么是UML系统建模)

本文编辑:admin
Copyright © 2022 All Rights Reserved 威海上格软件有限公司 版权所有

鲁ICP备20007704号

Thanks for visiting my site.