The Unified ModelingLanguage
UML是一种通用建模语言，它开发于90年代早期，由Grady Booch, JamesRumbaugh和Ivar Jacobson合并成一个统一的图形表示法。第一次标准化在1997年，经过了多次修订，最近正在开发第二个版本，这个版本已经接近完成。
UML是庞大且难于理解的，版本2更是如此，要向深入的理解UML必须先理解它怎样被使用。我们借用Martin Flower在《UML Distilled》一书中分类，Marting把UML的使用分为:用作草图，用作Blueprint，用作程序语言。
把UML当作草图使用非常流行，很多项目都在白板上使用UML画草图。把UML作为草图使用的另一个含义是把试图从面向对象设计中生成结构化的文档被看作是不妥当的。在这种情况下，UML是非常成功的，它完全达到了消除了面向对象设计和图解表示的不一致问题的目的。
把UML作为Blueprint使用提升了门槛，这时的目标是在开发过程中把多种UML模型结合起来。对于任何改动和自动化，都向系统地将UML模型转换到源代码，这也就意味这UML模型必须包含足够的信息，才能保证转换是有效且完整的。
当我们尝试这样作的时候，会很快发现UML的问题，因为它不能很直接的转换到我们所使用的技术，例如：一个UML类不能直接用来描述一个C#类，因为UML类并不能描述C#中的属性的概念。类似的，一个UML接口不能直接用来描述一个Java接口，因为UML不包括Java中的静态字段的概念。从这一点来看，把UML作为草图使用时，没有任何问题，但是，当UML被用作开发一个类的制品时，要么违反标准，要么引入一些不和谐因素来修补这些不匹配的问题。
将UML作为程序语言由一些社区支持，但是他们不喜欢走到商业化的路上，在这里我们不作讨论。
让我们再来观察这些UML的主要使用方法：作为草图和Blueprint。把标准表述为一组灵活的，可扩展的图释，并无缝地映射到开发所使用的技术，而且不存在任何不匹配的描述说明，这是非常有用的。只有从模型所表述的概念进行无缝且可逆的映射才会被大多数开发者所接收。“UML轮廓”采用允许有限度的对语言扩展来使蓝图具有可扩展性。但是实践证明这种可扩展性是非常有限的，并且还不能提供无缝的从UML到时下流行技术的映射。
在微软，我们的途径是通过我们的建模工具，使用一些易识别的扩展的表示法来表示概念。同时，我们发现UML表示法还不够清晰，我们对其进行了增补，例如：我们使.NET的类可视化，可以包含更多信息，更容易使用，而且使得图释的元素更精确。这保证了.NET中的术语和概念能够在图释中清晰地表达。我们从客户那里得到的反馈是压倒性的支持这种作法。尽管我们的图释法不是标准的UML，但是它所表达的含义对任何人而言都是非常容易理解的。
在UML所不针对的领域，我们必须创建新的约定，例如：设计器支持开发逻辑数据中心模型，这些模型被用来部署分布式系统，在这里我们可以使用UML中所不支持或支持很少的概念，而且我们可以对这些领域创建一个规约。领域定义语言被用来开发UML所不支持的新领域，我们可以期望将这些规约合并到这些领域中。
我们可能会发现在对UML2.0作过大量的扩展后可能会导致一门建模语言的产生，SDL（Specification and Description Language，定义和解释语言），广泛用于通讯技术领域。我们期待看到在那些UML还没有涉及到的领域的关于UML的图释约定和扩展的远景。
Defining Languages andInterchanging Models
在OMG的MDA旗帜下还有另一个重要的技术：MOF。MOF是一个比UML更加抽象和难以理解的技术。理解了这个还有更难理解的术语，象metamodel（元模型）和meta-metamodel（元－元模型），感谢还没有出现meta-meta-meta-model，我们也会尽力阻止出现。
MOF主要作两个工作。第一，它是一个被设计成定义建模语言的领域定义建模语言：一个MOF模型是一个MDA建模语言的定义。第二，它是一种计算一个MDA模型如何被序列化到一个XML文档或Java API的机制。
一个领域的建模语言包含很多方面，它必须定义领域中的概念，必须把概念表示为图形或文本，必须定义用户如何与语言交互，必须定义一个模型是否合法，必须定义模型间如何交互。但是MOF仅仅定义了语言的基本概念，以及概念的模型如何存储和交互。一种语言的MOF说明并没有提供多少用户真正关心的东西：语言所包含的模型是什么，它看起来象什么，用户如何和模型交互。
在微软，我们希望我们的语言能够整合到Visual Studio包括IntelliSense?，工具栏，菜单，属性栏，和对Debug的支持，我们发现定义如何对概念建模在整个工作中只是一个次要的方面，而且我们的语言定义工具要整合到Visual Studio中要比MOF好。
事实上，尽管这是语言定义技术的通常的地位，MOF仍然是一个存储概念模型，并且使用XMI（XML Metadata Interchange）在模型和CORBA和Java API之间转换的主要技术。如果使用MOF来定义一种语言的概念，接下来就可以使用XMI的方法来进行对语言的基于XML的自动生成。
从这个方面看，这似乎是挺吸引人的，但是，还是有一些问题。首先，XML的生成基于语言的定义，这也就意味着使用UML1.4标准进行的XMI序列化将无法被基于UML2.0的实现所理解，除非用户在这些概念的观点能够保持前后一致。再者，XMI本身就在变化，也就是说可能会出现对与同一个模型的不同XMI序列化版本。第三，MOF的定义也在变化，它会为了对付不同的组合而不断加入新的元素，这将导致MOF的版本具有不同的取向，而且无法完全一致。所以，虽然XMI宣称为建模工具提供互操作性，但是实际情况是，除非每个工具都能够支持MOF，XMI，UML标准下的所有可能的组合，工具之间的交互才是没问题的。XMI的更深层次问题是，特别是对于旧版本，由机器生成的XML架构常常冗长且难以阅读，这就迫使开发者们去寻求可视化程度更高的，可转换的技术来维护XML文档。
我们不认为XMI对于模型的序列化来说是正确的方法。XML正在变的成熟，市场上有大量的模式和工具。我们认为正确的方法是，对特定的建模语言有他自己特定的XML架构，并且提供工具来管理语言和序列化格式间如何自动解释和映射。如果对一个特定领域进行标准化，XML架构就可以是标准的，这是业界广泛存在的观点。之后，如果语言的定义发展了，可以在旧的XML架构上扩充，进行移植。XMI有效地阻止了这个清晰的思路发展，并导致了大量不兼容的XML架构标准，和它的互操作的目的完全背离了。
简而言之，微软不支持MOF是因为下面的原因：
1. 它还不是个稳定的标准
2. 使用它来作为设计我们的工具的语言会产生我们不愿看到的结果。
3. 支持MOF所没有提供的元素需要商业级的实现，我们会继续引入MOF定义的改动。
4. MOF没有实现自己的目标。
结论
本文讨论了模型在软件开发中的角色，特别是domain-specific languages的定义和使用，以及在产品线中的使用，同时对OMG的MDA作了总体的评价。我们确信在敏捷软件开发过程中模型会得到更多的使用，我们正在构筑工具和技术来支持这些开发。我们看到UML作为重要的一步，它的未来是基于图释的开发者间的约定，而且可以作为面向特定问题领域的领域定义语言的灵感。也看到XML是模型的表现和交互的关键技术，我们期望对领域内容的标准化能尽早开始。
文章来源于领测软件测试网 https://www.ltesting.net/
