用MOF构建一个软件开发系统
jimconrad(译)
2004-10-17
虽然MOF模型是一种强大的建模语言，能够表达许多种类的信息模型，但是它并不企图终结建模语言。相反，我们想把MOF用于设计和实现更复杂的建模系统。下面这个例子将围绕一个假设的UDL建模语言，说明如何用MOF构建一个软件开发系统。
UDL和OA&DF草案的UML建议之间有很多相似的地方，在其中UML是作为可视化设计和开发组件软件的通用建模语言。UDL可以被当作是对UML中许多概念的扩展，或改进的一种语言。这种扩展主要表现在它更充分更详细，以完成各种实现的框架技术和定义额外的元层模型，其中元层模型涉及多种技术领域，如数据库管理，事务处理等等。
基于UDL的软件开发系统的开发人员先会使用MOF Model的符号定义UDL的元模型。为了方便，UDL元模型会重用部分或全部MOF Model，不知道这是不是一个好的主意（MOF元模型有些非普适的特殊需求，举例来说：为自动化IDL生成而做的模型简化和支持等。因而期望用MOF元模型做所有类型的对象建模是不合理的。）。然后开发人员会使用一个简单的基于MOF的开发系统（按上几行描述的）为一个UDL仓库将UDL元模型转换为CORBA IDL，并提供相应的手写或生成的软件，实现UDL仓库和合适的UDL模型输入工具。（UDL仓库包括UDL元模型、UDL模型仓库及UDL仓库接口）
这个假设的UDL开发系统不能不考虑以下方面：为创建实现UDL模型所描述系统的可工作代码的过程提供某些层次的支持。依赖于UDL的性质，这个过程可能包括几个步骤，在这些步骤中概念设计被转换为更多的具体设计，并且最后成为程序源代码。一个UDL开发系统可能提供一系列工具辅助目标系统的设计者和程序员。这些工具需要被仓库功能（函数、操作）支持，以存储特殊的设计和实现信息，连同版本历史信息、项目时间表信息等等一起，从而构成了一个成熟软件的开发过程。
在实践中，实现上述几行的软件开发系统可能很难遇到市场需要。一个典型的软件工程“商店”可能在软件工程技术和过程两方面都有需求，但世间没有“放四海皆准”的开发系统。目前软件开发系统的趋势是倾向于通用仓库系统；即需要很高灵活性的系统，能够被飞快的剪裁和扩展。
基于MOF的通用仓库系统将基于MOF Model的核心和一套用于开发目标元模型（如UDL）的工具及它们的支持工具。通用仓库中的许多工具可以是支持反射的；即这些工具可能使用更高层的元层次的信息使它们能够跨模型类别执行操作。其功能，如持久化，复制功能，版本控制，和访问控制将需要在不同实体仓库框架上被统一支持。
英文原文（自MOF规范）：
While the MOF model is a powerful modeling language for expressing a range of
information models, it is not intended to be the ultimate modeling language. Instead,
one intended use of the MOF is as a tool for designing and implementing more
sophisticated modeling systems. The following example illustrates how the MOF might
be used to construct a software development system centered around a hypothetical
“Universal Design Language” (UDL).
Many parallels can be drawn between the hypothetical UDL discussed below and the
draft OA&DF UML proposal in that UML is designed to be a general purpose
modeling language for visualizing, designing, and developing component software.
The UDL can be thought of as an extension, as well as a refinement, of many of the
concepts in the UML. The extensions are mainly in the area of providing sufficient
detail to complete the implementation framework technologies and defining additional
meta models that address various technology domains such as database management,
transaction processing, etc.
The developer of a software development system based on UDL might start by using a
MOF Model notation to define a meta-model for UDL. Conceivably, the UDL
metamodel could reuse part or all of the MOF Model, though this is not necessarily a
good idea(The MOF meta-model has specific requirements (e.g., model simplicity and support for
automatic IDL generation) that are not generally applicable. As a consequence, it is unreasonable
to expect the MOF metamodel design to be suitable for all kinds of object modeling.).
The developer could then use a simple MOF-based development system
(along the lines described above) to translate the UDL metamodel into CORBA IDL
for a UDL repository, and to provide hand-written or generated software that
implements the UDL repository and suitable UDL model input tools.
The hypothetical UDL development system cannot be considered complete without
some level of support for the process of creating working code that implements
systems described by the UDL models. Depending on the nature of the UDL, this
process might involve a number of steps in which the conceptual design is transformed
into more concrete designs and, finally, into program source code. A UDL
development system might provide a range of tools to assist the target system designer
or programmer. These tools would need to be supported by repository functions to
store extra design and implementation information, along with information such as
version histories, project schedules, and so on, that form the basis of a mature software
development process.
In practice, a software development system implemented along these lines would have
difficulty meeting the needs of the marketplace. A typical software engineering "shop"
will have requirements on both the technical and the process aspects of software
engineering that cannot be met by a “one-size-fits-all” development system. The
current trend in software development systems is for Universal Repository systems;
that is, for highly flexible systems that can be tailored and extended on the fly.
A MOF-based universal repository system would be based around the core of the MOF
Model, and a suite of tools for developing target metamodels (for example, the UDL)
and their supporting tools. Many of the tools in the universal repository could be
reflective; that is, the tools could make use of information from higher meta-levels to
allow them to operate across a range of model types. Functionality, such as persistence,
replication, version control, and access control would need to be supported uniformly
across the entire repository framework.
