统一建模语言UML支持环境

（本文转载自软件工程专家网www.21cmm.com）

标准建模语言UML定义良好、易于表达、功能强大,不仅支持面向对象的分析与设计,而且支持从需求分析开始的软件开发的全过程。但如何恰当地将这种可视化图形建模技术用于解决软件开发所面临的问题,如何研制和开发支持UML的建模过程及其支持环境,仍是目前该领域的热点问题。

目前,在基于UML的开发方法和环境方面,国际上已经进行了一些研究和实际开发工作。Rational 公司正致力于它称之为Objectory过程的研究,并试图将其原有支持OMT的工具作进一步扩充,以期支持UML建模。国内对UML支持环境的研制开发工作尚处于起步阶段。

这里从当前对软件开发过程的需求及其动向出发,提出了UML柔性软件开发过程的概念,并设计了相应的UML集成化支持环境的组成框架。

1. 过程工程的基本要点

任何语言的支持环境都是为了更好地开发计算机应用系统,而任何计算机应用系统又都是为一定的企事业的目标服务的。因此计算机应用系统及其支持环境的研制与开发,必须在企事业过程工程理论的指导下进行。下面根据我们近十年来从事过程工程理论研究与正反两方面的实际经验,扼要介绍过程工程理论和过程工程环境的基本要点。

(1) 任何企事业都可以也都应该从过程、资源、机构、行为和信息等五方面来描述。其中过程是指该企事业所进行的活动及其活动间的关系,它有一个包含规划、设计、建造和应用等四个阶段呈螺旋特征的生命周期。刻划一个企事业模型,首先必须研究这五个方面模型的定量描述技术及其相互关系的约束理论,并研究其描述技术及约束理论在四个不同阶段中的演变情况,建立系统动力学模型,为采用模拟技术解决上述五个方面模型的综合集成与整体优化奠定理论基础。

(2) 任何企事业中的过程都可划分为纵向过程与横向过程两类。纵向过程是以产品工程技术为核心的逐步发展的硬技术群,横向过程是以产品和过程的管理技术为主体的服务于纵向过程的软技术群。因此要刻划一个企事业过程,还必须研究纵向过程与横向过程的定性模型与定量度量技术,研究这两类过程的相互关系,以建立产品开发和管理过程相结合的集成化综合模型,为采用模拟技术研究硬技术群与软技术群的相互之间的量化关系奠定理论基础。

(3)瞬息万变的信息化社会中,由于客观环境(系统的外部参数)和主观实体(系统的内部结构及状态)均具有动态的性质,系统模型的结构、状态及其计算机支持环境也应随之而变化。为此,要研究面向对象技术在过程工程中的应用技术,把软件工程、过程工程和企事业工程结合起来,为建立自适应的过程工程支持环境奠定理论基础。我们不妨把软件工程、过程工程、企事业工程三者结合起来进行综合考察的工程技术称之为聚合工程,把自适应的计算机支持环境称之为柔性信息系统。

(4) 过程的规模可大可小,过程的持续时间可长可短。因此要研究既能支持过程的横向划块(将过程规模较大的系统划分成若干个规模较小的子系统)、又能支持过程的纵向分段(将持续时间较长的过程划分成几个持续时间较短的子过程)的分割与综合技术,研究资源的动态调度技术以及模型的局部实例化与局部模拟技术,为采用模拟技术研究大范围、长周期的复杂动力学系统奠定技术基础。

由以上理论可知,任何语言的支持环境必须满足这些基本的技术设施,这就是我们研制与开发标准建模语言UML支持环境的基本出发点。在这些基本点中,特别值得注意的是前三条,即聚合工程和柔性信息系统的概念。

2. UML柔性软件开发过程及其支持环境

(1) UML柔性软件开发过程

软件系统的规模越来越大,复杂程度不断提高,传统的软件开发模式越来越难以满足需求。新的产品开发周期已不再是从需求定义、软件设计、实现和交付的一次性过程,迭代式增量开发方式已得到了广泛采用。除了传统概念上的时间、质量和花费三个主要要求外,产品支持系统的"柔性"成为更加重要的核心需求。因此我们将新的软件开发模式归结为图4所示的迭代式开发和图5所示的柔性软件开发模型。

所谓柔性软件开发是指软件开发过程应在需求工程的牵引下,首先建立系统的顶层模型,并对其进行模拟、分析和调整。次之,将顶层模型自顶向下地进行分解,建立该系统各个子系统的模型,对这些子模型进行模拟、分析和调整。然后将子模型的模拟结果,逐次代入上层,再对该上层模型进一步进行模拟、分析和调整,如有不适,则进行修改。因此整个建模过程是一个"自顶向下建模,由底向上修改"的反复迭代的过程。简言之,柔性软件开发过程是一个在需求牵引下,自顶向下分层细化地建模,然后按照"T型技术",通过对模型的虚拟执行,由底向上地逐层上移修改,直至各层的模拟结果都满足需求为止。

代码的生成建立在模型正确性的基础上,同时考虑到对需求修改的灵活性和快速响应能力,实施能够反馈修改的"闭环开发"。即不仅能支持从模型到代码的自动生成,将新的模型转换为代码,还能支持从代码到模型的逆向变换,将原有的代码转化成模型,进行再次分析、修改和调整以及新一轮的开发,从而为增量式开发提供支持。这样不仅能做到分阶段提交产品,也提高了对用户需求变化的响应速度和应变能力,以满足用户不断变化的新的需求。

(2) UML支持环境的基本需求

根据上述理论以及我们十五年来研制与开发集成化软件工程环境正反两方面的经验,一个完善的集成化过程工程环境在功能上应满足以下基本需求:

·应能支持开发完备的过程模型(即应能从过程、资源、机构、行为和信息等五个侧面来描述企事业过程)与系统模型(即应能从过程、行为、信息和结构等四个侧面来描述一个系统)。

·在这个环境支持下建立的模型应是一个可执行的过程(系统)模型,即应能支持模型的虚拟执行(模拟)和实际运作,从而可在不同的层次上对模型进行分析和优化。

·过程(系统)模型应采用可视化的图符与正文描述相结合的表达方式,其可视化模型图的结构应能客观、自然地反映出企事业各部门间的通信和同步关系。

·应能支持建模人员或管理人员按照企事业(系统)内外部的约束条件对模型的执行进行灵活的控制,从而实现开发过程与管理过程的交叉。

·应能支持从模型自动生成可在Internet上运行且支持多平台共享与多数据库存取的应用系统,从而实现对第三代过程工程自动化的有力支持。

·还应能支持对各类构件库的灵活管理,支持基于构件的程序设计方法,实现过程构件、需求描述、系统结构与软件构件的复用和组装。

UML集成化支持环境应对集成化过程工程环境和集成化系统工程环境提供强有力的技术支持。一方面在功能与接口上三者必须无缝连接,另一方面在风格上三者必须协调一致。在分工上,过程工程环境的目标是优化过程,系统工程环境的目标是自动产生优化了的计算机应用系统,UML支持环境的目标是为建成柔性的计算机应用系统提供技术支持。

3. UML集成化支持环境

UML集成化支持环境是在需求牵引下支持建造柔性信息系统的系统开发环境,其组成应包括UML可视化建模系统、模拟系统、代码生成系统、逆向变换系统、质量控制系统及其支持软件等。这些环境均应基于UML的语法规则和语义定义,如图1所示。由此可知,这个支持环境是一个能支持系统建模、系统模拟和系统生成的"闭环式开发"的集成化支持环境。

(1) UML可视化建模系统的框架

UML可视化建模系统支持从系统需求、系统分析到系统设计的整个建模过程,提供UM L图形的编辑和美化工具,保证得到语法正确、语义完整的UML图形模型,并提供包括文档管理和图形打印等辅助支持。

支持环境的建模机制

由于UML不仅支持对系统的对象建模,还支持对需求和系统体系结构的建模,不仅支持建立系统的静态模型,还支持描述系统的动态模型,因此,模型建造系统应支持以下模型的创建和编辑:

需求模型包括静态模型和动态模型。静态模型即功能模型,在UML中通过用例图描述系统功能和各功能的潜在用户及它们之间的关系。动态模型通过活动图支持对业务过程或事务处理过程的描述。

系统对象模型包括静态模型和动态模型。通过包图、类图和对象图定义系统对象及对象间的静态关系;通过顺序图、合作图和状态图描述对象间的交互关系、对象的生命周期以及生命周期中对象可能存在的状态和状态间的转换约束。

系统体系结构模型通过组件图和配置图支持软件体系结构和硬件体系结构以及通信机制的定义。同时,还应进一步支持软硬件系统之间的合作关系的可视化表示。

建模系统的检测机制

UML语法正确性检测机制为保证所得到的UML图形模型符合其语法定义,应提供语法正确性检测机制。一个较好的方法是提供语法制导的UML可视化建模工具,在模型的建造过程中提供动态的语法制导和语法检测功能。这样,既可方便用户学习和使用,也可保证所建造的模型在语法结构上的正确性。

UML模型的一致性检查机制由于UML支持从需求分析到系统设计整个建模过程,并且支持用户从不同的角度描述系统,而大型软件项目各模型间的协作和约束关系错综复杂,显然不应由用户独自承担对它们的管理和维护工作。作为建模支持系统,应提供模型间的一致性检查机制。

首先,该机制应根据以上对基于UML软件开发模型的讨论,在软件开发阶段时间轴上确定引入模型的时间;其次,明确同一种模型的细化分层机制,以及怎样用其他模型描述主模型的细节;第三,在软件开发阶段时间轴上,一个模型存在自顶向下分解的层次结构,在各时间阶段产生的层次结构中,各种UML模型相互约束、协作又产生复杂的网状关系,需要建立不同阶段、不同功能的同一种模型与不同种模型约束和协作的数学模型;最后,在该数学模型的基础上,研究将约束和协作关系有机地加入软件开发各个阶段的模型一致性检查机制。此外,由于允许从不同的角度描述同一模型,如交互图包括顺序图和合作图,这两者之间允许存在冗余信息,因此,不仅应保证两者间信息的一致性,还可考虑支持模型间的一致性转换。

UML模型的完备性检查机制完备性检查机制须在UML语义定义的基础上,首先定义UML图形模型的完备性准则,以保证UML图形模型的完备性。UML图形模型的完备性可分三个层次来考虑,即:各个图形的完备性;各个子模型的完备性,也就是相关图形的组合完备性;系统模型的整体完备性。区分这三种完备性的意义在于:在不同阶段可以进行语义完备性和语义正确性检查。

文档生成和管理工具文档生成工具是指文档自动生成机制。作为一个建模支持系统,应支持包括需求描述、面向对象分析和设计、系统体系结构等文档资料的自动生成。文档管理工具是指文档资料的版本管理等辅助管理工作。

(2) UML模拟系统

系统模拟机制支持对UML模型的功能模拟和性能模拟,它包括以下三个部分:

动态模型的模拟主要包括对活动模型、交互模型(顺序图和合作图)以及状态图的模拟。根据预先定义的语义,模拟各个模型对系统在时间特性上的描述是否真实地反映了客观现实和用户需求,并应提供相应的跟踪调试机制。

系统功能(需求)和用户界面的模拟借助于代码自动生成工具和用户界面自动生成工具的支持,产生系统原型,并尽早提供给用户,以确保建模的有效性。

系统性能的模拟作为一个良好的建模和开发支持工具,以支持对系统体系结构的建模,即在不同系统配置和功能分配的情况下,对系统性能进行模拟,以便得到优化的系统设计方案和合理的系统配置。

(3) UML代码生成系统

UML集成化支持环境应能支持可视化对象和行为的代码生成。UML代码生成系统也称之为UML支持环境的正向变换系统。众所周知,软件开发的最终目的是产生可执行代码。在大多数软件开发环境中,建模和编码过程缺少有机的统一,这是有其历史原因的。其中最重要的原因是缺少功能强大、简单清楚、标准统一的建模语言。UML的出现以及被OMG接受为标准,为消除这个障碍提供了一个很好的起点。

在UML语言的代码生成机制方面,国际上一些大公司做了有益的研究和开发工作,比较有代表性的是Rational公司和Advanced Software Technologies Inc.。但这些研究和实现大多限于UML静态模型中的类图,其他有关模型代码自动生成机制的研究资料则非常罕见。

我们认为,代码自动生成机制应根据UML语言多种模型动态协作、关系复杂的特点,首先界定UML的语义和面向对象编程语言(首先是Java)的语义,研究专用语义机制描述面向对象模型和语言中动态与静态机制,建立两者的语义模型。然后,再在该语义模型下建立两者的映射模型,并研究代码自动生成实现技术和独立于UML语言本身的编程语言的特殊机制。代码自动生成机制在研究与实现时,还应考虑后面逆向转换机制的需求。

(4) UML软件质量控制

软件系统的质量往往是大型、复杂系统成败的关键。软件系统质量难以保证的主要原因首先是软件系统固有的复杂性。但人们往往对这一点尚未有足够的认识,而把软件系统的复杂程度看得过低。另外一个原因是由于软件系统及其管理工作固有的不可见性。采用定量软件工程有利于改善可见性,但是还不可能做到完全透明。因此,在当代软件技术水平的前提下,建造软件质量控制环境势在必行。学术界与工业界对软件质量工程的看法主要划分为两个流派,一个叫"产品足够优质"(Good-Enough),另一个?quot;无差错软件"( Error-Free)。

在建造软件质量控制环境时,除了应建造通用软件过程管理环境(包括软件项目管理、软件配置管理和软件质量管理)、软件过程支持环境(以支持软件开发单位成熟度模型CMM、个体软件过程PSP和支持群组软件过程TSP的实现)外,还应包含相互联系但可分别独立使用的三个子环境:

集成化软件测试环境这个环境应包括软件需求覆盖测试工具、源程序覆盖测试工具、软件回归测试工具、软件测试管理工具和内存负载检测工具等。

集成化软件质量度量环境度量有关软件质量的原始数据,并据此来计算ISO软件度量标准中所需要的管理度量元。

软件产品质量综合评测系统从上述诸方面因素对软件产品的质量进行综合考虑,把所得到的数据进行加权综合。只有满足整体要求的软件才被认为是一个合格的软件产品。

(5) UML逆向变换系统

当用户对生成的代码进行修改后,逆向转换机制将用户的修改转换到模型上。否则,将造成模型和代码间的不一致性,使系统的扩充、增删和维护难以进行。

我们认为,如果一个支持环境既有正向变换机制,又有逆向变换机制,就能保持模型和代码的一致性。动态模型的逆向转换机制是研究难点,一般可由建模、析取和抽象三个步骤组成。我们将在正向转换的基础上,建立起模型到代码的映射关系,尝试建立一套约束机制,实现自动的或人工导引的逆向转换机制。目前,国际上对这方面的研究尚不成熟。