软件体系结构描述语言与程序设计语言有什么区别
从软件体系结构研究和应用的现状来看,当前对软件体系结构的描述,在很大程度上来说还停留在非形式化的基础上,很大程度上依赖于软件设计师个人的经验和技巧。
在目前通用的软件开发方法中,其对软件体系结构的描述通常是采用非形式化的图和文本,不能描述系统期望的存在于构件之间的接口,更不能描述不同的组成系统的组合关系的意义。
这种描述方法难以被开发人员理解,难以适于进行形式化分析和模拟,缺乏相应的支持工具帮助设计师完成设计工作,更不能用来分析其一致性和完整性等特性。
因此,形式化的、规范化的体系结构描述对于体系结构的设计和理解都是非常重要的。
然而,要实现体系结构设计、描述等的形式化并不是一蹴而就的,我们必须先经历一个非形式化的过程,在非形式化的发展过程中逐步提取一些形式化的标记和符号,然后将它们标准化,从而完成体系结构设计、描述等的形式化。
本文首先简单地介绍传统的软件体系结构描述方法,然后再比较详细地讨论软件体系结构描述语言。
一、传统软件体系结构描述方法1、图形表达工具对于软件体系结构的描述和表达,一种简洁易懂且使用广泛的方法是采用由矩形框和有向线段组合而成的图形表达工具。
在这种方法中,矩形框代表抽象构件,框内标注的文字为抽象构件的名称,有向线段代表辅助各构件进行通讯、控制或关联的连接件。
例如:图1表示某软件辅助理解和测试工具的部分体系结构描述。
目前,这种图形表达工具在软件设计中占据着主导地位。
尽管由于在术语和表达语义上存在着一些不规范和不精确,而使得以矩形框与线段为基础的传统图形表达方法在不同系统和不同文档之间有着许多不一致甚至矛盾,但该方法仍然以其简洁易用的特点在实际的设计和开发工作中被广泛使用,并为工作人员传递了大量重要的体系结构思想。
为了克服传统图形表达方法中所缺乏的语义特征,有关研究人员试图通过增加含有语义的图元素的方式来开发图文法理论。
2、模块内连接语言软件体系结构的第二种描述和表达方法是采用将一种或几种传统程序设计语言的模块连接起来的模块内连接语言MIL(Module Interconnection Language)。
由于程序设计语言和模块内连接语言具有严格的语义基础,因此他们能支持对较大的软件单元进行描述,诸如定义/使用和扇入/扇出等操作。
MIL方式对模块化的程序设计和分段编译等程序设计与开发技术确实发挥了很大的作用。
但是由于这些语言处理和描述的软件设计开发层次过于依赖程序设计语言,因此限制了他们处理和描述比程序设计语言元素更为抽象的高层次软件体系结构元素的能力
简要介绍UML中的视图以及它们之间的关系
标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。
第二类是静态图 (Static diagram),包括类图、对象图和包图。
其中类图描述系统中类的静态结构。
不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。
类图描述的是一种静态关系,在系统的整个生命周期都是有效的。
对象图是类图的实例,几乎使用与类图完全相同的标识。
他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。
一个对象图是类图的一个实例。
由于对象存在生命周期,因此对象图只能在系统某一时间段存在。
包由包或类组成,表示包与包之间的关系。
包图用于描述系统的分层结构。
第三类是行为图(Behavior diagram),描述系统的动态模型和组成对象间的交互关系。
其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。
通常,状态图是对类图的补充。
在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。
而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。
第四类是交互图(Interactive diagram),描述对象间的交互关系。
其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。
除显示信息交换外,合作图还显示对象以及它们之间的关系。
如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。
这两种图合称为交互图。
第五类是实现图 ( Implementation diagram )。
其中构件图描述代码部件的物理结构及各部件之间的依赖关系。
一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。
它包含逻辑类或实现类的有关信息。
部件图有助于分析和理解部件之间的相互影响程度。
配置图定义系统中软硬件的物理体系结构。
它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。
在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。
从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。
其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。
其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。
它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。
因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。
软件体系结构设计的目录
第一篇基础篇:软件体系结构的理论 第1章绪论1.1软件体系结构的概念演化1.1.1软件体系结构的定义1.1.2软件体系结构的理论基础1.2软件体系结构形式化方法概述1.2.1基于CHAM的体系结构形式规约1.2.2基于Z语言的体系结构形式规约1.2.3基于一阶逻辑的体系结构形式规约1.2.4基于图论的体系结构形式规约1.2.5目前形式化方法存在的问题1.3软件体系结构描述语言概述1.4软件质量与质量模型 思考题 第2章软件建模的基础2.1一个简单例子2.2面向对象特性2.2.1封装性2.2.2继承性2.2.3多态性2.3接口2.4设计原则2.4.1SRP单一职责原则2.4.2OCP开闭原则2.4.3LSP里氏替换原则2.4.4ISP接口分离原则2.4.5DIP依赖倒置原则2.5UML2的各种图2.6需求建模:用例2.6.1一个用例图例子2.6.2用例与参与者2.6.3用例图2.6.4用例间关系2.6.5用例对需求建模2.7基本结构建模2.7.1一个类图例子2.7.2性质2.7.3对象图2.7.4操作2.7.5接口2.7.6关系2.7.7关系建模2.7.8类图2.8高级结构建模2.8.1公共扩展机制2.8.2包和包图2.8.3复合结构2.8.4模板2.9Kruchten4+1模型描述软件体系结构2.9.1逻辑视图:面向对象的分解2.9.2过程视图:过程分解2.9.3开发视图:子系统分解2.9.4物理视图:从软件到硬件的映射2.9.5场景视图:汇总2.9.6视图间的交流2.9.7模型的迭代过程和软件文档 思考题 第3章软件体系结构的形式化3.1软件的生命周期3.2基于抽象代数的形式化方法3.2.1构件3.2.2连接件3.2.3软件体系结构3.2.4软件体系结构关系3.2.5软件体系结构范式3.3基于粒度计算的形式化方法3.3.1软件体系结构演化3.3.2属性合成和跟踪3.3.3软件体系结构多视图表达及集成3.3.4软件体系结构风格和软件体系结构风格发现3.4*基于π演算的形式化方法3.4.1π演算基本语法3.4.2π演算约简关系3.4.3π演算迁移关系3.5*动态软件体系结构的形式化描述:化学抽象机3.5.1化学抽象机模型3.5.2软件体系结构描述 思考题 第4章软件体系结构的风格4.1管道和过滤器风格4.2仓库风格和黑板风格4.3事件驱动风格4.4客户机?分配器?服务器风格4.5分层系统风格4.6解释器4.7面向服务的体系结构4.7.1面向服务体系结构中的组成元素4.7.2面向服务体系结构的设计原则4.8过程控制环路模式 思考题 第5章体系结构描述语言5.1典型ADL5.1.1C2概述5.1.2Darwin与Wright概述5.1.3ACME概述5.1.4UniCon概述5.1.5Aesop概述5.1.6Rapide概述5.1.7MetaH5.1.8SADL概述5.2πADL的概述5.2.1πADL体系结构描述框架5.2.2πADL体系结构风格描述方法5.3πADL体系结构行为规约 思考题 第6章软件质量建模方法6.1软件质量建模与分析6.1.1风险分析的基本概念6.1.2风险分析的基本方法6.1.3图形化建模语言6.2实证分析:软件体系结构的质量6.2.1地面智能机器人的软件系统6.2.2解决方案1:过程控制环路模式6.2.3解决方案2:分层架构模式6.2.4解决方案3:基于事件驱动的隐式调用模式6.2.5解决方案4:黑板体系模式6.2.6解决方案比较 思考题 第7章设计模式7.1设计模式概述7.2设计模式的分类7.3创建型的设计模式7.3.1Factory7.3.2Prototype7.3.3Builder7.3.4Singleton7.3.5Adapter 思考题 第8章战场环境中自适应服务的软件组合框架8.1服务的描述与特征8.1.1服务模型8.1.2服务事务处理8.2TSCF服务组合框架8.2.1TSCF框架8.2.2服务代理设计8.2.3服务组合协调8.3服务调度流程控制的应用实现8.4小结 思考题 第二篇软件复用与构件库的设计 第9章构件库研究现状 第10章软件复用概述 第11章构件技术 第12章Web构件库实现 第三篇软件规模的度量 第13章软件规模度量研究现状 第14章FPA方法 第15章FPA方法的实际应用及其不足 第16章FPA方法的改进 第17章改进后FPA方法的应用及实例试验 第四篇软件的性能抗衰 第18章软件的性能问题与抗衰技术18.1软件性能衰退 第19章新型软件抗衰策略 第20章细粒度软件抗衰策略研究 第21章细粒度重启技术研究 第22章细粒度软件抗衰策略模型研究 附录A缩略词及中英文词汇对照附录B软件体系结构支持工具参考文献 ……
软件体系结构的研究范畴有哪些?请举例加以说明!
软件体系结构的形式化方法研究软件体系结构研究如果仅仅停留在非形式化的框图阶段,已经难以适应进一步发展的需要。
为支持基于体系结构的开发,需要有形式化建模符号、体系结构说明的分析与开发工具。
从软件体系结构研究的现状来看,在这一领域近来已经有不少进展,其中比较有代表性的是美国卡耐基梅隆大学(Carnegie Mellon University)的Robert J.A11en于l997年提出的Wright系统。
Wright是-种结构描述语言,该语言基于一种形式化的、抽象的系统模型,为描述和分析软件体系结构和结构化方法提供了一种实用的工具。
Wright主要侧重于描述系统的软件构件和连接的结构、配置和方法。
它使用显式的、独立的连接模型来作为交互的方式,这使得该系统可以用逻辑谓词符号系统,而不依赖特定的系统实例来描述系统的抽象行为。
该系统还可以通过一组静态检查来判断系统结构规格说明的一致性和完整性。
从这些特性的分析来说,Wright系统的确适用于对大型系统的描述和分析。
软件体系结构的建模研究研究软件体系结构的首要问题是如何表示软件体系结构,即如何对软件体系结构建模。
根据建模的侧重点的不同,可以将软件体系结构的模型分为5种:结构模型、框架模型、动态模型、过程模型和功能模型。
在这5个模型中,最常用的是结构模型和动态模型。
(1)结构模型这是一个最直观、最普遍的建模方法。
这种方法以体系结构的构件、连接件和其他概念来刻画结构,并力图通过结构来反映系统的重要语义内容,包括系统的配置、约束、隐含的假设条件、风格、性质。
研究结构模型的核心是体系结构描述语言。
管道/过滤器风格的体系结构(2)框架模型框架模型与结构模型类似,但它不太侧重描述结构的细节而更侧重于整体的结构。
框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
(3)动态模型动态模型是对结构或框架模型的补充,研究系统的"大颗粒"的行为性质。
例如,描述系统的重新配置或演化。
动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。
这类系统常是激励型的。
(4)过程模型过程模型研究构造系统的步骤和过程。
因而结构是遵循某些过程脚本的结果。
(5)功能模型该模型认为体系结构是由一组功能构件按层次组成,下层向上层提供服务。
它可以看作是一种特殊的框架模型。
这5种模型各有所长,也许将5种模型有机地统一在一起,形成一个完整的模型来刻画软件体系结构更合适。
例如,Kruchten在1995年提出了一个"4+1"的视角模型。
"4+1"模型从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角来描述软件体系结构。
每一个视角只关心系统的一个侧面,5个视角结合在一起才能够反映系统的软件体系结构的全部内容。
"4+1"模型如图1所示。
图1 "4+1"模型发展基于体系结构的软件开发模型软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架,给出了软件开发活动各阶段之间的关系。
目前,常见的软件开发模型大致可分为三种类型:(1)以软件需求完全确定为前提的瀑布模型。
(2)在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型,如螺旋模型等。
(3)以形式化开发方法为基础的变换模型。
所有开发方法都是要解决需求与实现之间的差距。
但是,这三种类型的软件开发模型都存在这样或那样的缺陷,不能很好地支持基于软件体系结构的开发过程。
因此,研究人员在发展基于体系结构的软件开发模型方面做了一定的工作。
例如,为了形象地表示体系结构的生命周期,北京邮电大学的周莹新博士建立了一个软件体系结构的生命周期模型,该模型如图2所示。
数据抽象和面向对象风格的体系结构图2 软件体系结构的生命周期模型软件产品线体系结构的研究软件体系结构的开发是大型软件系统开发的关键环节。
体系结构在软件生产线的开发中具有至关重要的作用,在这种开发生产中,基于同一个软件体系结构,可以创建具有不同功能的多个系统。
在软件产品族之间共享体系结构和一组可重用的构件,可以增加软件工程和降低开发和维护成本。
一个产品线代表着一组具有公共的系统需求集的软件系统,它们都是根据基本的用户需求对标准的产品线构架进行定制,将可重用构件与系统独有的部分集成而得到的。
采用软件生产线式模式进行软件生产,将产生巨型编程企业。
但目前生产的软件产品族大部分是处于同一领域的。
什么是uml
1. 标准建模语言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开始致力于这一工作。
他们首先将Booch9 3和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、Micr osoft、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代表了面向对象方法的软件开发技术的发展方向,具有巨大的市场前景,也具有重大的经济价值和国防价值。
2. 标准建模语言UML的内容 首先,UML融合了Booch、OMT和OOSE方法中的基本概念,而且这些基本概念与其他面向对象技术中的基本概念大多相同,因而,UML必然成为这些方法以及其他方法的使用者乐于采用的一种简单一致的建模语言;其次,UML不仅仅是上述方法的简单汇合,而是在这些方法的基础上广泛征求意见,集众家之长,几经修改而完成的,UML扩展了现有方法的应用范围;第三,UML是标准的建模语言,而不是标准的开发过程。
尽管UML的应用必然以系统的开发过程为背景,但由于不同的组织和不同的应用领域,需要采取不同的开发过程。
作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分。
(1) UML语义 描述基于UML的精确元模型定义。
元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。
此外UML还支持对元模型的扩展定义。
(2) UML表示法 定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标...
UML体系结构的5种视图中,系统用户最关注的是那种视图?
UML 类图简介 UML 对很多人来说应该不是一个陌生的概念,这一两年来,UML 被大家越来越多的讨论着。
本来 UML 跟我这个主题似乎并不能扯上多大的关系(它是语言无关的,甚至可以说其本身就是一种语言——用于交流的)。
我在此谈到它有两个目的: 1. UML 是针对面向对象软件开发的,而 C++正是这样的一种语言 2. UML 在设计中被越来越多的使用着,而下一篇杂谈准备讨论设计模式,如果不了解 UML,那么无法进行下去 UML,全称:Unified Modeling Language,其目的是为了对软件密集型的制品进行可视化、详述、构造和文档化的图形语言。
UML 是依据许多前人的思想总结出的成果,1997 年被 OMG 通过并成为标准(所以在《设计模式》书中如果你看到与标准不一样的地方,不要奇怪,那本书是 95 年的)。
关于 UML 的历史和更详细的描述,可以参考《UML 参考手册》。
UML 主要由一系列视图组成,其中包括静态视图(Static vi ew),用例视图(Use case view)活动视图(Acti vity view)等,不同的图用处自然也不一样,而对开发人员来讲(或者说为我的下一篇来说),更重要的应该是静态视图中的类图(class diagram)和交互视图(Interaction view)中的顺序图(Sequence diagram),请注意 view 和 diagram 的区别。
类图 静态视图说明了对象的结构,其中最常用的就是类图,类图可以帮助我们更直观的了解一个系统的体系结构,有时侯,描述系统快照的对象图(Object diagram)也是很有用的。
在这里,我们主要介绍类图,下面的图就是一个简单的类图: 在类图中,类由矩形框来表示,如上图中,定义了 4 个类,分别为 Base、A、B、 C,类之间的关系通过各种线条和其他符号来表示,在上图中,空心的三角表示继承关系,在 UML 的术语中,这种关系被称为泛化(Generalization),所以上面的类用等价代码表示为: class Base{…}; class A:public Base{…}; class B:public Base{…}; class C:public Base{…}; 我们再看下一幅图: 这幅图与上幅几乎没有什么区别,唯一的不同就是 Base 类中增加了成员,一个私有的 integer _x(UML 术语为 property)和一个公有的 fun()的函数(method),是否需要这些类的内部细节 UML 本身并没有限制,完全取决于你自己如何使用, UML 的用处在于帮助你了解系统,所以只要你自己觉得足够清楚,那么够了,不要再复杂了。
接着看第三幅图: 上面图中的箭头表示一种关系,箭头另一边有一个菱形(空心)表示聚合(aggregation),聚合的意义表示 has-a 关系,其等价代码如下: class A{…}; class B{ A* theA;…}; 聚合是一种相对松散的关系,聚合类 B 不需要对被聚合的类 A 负责。
下面的图: 这幅图与上面的唯一区别是菱形为实心的,它代表了一种更为坚固的关系——组合(composition)。
组合表示的关系也是 has-a,不过在这里,A 的生命期受 B 控制,通常情况,等价代码如下: class A{…}; class B{A theA;…}; 即 A 会随着 B 的创建而创建,随 B 的消亡而消亡。
下图: 这里 B 与 A 的关系只是一种依赖关系,这种关系表明,如果类 A 被修改,那么类 B 会受到影响,一个简单的例子就是: class A{…}; class B{fun(A params);…}; 常用的关系就是我们上面用的这些,通过这些关系和类表示的类图,我们可以用图形化的方式描述一个系统的设计部分,当你习惯使用 UML 后,你会发现,这往往比你告诉同伴某某类从某某类派生,派生类又和某某类具有什么关系容易的多。
顺序图: UML 中另外一个常用的图形就是交互视图中的顺序图,在以往的过程化语言中,我们通常使用流程图来描述一个函数(系统)是如何工作的,而在面向对象的系统中,这显然是不可行的,而顺序图正是来解决这个问题的。
假设有如下的伪代码: class circle { public: void fillcolor() { // ... }; void draw() { fillcolor(); }; }; class window { public: void drawcircle() { _circle.draw(); }; private: circle _circle; }; 对于下面的调用: window wnd; wnd.drawcircle(); 对应的顺序图如下: 图中上方的方块表示参与的对象,垂直的虚线表示对象的生命线,方框表示激活,其中箭头表示了一个调用消息(也可以有回送 return),如果是异步的消息,则用半箭头表示,其中 draw 表示了一个自调用(self call) 至此,UML 中最常用的(从开发人员的角度),当然 UML 的内容远远不只这些,这里的介绍只是一些简单的概括,并且 UML 本身也在不断的发展之中,无论怎样,我觉得 UML 会越来越多的深入我们的开发过程中,特别是对下一篇我们要介绍的设计模式而言,类图是主要的描述工具(到那个时候你会体会到 UML 描述的优越)。
如果你看过《设计模式》着本书,你会发现与我上面所描述的有一些细微的不同,不要紧张,《设计模式》是 GOF95 年的作品,那时候 UML 还没有形成,而且,其中也明确那是 OMT 方法(Jim Rumbaugh 在通用电气发表的建模技术——Object Modeling Technique)和 Booch 方法。
UML是什么啊
UML介绍 什么是UML? 关键词:uml 面向对象的分析与设计(OOA&D)方法的发展在80年代末至90年代中出现了一个高潮,UML是这个高潮的产物。
它不仅统一了Booch、Rumbaugh和Jacobson的表示方法,而且对其作了进一步的发展,并最终统一为大众所接受的标准建模语言。
1. 标准建模语言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代表了面向对象方法的软件开发技术的发展方向,具有巨大的市场前景,也具有重大的经济价值和国防价值。
2. 标准建模语言UML的内容 首先,UML融合了Booch、OMT和OOSE方法中的基本概念,而且这些基本概念与其他面向对象技术中的基本概念大多相同,因而,UML必然成为这些方法以及其他方法的使用者乐于采用的一种简单一致的建模语言;其次,UML不仅仅是上述方法的简单汇合,而是在这些方法的基础上广泛征求意见,集众家之长,几经修改而完成的,UML扩展了现有方法的应用范围;第三,UML是标准的建模语言,而不是标准的开发过程。
尽管UML的应用必然以系统的开发过程为背景,但由于不同的组织和不同的应用领域,需要采取不同的开发过程。
作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分。
(1) UML语义 描述基于UML的精确元模型定义。
元模型为UML的所有元素在...
转载请注明出处51数据库 » uml作为软件体系结构描述语言的形式和方