UML是一种图形化的语言，用于明确规定和构建软件系统开发过程中形成的产品，使这些产品可视化并形成文档资料。UML代表了在模拟大型和复杂的系统中被证明是最成功的工程实践的一个集成。自从1997年11月UML1.1的提案被OMG组织采纳之后UML已经变成软件开发过程中实际存在的标准模型语言。全世界有许多机构都已经接受了UML，这些机构将通过各种方式继续鼓励UML的使用，比如说采用已经成型的定义，激励其他的方法学家、工具经销商、培训机构和作者们使用UML。 不同的模型图被使用在软件开发的各个阶段中，并且它们抽象的程度也不同。比如，Use Case图和类图用于静态分析，序列图和活动图用于动态分析，组件图和调度图用于代码实现。 正是在如此多重的观点下，软件开发人员可以将一个软件设计分解为易于控制的较小规模的组件。但也正是在如此多重的观点下，各种有争议的问题也不可避免地产生了： 1．协调性问题：各种观点下的模型在语法和语义上应该是相容的。 2．转换和进化问题：一个模型必须与它的精化在语义上是协调的。 3．可跟踪问题：在某个观点下的模型中的一个变化应该可以导致其余观点下的模型的协调性变化。 4．融合性问题：不同观点下的模型应该在软件成品之前被无痕的融合在一起。 为了精确和精巧地处理以上问题，一个形式化的语义模型无疑是最好的选择。UML的非形式的语义被精巧地设计得具有灵活性和可延展性以便UML可被使用在不同的目的，比如需求分析、系统设计、代码实现和测试。通常UML模型的形式化方法归于两大类。一类是转化方法：在这类方法中，某种UML模型被转化成已经存在的形式化语言，比如Z、B、VDM等等。另一类方法是直接给出UML模型的形式化的语义模型，然后提供一个连接机制将这些模型组合在一起做协调性检查。 现在已经存在的形式化地支持基于UML开发的大多数工作，主要致力于单个图的形式化并且仅仅处理一种观点或两种观点下的模型的协调性。在UML的形式化使用的研究中另一种现象是，不同的组织意欲强调不同的符号系统并且使用全部的甚至是扩展的UML序列图或状态机的表达力。这无疑失去了UML在多重观点下建模的优势，同时也导致了某类UML模型复杂性的增加和削弱了其它的UML模型应起的作用。据我们所知，几乎没有关于UML完整模型的协调性精化方面的工作。这里一个系统的完整模型是指这个系统在不同观点下的一簇模型。 这篇论文正是朝着UML的语义模型这个方向进行的。在第一章中，我们复述了这个工作的基础-指称语义。在第二章中，我们直接给出UML模型的语义模型，然后将这些模型连结起来此做协调性检查。但我们没有提供生成类Java代码的方法，因此这种技术不适应当前面向对象的方法这个主流。为了避免这个缺陷，在第三章和第四章中，我们把UML模型转化到面向对象的描述性语言rCOS的规范形式。rCOS这种语言被设计来广泛地用于面向对象的系统的开发。在第三章中，在类图和序列图的形式化的基础上，我们构建了需求模型和设计模型。在四章中，我们将状态机添加到我们的模型中并且指出一个系统的模型由一个类图、一簇序列图和一簇状态机构成。这个模型主要用于模型融合、精化和代码实理。因此这个工作在计算机科学和软件工程领域都有理论意义和实用价值。更重要的是，rCOS的精化计算将被用来定义UML模型的协调性精化，而精化过程则保留系统的协调性和正确性。这