请问什么是CORBA 标准 ，谢谢

CORBA(公共对象请求代理架构)：这是个和微软com,com+齐名的同类软件技术规范，由OMT提出。

用于在不同进程(程序)之间，甚至是不同物理机器上的进程(程序)之间通讯。底层技术依靠RPC[远程过程调用]实现。

典型的开发模型有：瀑布模型(waterfall model)、渐增模型/演化/迭代(incremental model)、原型模型(prototype model)、螺旋模型(spiral model)、喷泉模型(fountain model)、智能模型(intelligent model)、混合模型(hybrid model)

1、边做边改模型（Build-and-Fix Model）

遗憾的是，许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。

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

这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：

1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；

2） 忽略需求环节，给软件开发带来很大的风险；

3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

2、瀑布模型（Waterfall Model）

1970年温斯顿·罗伊斯提出了著名的“瀑布模型”，直到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、演化模型(evolutionary model)

主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。

在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。 实际上，这个模型可看作是重复执行的多个“瀑布模型”。

“演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。

7、喷泉模型（fountain model, (面向对象的生存期模型, 面向对象（Object Oriented,OO）模型））

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

8、智能模型（四代技术（4GL）)

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

9、混合模型（hybrid model）

过程开发模型又叫混合模型（hybrid model），或元模型（meta-model）,把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混合模型）。实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。

模型 优点 缺点

瀑布模型 文档驱动 系统可能不满足客户的需求

快速原型模型 关注满足客户需求 可能导致系统设计差、效率低，难于维护

增量模型 开发早期反馈及时，易于维护 需要开放式体系结构，可能会设计差、效率低

螺旋模型 风险驱动 风险分析人员需要有经验且经过充分训练

===================

OOA（面向对象的分析）模型由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。在这种方法中定义了两种对象类之间的结构，一种称为分类结构，一种称为组装结构。分类结构就是所谓的一般与特殊的关系。组装结构则反映了对象之间的整体与部分的关系。

OOA在定义属性的同时，要识别实例连接。实例连接是一个实例与另一个实例的映射关系。在定义服务的同时要识别消息连接。当一个对象需要向另一对象发送消息时，它们之间就存在消息连接。

OOA 中的5个层次和5个活动继续贯穿在OOD（画向对象的设计）过程中。OOD模型由4个部分组成。它们分别是设计问题域部分、设计人机交互部分、设计任务管理部分和设计数据管理部分。

Booch 认为软件开发是一个螺旋上升的过程。在螺旋上升的每个周期中，有4个步骤：标识类和对象、确定它们的含义、标识它们之间的关系、说明每一个类的界面和实现。

对象建模技术OMT定义了3种模型，它们是对象模型、动态模型和功能模型，OMT用这3种模型来描述系统。OMT方法有4个步骤：分析、系统设计、对象设计和实现。OMT方法的每一个步骤都使用这3种模型，每一个步骤对这3种模型不断地进行细化和扩充。

对象模型描述系统包括对象的静态结构、对象之间的关系、对象的属性和对象的 *** 作。OMT的对象模型中除了对象、类和继承外，还有链、关联、泛化、聚合和模块等概念。

动态模型用来描述与值的变换有关的系统特征--功能、映射、约束和函数依赖。功能模型用数据流图来表示。

每星期日 Sunday(星期日) 感染COM、EXE文件

Sunday-x(星期日变种)

Mindless(无头脑的) 感染COM文件，破坏文件或系统，查找文件时感染

XQR Boot区 COM EXE

Amilia(阿米拉) 感染COM文件

Witcode(智能码)

星期日(4月到12月9日) Doctor Qumak 2

每星期一 Carfield

BadGuy 恶棍 感染COM文件，破坏文件或系统，查找文件时感染，病毒长度206字节

BadGuy-2 恶棍2号 感染COM文件，破坏文件或系统，查找文件时感染

星期一(从1993年开始) VirDem (VirDem-833) 感染COM文件，发作时显示图像或动画，查找文件时感染

星期一逢1日 Beware 小心 感染COM文件，病毒长442字节，破坏文件或系统

星期一逢28日 Crazy Eddie 疯狂埃迪 感染COM文件，通过修改MCB尺寸方法驻留

每星期二 Ah

Demon 恶魔 感染COM文件，不驻留内存

Demon-B 恶魔-B 感染COM文件，不驻留内存

Murphy (Kamasya)

星期二逢1日 Jerusalem (JVT1) 感染COM文件

星期二逢13日 Jerusalem (Anarkia) 感染EXE文件，查找文件时感染

星期三(所有的) PS-MPC (No Wednesday)

Victor

星期四(所有的) TPE (Girafe)

星期四逢12日 CD 感染COM、EXE文件，显示图像或动画，运行文件时感染，通过修改MCB尺寸的方法驻留

星期五(所有的) Bryansk

Frere Jacques

PS-MPC (Mimic-Den Zuk)

PS-MPC (Mimic-Jerusalem)

Murphy (Smack) 感染COM、EXE文件，显示图像或动画，运行文件时感染，通过修改MCB尺寸的方法驻留

Talking Heads

Naziphobia

VCL (Diarrhea)

Wild Thing 2 感染COM文件，显示图像或动画，查找文件时感染，不驻留内存

星期五逢11日 VCL (Kinison)

星期五逢13日 1720

Friday 13th（黑色星期五） 感染COM文件，查找文件时感染，不驻留内存

Jerusalem (耶路撒冷) 感染COM、EXE文件，运行文件时感染，使用DOS标准方式驻留

RAM Virus

Suriv 300

Westwood

Witcode

Hybryd

星期五不逢13日 Payday 发薪日

星期五逢15日 VCL (Kinison)

星期五逢11日 Skism

Skism-1

星期五(每月最后一个) Sub-Zero B

星期六(所有的) Finger 手指

Phenome

Migram

星期六逢14日 Saturday The 14TH

每月1日 10 Past 3

PRGKILL 数据库杀手

1971 香烟

每月1、11、12、31日 Fish（鱼） Boot区FAT表COM文件

每月2、8日 Taiwan 台湾 COM

每月2日 Flip (翻转) 热甜啤酒 感染COM、EXE文件，发作时显示图像或动画，破坏文件或系统，运行时感染，通过修改MCB尺寸的方法驻留

Tormentor(Nuke)讨厌鬼 感染COM、文件，运行时感染，通过修改MCB尺寸的方法驻留

每月5日 Frogs 蛙

每月10日 Day 10 十日

每月13日 Rocko（RKO） COM EXE

NPox (NPox 21)

Nonxla

每月16日 10 Past 3 10点过3分

每月18日 NPox

Fired Love 10217燃烧的爱 EXE

FORM-Virus (Form-18)

每月20日 Day 10

每月21日(1995年以后) Doctor 医生的忠告

每月22日 10 Past 3

VCL (Veva 32)

每月24日 FORM-Virus Boot区 FAT表

Rocko (Nutating)

每月26日 CIH

每月29日 10 Past 3

Geek

Highlander 高地人 感染COM文件，发作时显示图像或动画，运行或查找文件时传播，使用DOS标准方式驻留

每月30日 Day 10

每月31日 Tormentor (Lixo Nuke)

VCL (Diogenes)

1月、4月、8月的15日 Casino （卡西诺） COM

1月1日 VCL (Beva 33)

1月3日 Joshi

1月1日到9月21日 Plastique 塑料炸d

1月5日 Joshi （生日快乐） Boot区 FAT表

Barrotes

1月8日 Taiwan台湾病毒 感染COM、EXE文件，发作时显示图像或动画，不驻留内存

1月11日 鱼病毒

1月15日 Casino 赌场

1月21日 鱼病毒

1月22日 红心病毒

1月31日 鱼病毒

2月1日到2月29日 Vienna (Beta Boys)二等仆人

2月2日 Amilia 黑色复仇者

Marauder （掠夺者、强盗） COM

2月19日 HXH-2106 莫斯科、友谊

2月23日 Swedish Boys瑞典仆人

2月24日 Swedish Boys瑞典仆人

2月25日 Swedish Boys瑞典仆人

Why （为什么） COM EXE

2月28日 Zaphod

3月1日到3月31日 Fich

Micropox

3月5日 X-2 (X-1 & X-1B)

3月6日 Michaelangelo米开朗基罗 Boot区 FAT表

RIP-699

3月15日 Maltese Amoeba （变形虫） COM EXE

3月24日 Vienna （维也纳） COM

4月1日 Casper （精灵） COM

Ghost 幽灵病毒

Disk Killer 磁盘杀手

Christmas Tree （圣诞树） COM (12月24日)

Israeli （以色列） COM

Suriv 101

Suriv 201

Suriv 402

4月1日到4月30日 Akuku (Wilbur 3)

4月1日到6月30日 Month 4-6

4月12日 ARCV Friends

4月15日 Casino 赌场

Swami

4月17日 ZGB/2128

4月26日 CIH病毒

5月1日到5月4日 1210 谨慎病毒

Prudent （小心） EXE

5月1日到5月31日 Kthulhu

5月4日 XQR (New Century)新世纪 Boot区 FAT表 COM EXE

5月5日 PS-PC (Cinco de Mayo)

6月4日 6．4 Boot区 FAT表

6月6日 Sub-Zero B 零下-B

Tiny Virus (Kennedy) 感染COM文件

6月14日 Gremlin

6月16日 June 16TH

6月1日到12月31日 June 17TH

6月26日 DOSHunter DOS猎手

6月28日 Crazy Eddie 感染COM文件

7月1日到7月31日 ARCV 330

7月1日到12月31日 Got-You 拦住你

Jerusalem-PLO 感染COM、EXE文件

Mendoza

7月4日 VCL (Beva 96) 珍珠港病毒

7．4 感染COM文件

7月13日 July 13TH

ChangSha94 秋水病毒

7月26日 July 26TH

8月15日 Casino 赌场

8月15日到12月31日 Violater （暴徒） 感染COM文件

8月16日 August 16TH

8月17日 ZGB/2128

8月31日 Bomber 轰炸机

9月1日到9月30日 AirCop 空中警察

Cascade

Sad

TenBytes 感染COM、EXE文件，破坏文件或系统

9月4日 Violator 攻击者 感染COM、EXE文件

9月8日 RIP-699

9月9日(1994年以后) Dabi/Little Red (唱东方红)

9月16日 It (Viva Mexico)

9月20日到12月31日 Plastique 塑料炸d COM EXE

Plastique-B

9月22日到12月31日 4096 (百年) OVL COM EXE

10月1日到12月31日 Cascade/1701 (小瀑布、雨点） COM

TenBytes 感染COM、EXE文件，破坏文件或系统

Violator-C 侵犯者 感染COM、EXE文件

10月4日 Violator B1 攻击者B1 感染COM、EXE文件

10月12日 Akuku (Columbus)

Anarkia-B

10月13日到12月31日 Date Crime 数据罪犯 COM EXE

10月15日 Dark End 黑色尽头 感染COM、EXE文件

10月23日 Karin

10月28日 Aragorn

10月31日 Halloween (HW) COM EXE

Violator B2 攻击者B2

11月1日 Maltese Amoba

11月4日 Violator B1

11月11日 Flower 花 感染EXE文件，发作时显示图像或动画，查找文件时感染，破坏文件或系统

11月11日到25日 Brothers （兄弟） 感染COM文件

11月12日 Timor

11月17日 November 17TH 感染COM、EXE文件

11月17日到12月31日 November 17-880 感染COM、EXE文件，通过MCB尺寸方法驻留内存，病毒长度800字节，病毒位置文件尾部

11月18日 Tiny Virus 感染COM文件

11月22日 Tiny Virus 感染COM文件

11月29日 1971 香烟病毒

11月30日 Jerusalem 11-30 感染COM、EXE文件，使用DOS标准方式驻留

12月1日到12月31日 1253

12月1日 ANT

12月4日 Violator B1 感染COM文件，发作时显示图像、动画或发出声音

12月7日 VCL (Pearl Harbor)

12月19日到12月31日 Father Christmas圣诞老人

12月20日到12月25日 ARCV Xmas

12月20日到12月31日 SRI848

12月21日 Poem 感染COM文件，发作时显示图像或动画，破坏文件或系统

12月24日 Icelandic-III 冰岛

Christmas Tree （圣诞树） COM （4月1日）

12月24日到12月31日 Witcode

12月24日到1月1日 Christmas Tree 发作时显示图像或动画，不驻留内存

12月25日 Japanese Christmas日本圣诞节 COM

Violator B3

12月26日(1994年以后) Dabi/Little Red(唱浏阳河)

12月28日 Spanish April Fools西班牙愚人节

12月31日 Violator B2 攻击者B2

1989年8月1日之后 Fu Manchu 富满族

1990年6月之后 Flash 闪烁

1990年8月之后 Datalock 数据锁

1990年8月14日之后 Violator 侵犯者

1990年11月11日之后 Fingers 手指

1991年12月31日之后 Sicilian Mob西西里暴徒

1992年12月31日之后 CyberTech 感染COM文件，不驻留内存

OMT

1993年1月1日之后 Grunt-1 感染COM文件，破坏文件或系统

1993年12月31日之后 CyberTech-B 感染COM文件，不驻留内存

1992年 Europe-92 92欧洲年 感染COM文件，发作时显示图像或动画，不驻留内存

Were Here 感染COM文件，发作时显示图像或动画

60年代中期开始爆发了众所周知的软件危机。为了克服这一危机，在1968、1969年连续召开的两次著名的NATO会议上提出了软件工程这一术语，并在以后不断发展、完善。与此同时，软件研究人员也在不断探索新的软件开发方法。至今已形成八类软件开发方法。

一、1972年 Parnas方法

二、1978年 SASA方法

三、1975年 面向数据结构的软件开发方法(至今仍广泛使用)

四、问题分析法

五、面向对象的软件开发方法

六、可视化开发方法

一、Parnas方法

最早的软件开发方法是由D．Parnas在1972年提出的。由于当时软件在可维护性和可靠性方面存在着严重问题，因此Parnas提出的方法是针对这两个问题的。首先，Parnas提出了信息隐蔽原则：在概要设计时列出将来可能发生变化的因素，并在模块划分时将这些因素放到个别模块的内部。这样，在将来由于这些因素变化而需修改软件时，只需修改这些个别的模块，其它模块不受影响。信息隐蔽技术不仅提高了软件的可维护性，而且也避免了错误的蔓延，改善了软件的可靠性。现在信息隐蔽原则已成为软件工程学中的一条重要原则。

Parnas提出的第二条原则是在软件设计时应对可能发生的种种意外故障采取措施。软件是很脆弱的，很可能因为一个微小的错误而引发严重的事故，所以必须加强防范。如在分配使用设备前，应该取设备状态字，检查设备是否正常。此外，模块之间也要加强检查，防止错误蔓延。

Parnas对软件开发提出了深刻的见解。遗憾的是，他没有给出明确的工作流程。所以这一方法不能独立使用，只能作为其它方法的补充。

二、�SASA方法

1978年，E．Yourdon和L．L．Constantine提出了结构化方法，即SASD方法，也可称为面向功能的软件开发方法或面向数据流的软件开发方法。1979年TomDeMarco对此方法作了进一步的完善。

Yourdon方法是80年代使用最广泛的软件开发方法。它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，最后是结构化编程（SP）。这一方法不仅开发步骤明确，SA、SD、SP相辅相成，一气呵成，而且给出了两类典型的软件结构（变换型和事务型），便于参照，使软件开发的成功率大大提高，从而深受软件开发人员的青睐。

三、面向数据结构的软件开发方法

Jackson方法

1975年，M．A．Jackson提出了一类至今仍广泛使用的软件开发方法。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。

Jackson方法有时也称为面向数据结构的软件设计方法。

Warnier方法

1974年，J．D．Warnier提出的软件开发方法与Jackson方法类似。

差别有三点：一是它们使用的图形工具不同，分别使用Warnier图和Jackson图；另一个差别是使用的伪码不同；最主要的差别是在构造程序框架时，Warnier方法仅考虑输入数据结构，而Jackson方法不仅考虑输入数据结构，而且还考虑输出数据结构。

四、问题分析法

PAM问题分析法。PAM（ProblemAnalysisMethod）是80年代末由日立公司提出的一种软件开发方法。

PAM方法希望能兼顾Yourdon方法、Jackson方法和自底向上的软件开发方法的优点，而避免它们的缺陷。它的基本思想是：考虑到输入、输出数据结构，指导系统的分解，在系统分析指导下逐步综合。这一方法的具体步骤是：从输入、输出数据结构导出基本处理框；分析这些处理框之间的先后关系；按先后关系逐步综合处理框，直到画出整个系统的PAD图。从上述步骤中可以看出，这一方法本质上是综合的自底向上的方法，但在逐步综合之前已进行了有目的的分解，这个目的就是充分考虑系统的输入、输出数据结构。

PAM方法的另一个优点是使用PAD图。这是一种二维树形结构图，是到目前为止最好的详细设计表示方法之一，远远优于NS图和PDL语言。

这一方法在日本较为流行，软件开发的成功率也很高。由于在输入、输出数据结构与整个系统之间同样存在着鸿沟，这一方法仍只适用于中小型问题。

五、面向对象的软件开发方法

面向对象技术是软件技术的一次革命，在软件开发史上具有里程碑的意义。

随着OOP（面向对象编程）向OOD（面向对象设计）和OOA（面向对象分析）的发展，最终形成面向对象的软件开发方法OMT(LbjectModellingTechnique）。这是一种自底向上和自顶向下相结合的方法，而且它以对象建模为基础，从而不仅考虑了输入、输出数据结构，实际上也包含了所有对象的数据结构。所以OMT彻底实现了PAM没有完全实现的目标。不仅如此，OO技术在需求分析、可维护性和可靠性这三个软件开发的关键环节和质量指标上有了实质性的突破，彻底地解决了在这些方面存在的严重问题，从而宣告了软件危机末日的来临。

自底向上的归纳

OMT的第一步是从问题的陈述入手，构造系统模型。从真实系统导出类的体系，即对象模型包括类的属性，与子类、父类的继承关系，以及类之间的关联。类是具有相似属性和行为的一组具体实例（客观对象）的抽象，父类是若干子类的归纳。因此这是一种自底向上的归纳过程。在自底向上的归纳过程中，为使子类能更合理地继承父类的属性和行为，可能需要自顶向下的修改，从而使整个类体系更加合理。由于这种类体系的构造是从具体到抽象，再从抽象到具体，符合人类的思维规律，因此能更快、更方便地完成任务。这与自顶向下的Yourdon方法构成鲜明的对照。在Yourdon方法中构造系统模型是最困难的一步，因为自顶向下的“顶”是一个空中楼阁，缺乏坚实的基础，而且功能分解有相当大的任意性，因此需要开发人员有丰富的软件开发经验。而在OMT中这一工作可由一般开发人员较快地完成。在对象模型建立后，很容易在这一基础上再导出动态模型和功能模型。这三个模型一起构成要求解的系统模型。

自顶向下的分解

系统模型建立后的工作就是分解。与Yourdon方法按功能分解不同，在OMT中通常按服务（Service）来分解。服务是具有共同目标的相关功能的集合，如I／O处理、图形处理等。这一步的分解通常很明确，而这些子系统的进一步分解因有较具体的系统模型为依据，也相对容易。所以OMT也具有自顶向下方法的优点，即能有效地控制模块的复杂性，同时避免了Yourdon方法中功能分解的困难和不确定性。

OMT的基础是对象模型

每个对象类由数据结构（属性）和 *** 作（行为）组成，有关的所有数据结构（包括输入、输出数据结构）都成了软件开发的依据。因此Jackson方法和PAM中输入、输出数据结构与整个系统之间的鸿沟在OMT中不再存在。OMT不仅具有Jackson方法和PAM的优点，而且可以应用于大型系统。更重要的是，在Jackson方法和PAM方法中，当它们的出发点输入、输出数据结构（即系统的边界）发生变化时，整个软件必须推倒重来。但在OMT中系统边界的改变只是增加或减少一些对象而已，整个系统改动极小。

需求分析彻底

需求分析不彻底是软件失败的主要原因之一。即使在目前，这一危险依然存在。传统的软件开发方法不允许在开发过程中用户的需求发生变化，从而导致种种问题。正是由于这一原因，人们提出了原型化方法，推出探索原型、实验原型和进化原型，积极鼓励用户改进需求。在每次改进需求后又形成新的进化原型供用户试用，直到用户基本满意，大大提高了软件的成功率。但是它要求软件开发人员能迅速生成这些原型，这就要求有自动生成代码的工具的支持。

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

可维护性大大改善

在OMT之前的软件开发方法都是基于功能分解的。尽管软件工程学在可维护方面作出了极大的努力，使软件的可维护性有较大的改进。但从本质上讲，基于功能分解的软件是不易维护的。因为功能一旦有变化都会使开发的软件系统产生较大的变化，甚至推倒重来。更严重的是，在这种软件系统中，修改是困难的。由于种种原因，即使是微小的修改也可能引入新的错误。所以传统开发方法很可能会引起软件成本增长失控、软件质量得不到保证等一系列严重问题。正是OMT才使软件的可维护性有了质的改善。

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

更重要的是OMT彻底解决了软件的可维护性。在OO语言中，子类不仅可以继承父类的属性和行为，而且也可以重载父类的某个行为（虚函数）。利用这一特点，我们可以方便地进行功能修改：引入某类的一个子类，对要修改的一些行为（即虚函数或虚方法）进行重载，也就是对它们重新定义。由于不再在原来的程序模块中引入修改，所以彻底解决了软件的可修改性，从而也彻底解决了软件的可维护性。OO技术还提高了软件的可靠性和健壮性。

六、可视化开发方法

可视化开发是90年代软件界最大的两个热点之一。随着图形用户界面的兴起，用户界面在软件系统中所占的比例也越来越大，有的甚至高达60～70％。产生这一问题的原因是图形

界面元素的生成很不方便。为此Windows提供了应用程序设计接口API（Application Programming Interface），它包含了600多个函数，极大地方便了图形用户界面的开发。但是在这批函数中，大量的函数参数和使用数量更多的有关常量，使基于Windows API的开发变得相当困难。为此Borland C++推出了Object Windows编程。它将API的各部分用对象类进行封装，提供了大量预定义的类，并为这些定义了许多成员函数。利用子类对父类的继承性，以及实例对类的函数的引用，应用程序的开发可以省却大量类的定义，省却大量成员函数的定义或只需作少量修改以定义子类。

Object Windows还提供了许多标准的缺省处理，大大减少了应用程序开发的工作量。但要掌握它们，对非专业人员来说仍是一个沉重的负担。为此人们利用Windows API或Borland C++的Object Windows开发了一批可视开发工具。

可视化开发就是在可视开发工具提供的图形用户界面上，通过 *** 作界面元素，诸如菜单、按钮、对话框、编辑框、单选框、复选框、列表框和滚动条等，由可视开发工具自动生成应用软件。

这类应用软件的工作方式是事件驱动。对每一事件，由系统产生相应的消息，再传递给相应的消息响应函数。这些消息响应函数是由可视开发工具在生成软件时自动装入的

1997年，OMG组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML）。UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML提出了一套IT专业人员期待多年的统一的标准建模符号。通过使用UML，这些人员能够阅读和交流系统架构和设计规划--就像建筑工人多年来所使用的建筑设计图一样。

2003年，UML已经获得了业界的认同。

UML的是要成为一种标准的统一语言，使得IT专业人员能够进行计算机应用程序的建模。UML的主要创始人是Jim Rumbaugh、Ivar Jacobson和Grady Booch，他们最初都有自己的建模方法（OMT、OOSE和Booch），彼此之间存在着竞争。最终，他们联合起来创造了一种开放的标准。UML成为标准建模语言的原因之一在于，它与程序设计语言无关。而且，UML符号集只是一种语言而不是一种方法学。因为语言与方法学不同，它可以在不做任何更改的情况下很容易地适应任何公司的业务运作方式。

UML不是一种方法学，不需要任何正式的工作产品。而且它还提供了多种类型的模型描述图（diagram），当在某种给定的方法学中使用这些图时，它使得开发中的应用程序的更易理解。UML的内涵远不只是这些模型描述图，但是对于入门来说，这些图对这门语言及其用法背后的基本原理提供了很好的介绍。通过把标准的UML图放进工作产品中，精通UML的人员就更加容易加入项目并迅速进入角色。最常用的UML图包括：用例图、类图、序列图、状态图、活动图、组件图和部署图。

UML语言开发始于1994年8月，当时Rational软件公司的Booch和Rumbaugh着手进行统一的Booch方法和OMT方法，以便以后得到一种统一的建模语言。1995年10月，他们发布了统一方法（UM）的初级版本。同年秋天，Jacobson加盟联合开发小组，并力图把OOSE方法也统一进来。

经过Booch、Rumbaugh和Jacobson的努力，UML09和091版在1996年的6月和10月出版。1996年，OMG（对象管理组）发布了向外界征集关于面向对象建模标准方法的消息。UML的3位创始人开始与来自其它公司的软件工程方法专家和开发人员一道制定了一套OMG感兴趣的方法，并设计了一种被软件开发工具提供者、软件开发方法学家和开发人员这些最终用户接受的建模语言。与此同时，其它一些相关人员也在做这项富有竞争性的工作。1997年9月1日产生了UML11，并提交到OMG进行讨论。

OMG于1997年11月正式接纳了UML11，然后成立任务组不断的修订，并产生了UML12、13和14版本，其中UML13是较为重要的修订版本。该组织正在对UML进行重大修订，其目标是推出UML20，做为向ISO提交的标准方案。

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

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

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

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

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

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

1994年10月，Grady Booch和Jim Rumbaugh开始致力于这一工作。他们首先将Booch 93和OMT-2 统一起来，并于1995年10月发布了第一个公开版本，称之为统一方法UM 08（Unitied Method）。1995年秋，OOSE 的创始人Ivar Jacobson加盟到这一工作。经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分别发布了两个新的版本，即UML 09和UML 091，并将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 10（1997年1月）及UML 11（1997年11月17日）的定义和发布起了重要的促进作用。

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

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

1：瀑布方法

所有软件方法的祖先是瀑布方法（waterfall methodology）。它之所以被称为瀑布方法是因为开发模块相互之间的依次流动，瀑布方法通过控制阀门的一系列活动组成。这些控制阀门决定一个给定的活动是否已经完成并且可以进入下一个活动。需求阶段处理决定了所有的软件需求。设计阶段决定整个系统的设计。代码在代码阶段编写。代码然后被测试。最后产品被发布。

对瀑布方法模型最基本的批评就是瀑布方法对于反馈事物发展状况耗时太长。软件的一些内容那个很容易被理解，而另一些内容则相反。因此，当用户对于手边出现的问题都没有很好理解的时候，开发人员试图先完成所有的需求（也就是说，将需求量化到实际的规格说明当中）是非常空难的。更进一步来说，如果在需求中出现一个错误，它将传播到设计阶段，传播到代码中等。同时一般不存在过程中返回的真正能力。因此，如果进入测试并且发现设计的一部分是无法工作的，那么就会进行修改并修补问题而交差，但是这种方法将会失去设计活动的所有上下文环境——你只是有目的地对系统权宜行事！

认识到这个问题后瀑布方法已经被修改成几种形式。例如螺旋式瀑布方法它继承并使用了多个瀑布模型。这种方法缩短了生命周期向下的时间；也就是说，为解决为题提供了迭代方案。

最终，大家无法脱离瀑布方法是因为它确实是合乎常规的方法。首先，这种方法可以决定将要构建的内容。接着，决定将要如何构建这些，下一步，世界构建这些内容。可以确保自己确实构建自己所需的东西（并且可以成功运行）。

2：统一过程

统一过程应用了基于处理系统首先考虑的最重要方面而实施的短期迭代开发。

开发一个寡欲各种用列（use case）的调查文档（也就是说，对用户与系统交互的简短描述），并且开始排除那些可能对整个系统成功造成风险的用列。只要适合，就可以在开发过程中添加或者删除用列。

统一过程的4个阶段定义如下：

初始(inception)：系统仍然处于决定系统内容的阶段——系统将要完成什么以及系统的边界是什么。如果系统能够很好的理解，那么这个阶段就非常短。

细化(Elaboration)：正在将体系结构的风险移至系统。一种表述该阶段的说法是，“你是否已经解决了所有难题？”或者“你知道如何完成你将要去完成的事情吗？”

构造（Construction）正在完成所有相关的用列来使系统为移交做好准备，也就是说，进入Beta版本。

移交（Transition）使系统通过它的最后发布阶段以及Beta版本。它可能包括软件的 *** 作及维护。

这是一个关注于维护要素的敏捷过程，但是仍然采用了大量用例开发，间模等方面的传统实践。

3：极限编程：

极限编程的开发过程就是以代码为中心的方法。

让用户告知你一些有关系统是如何如用转的故事描述，基于故事相互之间的重要性来定制这些系统这样就可以为自己的团队提供一个故事集合，可以在一个给定的迭代中完成他们，大约两周时间——每周工作40个小时，你将团队划分，双人应付没一个故事，在代码被编写时提供确定数量的内建对等评审。你和你的同伴在编写自己代码的同时编写单元测试。在完成自己负责的那段代码后，将其拿到集成的机器上，放入代码基线，运行从所有人的代码中积累而成的单元测试。在完成iji负责的那段代码后，将会提供一个运行系统使用户可以评审来确保自己的工作满足他们的需要。

注意极限编程并没有将软件的设计设置成一个高级阶段。相反它认为那些最前端的设计对于整个系统开发不是很有帮助，并且随着实际开发的进行它最终还是被修改。

极限编程对于需要持续提供运行系统的软件卡发来说非常适用。当缺少用户介入或者项目规模很大时极限编程方法将会不好用，因为这时协调和设计活动实际上变得更重要了。

极限编程合理地考虑开发团体的能力，这样可以有效计划。

对象(object)是一件事、一个实体、一个名词，可以获得的东西，可以想象有自己的标识的任何东西。对象是类的实例化。一些对象是活的，一些对象不是。比如这辆汽车、这个人、这间房子、这张桌子、这株植物、这张支票、这件雨衣。 概括来说就是：万物皆对象。

面向对象(ObjectOriented,OO)是当前计算机界关心的重点，它是90年代软件开发方法的主流。面向对象的概念和应用已超越了程序设计和软件开发，扩展到很宽的范围。如数据库系统、交互式界面、应用结构、应用平台、分布式系统、网络管理结构、CAD技术、人工智能等领域。

面向对象的基本概念

(1)对象。

对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。

(2)对象的状态和行为。

对象具有状态，一个对象用数据值来描述它的状态。

对象还有 *** 作，用于改变对象的状态，对象及其 *** 作就是对象的行为。

对象实现了数据和 *** 作的结合，使数据和 *** 作封装于对象的统一体中

(3)类。

具有相同或相似性质的对象的抽象就是类。因此，对象的抽象是类，类的具体化就是对象，也可以说类的实例是对象。

类具有属性，它是对象的状态的抽象，用数据结构来描述类的属性。

类具有 *** 作，它是对象的行为的抽象，用 *** 作名和实现该 *** 作的方法来描述。

(4)类的结构。

在客观世界中有若干类，这些类之间有一定的结构关系。通常有两种主要的结构关系，即一般--具体结构关系，整体--部分结构关系。

①一般——具体结构称为分类结构，也可以说是“或”关系，或者是“is a”关系。

②整体——部分结构称为组装结构，它们之间的关系是一种“与”关系，或者是“has a”关系。

(5)消息和方法。

对象之间进行通信的结构叫做消息。在对象的 *** 作中，当一个消息发送给某个对象时，消息包含接收对象去执行某种 *** 作的信息。发送一条消息至少要包括说明接受消息的对象名、发送给该对象的消息名（即对象名、方法名）。一般还要对参数加以说明，参数可以是认识该消息的对象所知道的变量名，或者是所有对象都知道的全局变量名。

二、面向对象的特征

(1)对象唯一性。

每个对象都有自身唯一的标识，通过这种标识，可找到相应的对象。在对象的整个生命期中，它的标识都不改变，不同的对象不能有相同的标识。

(2)分类性。

分类性是指将具有一致的数据结构(属性)和行为( *** 作)的对象抽象成类。一个类就是这样一种抽象，它反映了与应用有关的重要性质，而忽略其他一些无关内容。任何类的划分都是主观的，但必须与具体的应用有关。

(3)继承性。

继承性是子类自动共享父类数据结构和方法的机制，这是类之间的一种关系。在定义和实现一个类的时候，可以在一个已经存在的类的基础之上来进行，把这个已经存在的类所定义的内容作为自己的内容，并加入若干新的内容。

继承性是面向对象程序设计语言不同于其它语言的最重要的特点，是其他语言所没有的。

在类层次中，子类只继承一个父类的数据结构和方法，则称为单重继承。

在类层次中，子类继承了多个父类的数据结构和方法，则称为多重继承。

在软件开发中，类的继承性使所建立的软件具有开放性、可扩充性，这是信息组织与分类的行之有效的方法，它简化了对象、类的创建工作量，增加了代码的可重性。

采用继承性，提供了类的规范的等级结构。通过类的继承关系，使公共的特性能够共享，提高了软件的重用性。

(4)多态性(多形性)

多态性使指相同的 *** 作或函数、过程可作用于多种类型的对象上并获得不同的结果。不同的对象，收到同一消息可以产生不同的结果，这种现象称为多态性。

多态性允许每个对象以适合自身的方式去响应共同的消息。

多态性增强了软件的灵活性和重用性。

三、面向对象的要素

(1)抽象。

抽象是指强调实体的本质、内在的属性。在系统开发中，抽象指的是在决定如何实现对象之前的对象的意义和行为。使用抽象可以尽可能避免过早考虑一些细节。

类实现了对象的数据（即状态）和行为的抽象。

(2)封装性（信息隐藏）。

封装性是保证软件部件具有优良的模块性的基础。

面向对象的类是封装良好的模块，类定义将其说明（用户可见的外部接口）与实现（用户不可见的内部实现）显式地分开，其内部实现按其具体定义的作用域提供保护。

对象是封装的最基本单位。封装防止了程序相互依赖性而带来的变动影响。面向对象的封装比传统语言的封装更为清晰、更为有力。

(3)共享性

面向对象技术在不同级别上促进了共享

同一类中的共享。同一类中的对象有着相同数据结构。这些对象之间是结构、行为特征的共享关系。

在同一应用中共享。在同一应用的类层次结构中，存在继承关系的各相似子类中，存在数据结构和行为的继承，使各相似子类共享共同的结构和行为。使用继承来实现代码的共享，这也是面向对象的主要优点之一。

在不同应用中共享。面向对象不仅允许在同一应用中共享信息，而且为未来目标的可重用设计准备了条件。通过类库这种机制和结构来实现不同应用中的信息共享。

4强调对象结构而不是程序结构

四、面向对象的开发方法

目前，面向对象开发方法的研究已日趋成熟，国际上已有不少面向对象产品出现。面向对象开发方法有Coad方法、Booch方法和OMT方法等。

1Booch方法

Booch最先描述了面向对象的软件开发方法的基础问题，指出面向对象开发是一种根本不同于传统的功能分解的设计方法。面向对象的软件分解更接近人对客观事务的理解，而功能分解只通过问题空间的转换来获得。

2Coad方法

Coad方法是1989年Coad和Yourdon提出的面向对象开发方法。该方法的主要优点是通过多年来大系统开发的经验与面向对象概念的有机结合，在对象、结构、属性和 *** 作的认定方面，提出了一套系统的原则。该方法完成了从需求角度进一步进行类和类层次结构的认定。尽管Coad方法没有引入类和类层次结构的术语，但事实上已经在分类结构、属性、 *** 作、消息关联等概念中体现了类和类层次结构的特征。

3OMT方法

OMT方法是1991年由James Rumbaugh等5人提出来的，其经典著作为“面向对象的建模与设计”。

该方法是一种新兴的面向对象的开发方法，开发工作的基础是对真实世界的对象建模，然后围绕这些对象使用分析模型来进行独立于语言的设计，面向对象的建模和设计促进了对需求的理解，有利于开发得更清晰、更容易维护的软件系统。该方法为大多数应用领域的软件开发提供了一种实际的、高效的保证，努力寻求一种问题求解的实际方法。

4UML(Unified Modeling Language)语言

软件工程领域在1995年～1997年取得了前所未有的进展，其成果超过软件工程领域过去15年的成就总和，其中最重要的成果之一就是统一建模语言（UML)的出现。UML将是面向对象技术领域内占主导地位的标准建模语言。

UML不仅统一了Booch方法、OMT方法、OOSE方法的表示方法，而且对其作了进一步的发展，最终统一为大众接受的标准建模语言。UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发全过程。

4、指男、女朋友

在ASP动态网页中，对象是一个抽象的概念，是要 *** 作的目标。比如，在现实生活中，电脑就是我们搜寻资料的一个对象，他具有外观、 *** 作系统、价格等等特点，这在对象概念中被称为属性，而利用这个电脑玩游戏、看**、查找资料等用途，这就对应于对象里的方法，另外，主板、CPU、显卡、键盘等等组件，我们可以称作对象的集合。

在ASP动态网页中，对象的特点归结起来有三个：属性、方法、集合。

拜托大家看下分类是电脑

以上就是关于请问什么是CORBA 标准 ，谢谢全部的内容，包括:请问什么是CORBA 标准 ，谢谢、介绍常见软件过程模型（瀑布，原型，增量，螺旋）的原理及优缺点回答好追分200、有什么电脑病毒(比如熊猫烧香）等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！