织梦CMS - 轻松建站从此开始!

罗索

统一的模型语言UML消灭对象建模的差别

罗索客 发布于 2002-11-05 16:10 点击:次 
北京航空航天学院计算机科学与工程系 麦中凡 李庆如 此文分三次连载在1998年4月13日、4月20日、4月27日国际电子报上。主要介绍了UML的技术背景、UML产生的技术背景、主要思想、应用特征和对OO(面向对象)设计业界的意义。文章虽然对Rational公司的背景谈的不多,对Rati
TAG:

北京航空航天学院计算机科学与工程系 麦中凡 李庆如

 

      此文分三次连载在1998年4月13日、4月20日、4月27日国际电子报上。主要介绍了UML的技术背景、UML产生的技术背景、主要思想、应用特征和对OO(面向对象)设计业界的意义。文章虽然对Rational公司的背景谈的不多,对Rational的三位面向对象大师Grady Booch、Jim Rumbaugh和Ivar Jacobson也以寥寥几句带过,但却着重指出是“Rational把UML带到一起,完成了工业标准语言的目标”。

 

一、引言

      去年一月Rational软件公司的三位学者,Grady Booch、 Jim Rumbaugh 和Ivar Jacobson经过三年多的努力正式提出面向对象系统的通用的统一模型语言UML (Unified Modeling Language)1.0版,并提交美国面向对象(OO)行业的OMG组审核。这是OO行业中一件具有里程碑性质的新进展。

      众所周知面向对象技术自80年代初问世以来。由于它的模块性、封装性、继承性、多态性和动态束定能满足软件工程要求的局部化、易维护、可重用、易扩充以及当今多媒体和分布式计算的诸多要求,一时成为计算机各项领域争相采用的新技术焦点。整个80年代到90年代中期,面向对象成为业界有口皆碑的技术。因为面向对象对它的专业有好处,人人都采用面向对象,但是每个人心中的面向对象不完全一样,致使面向对象数据库不能像关系数据库那样快地普及。软件可重用构件虽然可节约大量软件开发费用,但不是所有环境都可用。同一成分,即使是支持编程的类库,各语言系统也都不一致。

     美国OO业界深深地理解到不统一对象模型,很难求得基于面向对象技术的产业发展。90年代初由30几位对OO有兴趣的厂商和学者组成了对象管理小组OMG,试图统一对象标准。

      UML语言的出现是为建立统一的面向对象开发方法。它是在已有的三大OO方法学的基础上,抽象出表示它们的模型语言,并吸取了其它OO开发方法和近30年软件工程的成果。它立足于实用,尽管目前还只能由资深的高级程序员、分析员、研究者使用。但它对OO技术的发展有着深远的影响,这是毫无疑问的。读者可参阅网上的资www.rational.com 及EdisonWesley公司出版的有关Rational UML系列书籍。

 

二、UML产生的技术背景

      如何开发OO软件,人们也是有过弯路的。从不用作对象分析、对象俯拾即是到Booch的早期工作:用自然语言陈述一个解,名词是候选对象,动词是方法的候选,形容词可归为属性,副词列为条件。其开发步骤是:确定对象、配齐属性、分析对象间关系、编码实现方法。但这种凑对象的方法不能体现。1988年到1992年是面向对象方法学蓬勃发展的时期,人们从各自的经历和软件开发的经验提出了各种面向对象的开发方法,代表的有: Sally Shlaer 和 Steve Mellor以信息模型化方法作为基础,并为目标系统增设了状态模型和过程模型; Peter Coad 和 Ed Yourdon则在信息模型化、面向对象的程序设计语言和基于知识的系统的基础上,建立了他们的OOA、OOD,主要工具是类与对象图、对象状态图和服务图Wirfs-Brock的职责驱动设计(Responsibility-Driven Design),也称类-职责-协作Class-Responsibility-Collaboration (CRC) cards,用类所承担的责任来描述系统,采用责任把封装的概念带到分析与设计活动中去; Grady Booch在Rational软件公司开发Ada系统作了许多构件(Component),并以此由底向上构筑大型软件系统,即OOD方法; Jim Rumbaugh在通用电子(General Electric)领导一个研究小组,提出了对象建模技术(OMT)方法,通过面向对象的三种模型:对象模型、动态模型和功能模型,从不同角度对系统进行描述; 所有这些方法都不外乎经过分析抽象出对象,建立对象之间的关系。只是每一种方法都有其应用背景和侧重点,它们按照各自的表示法系统,被介绍到学术刊物或市场。经过几年实践,相对市场占有率较大的是:OMT,Booch 和OOSE。OMT在分析方面较强,设计领域较弱。Booch''91则在设计领域较强,分析领域较弱。Jacobson有很强的行为能力,适合于实时系统但其它方面较弱。九十年代中期,为使自己的方法学更全面地支持OO软件开发,新的重复开始出现。最突出的是Booch93,采用了许多Rumbaugh和Jacobson等人提倡的分析技术。Rumbaugh出版了一系列文章,也就是OMT-2,采用了许多Booch好的设计技术。这些方法开始交叠,但它们仍沿用各自的表示法系统。众多不同的表示法的使用带来了市场的混乱。例如,一个实心圆在OMT是多态的标识,在Booch则是聚集的符号。

      1994年任职于Rational公司的Grady Booch首先联合Jim Rumbaugh加盟Rational软件公司开始了统一OO方法学和工具的历程。以融合Booch和OMT方法的UML开发开始。1995年10月UML0.8发布。1995年秋,Ivar Jacobson和他的 Objectory 公司加盟Rational,UML中加入了OOSE方法,使其有可能最集中地包容当今最适用的各种OO方法。成为OO业界众望所归的大举措。

      Booch、Rumbaugh和 Jacobson努力的结果是 UML0.9、0.91分别在1996年7月和10月发布。其目标是及早向业界发布UML1.0正式版本。

      1996年,几家公司将UML作为他们的商业战略。 Rational 与愿意共同努力完成UML1.0定义的公司,建立了UML 加盟者协会。1997年1月,它们的合作产生了UML 1.0。这些关于模型交互的方法标准建议主要集中在元模型和可选择的表示法上。1997年9月再次修订后为UML1.1。并被批准成为面向对象开发的行业标准语言。

      可见,UML的创建也是一个迭代和增量的过程,非常类似于模型大型软件系统。

      Rational 把UML带到一起,完成了工业标准语言的目标。(第十三期(4月13日): 电脑时空版)

 

三、UML的主要思想

      UML是面向对象开发中一种通用的、统一的、图形模型语言,是近代软件工程环境上对象分析和设计的重要工具。它是建立在现代抽象模型理论上的表示法体系结构,用户籍UML提供的视见元素构件可以设计、表达出复杂的面向对象软件的体系结构。 从模型元素到视见元素表示的映射是建立在域分析和方法学的基础上。UML模型元素的扩充机制支持域分析。UML采用面向对象机制表达其本身的语法和语义,统一的表示法体系可以支持何基于OO的方法学,以下分述之:

1、UML的元模型理论

      模型规定了对象的属性、操作以及聚集、结合和通信。利用表示法系统对它表达的层次叫模型层。

      一个系统往往是由多个模型的聚集、相互结合和通信组成。我们需要一种手段构成各个模型。为此把属性、操作、结合、通信进一步抽象为结构元素、行为元素来表达模型,并提供表达系统的机制(包),这一层称为元(Meta)模型层。为了准确地表达模型的语义,提供分类(型版)、说明(标记值)和约束。在这样的元模型描述下生成的模型实例,语义可以得到准确的刻画。

       那么元模型体系结构的表示法又是什么呢?为了准确定义元模型的元素和各种机制,元-元模型提供的最基本的概念和机制指出,每个元类中有元属性(MeteAttribute)和元操作(MetaOperation),最基本的机制是类-实例化机制,即元模型是元-元模型的实例。UML表示法的最上层其实就是元-元模型层。按照莫比乌斯怪圈理论,元-元模型是自定义的,相当于编译的自编译。为了和OMG组的元对象设施(Meta Object Facility简称MOF)提供的元-元模型一致。UML的元模型体系结构直接从MOF的元模型生成。UML是元模型层的描述语言,它的实例兼及模型层,并可以直接对应OO语言中的类、类型、消息、继承、聚集、概括、接口。而元模型层次上有丰富的语义表达机制。四层模型的理论充分吸收了通用数据交换格式CDIF(CASEData Interchange Format)研究成果,CDIF是美国电子协会EIA为软件开发各不同阶段间数据交换提出的行业规范。

2、 大型逻辑包装

      一个软件系统,由不同模型的系统组成。每个模型由模型元素按照某种组合机制构成。UML从表示角度上用无语义但有结构关系的包把相关元素封装在一起。包有包容(子包)和继承关系(新包可以继承所有指名旧包的描述)。系统和模型均按包的形式提供,即一个包可以封装一个模型,若干子包聚集为一系统包。用户可以在系统提供的包的基础上定义自己的系统和各模型(以包的形式)。UML提供的包是基础(Foundation)包、行为元素(Behavioral Element)包和模型管理(Model Management)包。基础(Foundation)包描述一个软件系统提供的最基本支持;行为元素(Behavioral Element)包为模型元素定义各种动作、通讯,管理其使用情况、状态描述等等;模型管理(Model Management)包定义了模型元素如何组织成模型、包和子系统。

3、 元模型的静态语义的形式化

      用户借助UML提供的表示法定义自己系统的元模型,特别是以(图形的)视见元素表示模型元素时,其语义解释不够准确。UML提供形式化语言OCL(对象约束语言)以一阶谓词逻辑模型描述各种约束。

      实际上UML继承了软件工程中形式化规格说明语言研究的成果。因为只有形式规格说明描述的软件体系结构在其各开发阶段中才能保证语义的一致性。可惜形式语言约束只能准确刻划静态语义。对于动态语义除了加上OCL描述外,还必须以自然语言加以说明,完全形式化是极为复杂的。UML在给出自身的语义说明时运用了这个办法,对于每个包都给出三个层次的说明:1) 抽象的语法(Abstract syntax):由一个UML类图给出各元类之间的关系。2) 良构的规则(Well-formedness rules):用形式语言OCL表达无边界效应的约束。3) 语义(Semantics):用自然语言描述引入的新概念和动态语义。

      总的来说,UML元模型是由图形表示法、自然语言和形式语言组成的描述。设计者意识到用元模型自己表述元模型是有理论限制的。这种合成强调表述性和易读性间的平衡。?(第十四期(4月20日): 电脑时空版)

 

四、使用UML开发应用系统

      UML为对象的结构模型和行为模型定义了语义。结构模型(静态模型)强调在一个系统中对象的结构,包括它们的类、接口、属性、和关系。行为模型(动态模型)强调系统中对象的行为,包括它们的方法、交互作用、协作性和状态历史。UML为所有模型表示法提供了完整的语义。

      模型和视图的选择对问题怎样入手和怎样计划相应的解决方案有很大的影响。对每个复杂系统理解的最好的方法是通过一系列几乎独立的模型视图去描述。每一个模型可以在不同真实度上描述。最好的模型是与现实相连的。UML表示法是UML语义的可视化表示,是用来模型系统的工具。UML定义了八种类型的图表示各种模型的各个方面。

      UML的表示法是模型的图形化表示,是模型语言的格式。例如,类图表示法定义了诸如类,聚集和多态如何表示。这些图通常是一些非形式的定义。无论你采用哪种方法学,最后以UML求精了的图形表示加上形式约束,它就是该系统精确的模型。在某种意义上说来方法学就是导出各种模型图或从一种图导出另一种图的办法。你所使用的模型语言是否严格,这取决于你使用的目的。如果你用CASE工具产生代码,就必须用CASE工具翻译模型语言来得到合适的代码。如果你用图来通讯,就可以有一些误差。

      软件开发一大挑战是构建正确的系统,一个在合理的消费上满足用户需求的系统。我们有我们的术语,用户有自己的,我们和用户之间需要通讯。按照充分了解用户世界的方式,完成好通讯是开发好软件的关键。一个使用情况是系统的一次快照。所有使用情况的总和是系统的外部照片,解释系统将要做什么。使用情况的集合是了解你的用户需求的核心,也是表示项目计划的一个好的媒介。它可控制迭代开发,本身就是一个有价值的技术反馈,告诉用户软件进行到那里。以概念的角度来使用类图更有价值,也就是把每个类作为用户意识或语言中的一个概念。你所画出的类图并不是数据或类,而是你的用户的语言图。活动图在工作流过程中很有用,这正是用户世界的重要的一部分。活动图支持并行处理,它们能帮助用户从不必要的顺序中脱离出来。

      UML提供的表示法是早已出现的OO方法学表示法的精化,UML将它们连贯成一体。例如使用情况图与OOSE中的类似;类图是OMT、Booch和大多数其它方法类图的融合;状态图是基于David Harel的状态图上作了小的修改;行为图类似工作流图;顺序图与一些方法中的交互、信息TRACE和事件TRACE类似;协作图来自Booch的对象图和Fusion的对象交互图等;实现图来自Booch的模块和过程图。总之,它是计算机科学和软件工程长期思想的产物。

 

五、总结

      概括一下,UML作者提出的开发过程是使用情况驱动、体系结构中心和过程迭代。系统的开发由使用情况驱动,将需求化为使用情况。反复选择实现最重要的使用情况,将使用情况的职责(responsibilities)分配到类(classes)上。用使用情况测试可执行系统。将使用情况和工作步骤一起考虑。以体系结构为中心,来处理全局问题。系统分解为子系统,各子系统之间有共享机制和相应的连接性,并有各自的独立灵活性。体系结构来自于顶层使用情况和内部结构(根据以往经验,型式)。体系结构必须在内部结构与功能性间作权衡。将开发工作分成较小的迭代序列:每次迭代都增加功能;每次迭代都减少风险,尽早地注意风险在技术上的成因;每次迭代都落实到可执行系统,可清晰地度量进展情况,从用户每次都取得反馈,开发者突出频繁的同步化;每次迭代时要将工作分解为详细的功能表,向前看一次迭代。■

(第十五期(4月27日): 电脑时空版) (麦中凡)
本站文章除注明转载外,均为本站原创或编译欢迎任何形式的转载,但请务必注明出处,尊重他人劳动,同学习共成长。转载请注明:文章转载自:罗索实验室 [http://www.rosoo.net/a/200211/1024.html]
本文出处: 作者:麦中凡
顶一下
(1)
100%
踩一下
(0)
0%
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片
栏目列表
将本文分享到微信
织梦二维码生成器
推荐内容