四、标准建模语言UML支持环境

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

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

 1. UML柔性软件开发过程

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

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

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

2. UML集成化支持环境

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

(1) UML可视化建模系统的框架
    UML可视化建模系统支持从系统需求、系统分析到系统设计的整个建模过程,提供UML图形的编辑和美化工具,保证得到语法正确、语义完整的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),另一个叫"无差错软件"( Error-Free)。
    在建造软件质量控制环境时,除了应建造通用软件过程管理环境(包括软件项目管理、软件配置管理和软件质量管理)、软件过程支持环境(以支持软件开发单位成熟度模型CMM、个体软件过程PSP和支持群组软件过程TSP的实现)外,还应包含相互联系但可分别独立使用的三个子环境:

集成化软件测试环境　这个环境应包括软件需求覆盖测试工具、源程序覆盖测试工具、软件回归测试工具、软件测试管理工具和内存负载检测工具等。
集成化软件质量度量环境　度量有关软件质量的原始数据,并据此来计算ISO软件度量标准中所需要的管理度量元。
软件产品质量综合评测系统　从上述诸方面因素对软件产品的质量进行综合考虑,把所得到的数据进行加权综合。只有满足整体要求的软件才被认为是一个合格的软件产品。

(5) UML逆向变换系统
    当用户对生成的代码进行修改后,逆向转换机制将用户的修改转换到模型上。否则,将造成模型和代码间的不一致性,使系统的扩充、增删和维护难以进行。
    如果一个支持环境既有正向变换机制,又有逆向变换机制,就能保持模型和代码的一致性。动态模型的逆向转换机制是研究难点,一般可由建模、析取和抽象三个步骤组成。