简介
模型是 Rational Unified Process 中一种重要的工作产品,(在 RUP 中)通常以工具无关和环境无关的方式使用统一建模语言(UML)表示,以便在许多环境中用许多工具集部署和规定 RUP。支持材料:可视建模探索建模的部分原因,包括:
-
辅助理解复杂系统
-
探索和比较低成本的设计备选方案作为实施的基础
-
精确捕获需求
-
明确传达决策
模型被视作推断系统行为(期望的和已实现的)和结构的方法,并向感兴趣的项目干系人传达这些考虑的结果。MDD 和 MDA
强调了模型作为实施的基础元素的作用,期望它们不仅用作开发人员编写代码所依据的蓝图,而且它们根据支持工具集的功能,自身达到一定的可规定或可执行程度。从很久以前开始,这就遵循一个趋势,即开发人员工作的抽象程度不断提高。这将焦点从代码(如我们所知)转移到用更高级的(可能为图形化的)语言表示的模型。RUP
通过将某些工件确定为模型,而不是包含模型图片的文档(例如,捕获需求和设计)来隐式支持这种可能性。
视点和视图
视点正如它的名称所示,是概念上的位置,从这里可看到有关系统(或表示系统的那组模型)某些方面或关注点,这意味着应用一组概念和规则来形成概念上的过滤器。术语“透视图”用法类似,它描述查看和理解模型的方法,该方法最适用于不同项目干系人的许多不同的定位和关注点。
视图是模型的投影,它从特定的视点或视角展现相关的实体。
在 MDD
中,视点和视图用于分离问题,从而(例如)在独立于物理结构和流程结构的情况下处理逻辑结构。模型越接近问题域,视点或透视图与项目干系人的业务问题越匹配;因为开发的模型越接近可执行形式,就会涉及越多的计算问题。在任一种情况下,目标不仅仅是产生被动的解释,而是产生某些模型,这些模型至少潜在地可生成满足这些单独问题的实施。
精化和转换
这些术语通常非正式地用于区分手动进行的模型变更(精化)和工具进行的模型变更(转换)。在 RUP 中,精化具有相当不同的正式含义 - 它是生命周期阶段的名称 - 但在本节中,我们将它非正式地用于解释明显不同的模型发展方法。
其中的另一层含义是转换和精化过程中的演进步长不同 - 即模型是分成若干细小步骤演进,直到模型足够详细可用工具或手动生成代码(包括语言、基础结构或操作系统详细信息)。手动方式意味着人可以参照模型编写 Java、C++
或其他语言,并可能在流程中进一步精化。相反,在转换方式中,模型仍然保持一定的抽象度,不涉及任何语言、基础结构或操作系统,它被转换为某种可执行并产生期望结果的实体,但本身很少甚至没有做进一步的精化。请注意,期望结果包括性能和其他非功能特征。因此,这种方法暗示着可通过构造模型的方式以及模型描述资源需求的方式来处理此类交叉型体系结构。
另一个词术语定义:转换,已普遍用于描述通过遵循一组规则并按照一组参数工作而从源模型生成目标模型的流程。 请注意,这里使用术语“模型”的方式与 RUP
相同,因此,目标模型可以是实施元素,例如代码或文本。当然,转换可以手动进行,这使连续转换(增加细节)等价于精化,并且规则可以很复杂并建立在对可用技术和领域的深入体验上。不过,按缺省的用意,转换是自动进行的,在 Model Driven
Architecture® 的下一节再次检查。
请注意,转换的概念只涉及源模型和目标模型。通常的情况是目标模型没有源模型抽象,即目标在某种程度上比源更具体,但这并不隐含在转换观念中。请注意,转换也可以向模型添加详细信息,产生进一步优化的目标模型,同时大致维持相同的抽象程度,因为并未引入关于其他领域的信息。将此与从
UML 模型产生代码的转换相对照,引入此目标模型的多数转换不涉及业务项目干系人 - 只要保持所需的行为和非功能特征。
实现转换想法的能力依赖于工具功能以及整理、获取和重复使用有经验的人员所用知识的能力。必须获取和整理的知识量取决于进行转换步骤时随依据的抽象程度 - 通常情况下,抽象程度越高,知识就越多,领域的依赖性也越强。
在 MDD
中,我们努力提高可自动生成操作系统的抽象程度。模型被精化,直至达到可用于生成它物的程度。然后,最好不要为执行而进一步精化输出。而且,我们的目标是在可能的情况下,通过连续的自动转换作出前述的精化。因此,两种方法都集中于:通过连续的转换步骤,尽可能实现转换的自动化。执行系统的最后一次转换时,模型描述仍然处于较高的抽象度;技术、基础结构和目标语言选择以代码形式编入转换引擎中,并且向该引擎提供规则和数据。
MDD 的其他好处是希望能够通过整理由专家在相应领域创建的平台、领域知识和最佳实践,来重复使用转换。这样,我们推动由较少技能的开发人员即可实施的重复使用,并避免在每个新的应用程序中都必须从头开始重新创建。
什么是高度抽象?
有几种方法来查看这一点。一个是沿着一系列语言查看,例如查看可执行 UML 形式的出现情况。另一种是从领域设计的角度,其中语言和建模概念可专用于该领域。例如,UML 是通用语言,因此,沿这个方面查看术语定义:UML 概要文件的使用来使 UML 的使用专门化。还有一种方法是一种认识到的需要,即避免特定于供应商、特定于基础结构的模型,以便保持对新技术开放。
从详细的动态情况的表达上来说,在 UML 操作语义上进行的工作使
UML 的可执行形式成为了可能,但具体的语法和表示法尚未标准化并且操作语义的级别类似于其他 OO 语言。因而,UML 加上操作语义可能不是最终的答案,但它指明了事情发展的方向。
我们断定用 UML 表示或使用 UML 概要文件的模型(不包含依赖于供应商的元素)不依赖于特定基础结构平台(如 J2EE 或 Microsoft®
.NET),并且在结构和行为中语义完整,而没有借助于特定过程语言(Java、C#...),按此定义该模型是高度抽象的,虽然操作语义级别的问题仍然存在。
从问题域的角度,即从用户或业务客户的角度来看,可能并有吸引力的解决方案是明确表达特定于领域的建模语言。这些语言是抽象的,即用特定领域中的工作人员所熟悉的术语和概念来表达,还有完整的能力来表达模型动态情况,同时仍是基于 UML 的。
这如何与 RUP 相关?
RUP 分析、设计和实施模型的关系说明了这些观念:分析模型代表如何实现用例中表述的行为的早期观点;它在要处理的问题域上自然会有描述上的偏差,并且它包含的分析类被视作所需职责和行为的概念性分组。分析模型通常不足以完整到可执行(除了可能在阅读模型并弥补差距的人员的思索试验中),因为有太多内容未作陈述。
相反,分析模型必须完成优化(提高详细程度和精确程度)的流程,得出设计模型。
RUP 允许项目维护单独的分析模型或将分析模型视作发展成设计模型的模型。改进流程在 RUP
任务中有一定程度的描述,缺省解释为扮演软件设计人员和设计人员角色的人员将完成此演进,并可能借助相当多的工具帮助。请注意,该改进可以看作是一系列模型转换,其中的一些转换可能自动执行,例如,当应用 RUP 任务体系结构分析和确定设计机制中的术语定义:分析模式和术语定义:设计模式时。
设计模型何时完整?
设计模型在项目整个期限中通过几个迭代发展;因此,设计模型(或设计模型的某个部分)何时能够变成代码,即何时可以开始产生实施元素并将它们集成到系统的感兴趣工作版本中呢?RUP
提供了关于从设计映射到代码的一些指导,但是从根本上并没有固定不变的答案。当(例如通过复审)您判断自己有能力时,您即转向实施,并且该时刻在组织和项目之间可有很大的变动。RUP
提供多种方法从设计继续进行到代码,这里讨论其中两种来解释如何做出设计完整性的决定:
1. 草图和代码
RUP 宣称:“一种常见的设计方法是相当抽象地勾画出设计,然后直接转向代码。设计模型的维护是手动的。”
要使用此方法取得成功需要开发人员能够跨越设计级别和实施级别之间的抽象差距将两者衔接起来。通常设计模型的维护是次要问题,而代码成为关注点!
2. 单演进设计模型往返工程(RTE)
RUP 宣称:“在此方法中,只有一个设计模型。最初拟定的设计元素演变为可与代码同步。”
这里,开发人员使用一系列建模步骤填补了抽象差距。此方法与“草图和代码”之间的差别在于中间步骤是明了的并且最后设计模型的抽象版本消失了。
在两种情况下,抽象设计模型的潜在价值都丧失了:在“草图和代码”中,是因为通常不维护抽象设计模型,并且随着时间的过去,失去了与代码的联系;而在“一个不断发展的设计模型”中,则是因为抽象版本消失了。即使保留了初始版本,它通常也会遭遇“草图和代码”设计模型同样的命运。请注意,使用
RTE 的设计模型的终点是真正代码可视化的,并且使用适当的工具,可从在草图和代码产生的代码反向设计出类似的可视化。 在 RUP
中,通过在软件体系结构文档中,在关键点上捕获重要的体系结构视图和设计理由,可在某种程度上减少抽象设计模型的损失。
MDD
有望抽象设计模型将成为代码生成的基础并长期存在。它成为维护的主要基础,并且实际上可能是维护的唯一基础。它也提供设计终点的明确定义,即终点是这样一个点:只要涉及转换引擎,模型就是完整、一致和明确的并能够变成可执行的系统。模型的抽象程度取决于可用的技术和工具集(例如,请参阅 导览:Rational Software Architect
概览),还可能依赖于领域。请注意,就 MDD 而言,这只是另一个转换(设计到代码),但却是跳过几个抽象程度的重要转换。
下一节描述 MDD 的新兴框架标准,是对象管理组(OMG)发起的活动,称为 Model Driven Architecture®(MDA®)。
Model Driven Architecture(MDA)
动机
MDA 是 OMG 活动,OMG 是有大约 800 名成员的行业联盟,任务是建立标准指南和规范,为应用程序开发提供共同的供应商中立框架并鼓励跨主要硬件和软件基础结构平台的互操作性。统一建模语言就是 OMG 的产品。目前,OMG 将 MDA
提升为旗舰规范,并且顾及 OMG 作为实践标准(计划受到业界 IC、做法、产品和工具的支持)的传播者的身份,同时注意到 UML 的成功,MDA 是值得研究的。在 OMG 的 Web 站点上有大量关于 MDA 的信息,包括最新的 MDA 指南[OMG03]。也有一些可获取的书籍,如[FRA03]、[KLE03] 和[MEL04] 以及很多文章,如“An MDA Manifesto”(作者:Grady Booch、Alan Brown、Sridhar Iyengar、James
Rumbaugh 和 Bran Selic,出处:The MDA Journal,2004 年 5 月)。
MDA的核心思想
MDA 简介了一些特定概念和术语,这些概念和术语使 MDA 不同于 MDD 的更普遍的方法;在以下各节中将定义和讨论这些概念和术语。
在已有的标准上创建
MDA 是由现有 OMG 标准支持的,包括:
-
元对象工具(MOF)- 除了定义元模型构造的语言(例如,UML 和 CWM),MOF 还定义实施模型和元模型的存储库的框架,从而当使用 MDA 时可使用一致的方法操纵这些模型。因此,MOF 是
MDA 的基本技术。
-
统一建模语言(UML)- 其中定义了 PIM、PM 和 PSM 的 UML 是 MDA 的基础表示法。
-
XML 元数据交换(XMI)- XMI 定义了基于 XML 的 UML 模型交换格式。
-
公共仓库元模型(CWM) - 因为 UML 用于应用程序建模,因此 CWM 用于数据建模。
平台无关性
术语定义:平台的直观概念是:通过提供具有一组隐藏实施细节的定义良好的接口的服务,来支持更高的体系结构层。平台的 OMG 定义(在 MDA 指南中)是:
“一组子系统/技术,它们通过接口和指定的用途模式提供一组连贯的功能,依赖于平台的任何子系统可以使用这些功能,而不必考虑平台所提供的功能如何实施的细节问题。”
这类似于 RUP 中使用的术语定义:层的概念。
平台无关性的观念有些含糊:它是模型的一种性质或特征,例如,当模型未引用平台提供的服务或功能时,可以说它是独立于特定平台的。但是,该陈述是相对而言的,因为很难设想出绝对的平台无关性形式。MDA
指南承认了这一点,同时也确认了关于特定平台的平台无关性程度的可能性,例如,在特定平台中模型使用普遍形式的特性。
平台无关性的实现受益于平台(如 J2EE、.NET 和 WebSphere)的发展,程度达到在暴露给应用程序的内容上不断提高的抽象程度。这使平台中立的构造的确定更易跟踪,并使转换它们的、特定于平台的转换更简单、更易编写。
平台无关模型(PIM)
它遵循以下说法,即当模型不一定要使用该平台并可使用同类型的任何平台时,我们说模型是关于特定平台的 PIM。在前面一节中,我们讨论了高度抽象的观念,并得出结论如果用 UML(或使用 UML
概要文件)表示的模型不包含依赖于供应商的元素、不依赖于特定基础结构平台,并且在结构和行为中语义是完整的,而不求助于特定过程语言,那么该模型至少在概念上是可执行的,并且高度抽象。这样一个模型独立于平台吗?是,也不是。对于可能的假想的 UML
虚拟机不是,而对于这样一个虚拟机依赖的一整类平台则是。
平台模型
平台模型是应用程序使用特定平台所需的一组概念(代表部件和服务)、规范、接口定义、约束定义以及任何其他需求。在 MDA 中,平台模型被以 UML 等加以详述和正式化,并且在兼容 MOF 的存储库中向外提供。例如,可为 J2EE 或 .NET
等构建平台模型。
平台相关模型(PSM)
通过添加使其特定于某个或某些平台的信息,将 PIM 转换成一个或多个 PSM。PIM 和 PSM 仍指定同一个系统,但 PSM 被限制使用特定技术并可能包含某些特定于平台的元素。请注意,没有涉及转换步骤(PIM 到 PSM
或到它的关联平台)的大小。包含一小组模式的应用程序的转换优化该模型并在某种意义上使其更特定;这强调了术语 PIM 和 PSM 的相对性。
视点和视图
这些术语以对 MDD 所述的同样方式用于 MDA:
-
视点正如它的名称所暗示,是概念上的位置,系统的某些方面或问题从该位置变得可见,意味着应用一组概念和规则来形成概念上的过滤器。鉴于某些关于系统的信息被抑制,它是一种抽象形式。术语透视图的用法类似。
-
从视点中,可以查看视图,视图是模型的投影,显示该视点的相关实体。
MDA 指定了系统的三个视点:独立于计算的视点、独立于平台的视点和特定于平台的视点。
计算无关视点
从独立于计算的视点,您关注系统的环境、系统必须在此下操作的需求和约束以及环境中必须与之交互的因素。从此视点,看不到系统结构或行为的详细信息。
计算无关模型(CIM)从独立于计算的视点来看的系统或即将形成的系统的视图。CIM 在概念上类似于 RUP
中的领域模型组合,该组合是一组工件,包括业务词汇表、业务分析模型(该模型是业务建模中“任务:开发领域模型”的输出)和用例模型(对系统行为的独立于计算的描述)。用主题或领域专家的语言表达的 CIM
是即将形成的系统中的关键抽象确定(分析和设计期间)中的重要链接。
平台无关视点
独立于平台的视点是相对于特定平台的。从此视点,可以查看系统的结构和信息,而没有平台的详细信息。PIM 是从独立于平台的视点来看的系统视图。
平台相关视点
从特定于平台的视点,同时相对于特定平台,您可以查看从独立于平台的视点可见的、但现在附带显示平台用途详细信息的内容。PSM 是从特定于平台的视点来看的系统视图。
自动化转换
转换的概念是 MDA 的基础,并且模型转换可简单定义为“将同一系统中的一个模型转换成另一个模型的过程”。MDA 还定义了一个小模式,来使转化可视化并解释我们已看到的部分术语的用法:
MDA 模式
该图的意图是显示转换是头等的事情:转换掌握 PIM 和其他信息并将其合并产生 PSM。
当然,模型转换也可以手动进行。这有点不同于软件设计始终进行的方式。即使在此,MDA 也可用于描述和正式化转换观念、流程和要使用的其他信息。MDA 还建议产生转换记录;这提供了从 PIM 到 PSM 的强有力的可跟踪性,因为它应包含从
PIM 的元素到 PSM 的元素的映射。大多数手段是为了能够使转换自动化(即使是部分地),产生将汇编程序编程替换成高级语言带来的同样好处。
如何执行转换?
MDA 不规定用一种方法进行转换:准备由平台选择驱动的映射来给出如何针对该平台将 PIM 转换成 PSM 的规范;此映射得出用转换定义语言撰写的转换定义(可能表示成一组转换规则),还可能会有转换参数。请注意,OMG 提出了 RFP(MOF
2.0 查询/视图/转换 RFP),希望为创建模型视图、查询模型和撰写转换定义实施语言的标准化(对于 MOF)。MDA 指南描述了转换的几种方法,包括:
-
元模型转换 - 此方法假定存在使用构建 PIM 的语言的、PIM 级别的 MOF 元模型。同样,对于选中的平台,存在使用构造 PSM 的语言的、PSM 级别的元模型。两个元模型之间的映射可用于构造转换定义;然后用此定义将 PIM
转换成 PSM。
-
标记 - 准备选中平台的映射。此映射用于构造转换定义(该定义包括一组用于标记 PIM 元素的标记,产生“标记过的 PIM”)和如何处理如此标记的元素的定义。然后,进一步转换标记过的 PIM,产生 PSM。
标记通常是手动流程,但后续的转换可以是自动的。
-
模型转换 - 使用也在模型中指定的独立于平台的类型构建 PIM,其中 PIM 中的元素是独立于平台的类型的子类型。选择特定平台,该平台与一组特定于平台的类型关联。在两个类型组之间进行映射,产生转换定义,该定义被应用于
PIM,从而产生以特定于平台的类型的子类型表示的 PSM。此方法有些类似于元模型转换,除了该转换受限于模型中的类型,而不受限于 MOF 元模型的概念。
-
模式应用 - PIM 是使用一组独立于平台的类型和抽象模式构建的。 对于选中的平台,存在一组特定于平台的类型和模式。在两个类型和模式组之间进行映射,给出将应用于 PIM 的转换定义。这会产生 PSM,其中已经使抽象模式特定于平台。
有关更多详细信息,请读者参阅 MDA 指南 [OMG03]。
如何应用转换?
应用 MDA 最简单的场景是:
-
准备 PIM
-
选择平台
-
准备映射,如果尚不存在的话
-
应用转换来产生 PSM
-
将 PSM 转成代码。如果 PSM 不需要进一步改进并可以直接实施,则它是如下一节中定义的实施
其他平台的 PSM 可用相同的方法生成。
重复应用 MDA 模式
不过,MDA 模式服从重复应用:在某一级别生成的 PSM 变成 PIM,用于下一个以及再下一个更加专用的平台选择。请注意,在 MDD 中,正如我们在 RUP 中描述它并使用 IBM Rational
工具集支持它,我们倾向于使改进步骤数量最小化,即,尽量直接地从接近客户的问题陈述的说明进展到可执行的形式。
重复的 MDA 模式应用
上图是为了显示 MDA 模式的三种应用,将初始 PIM 变成依赖平台 1 的 PSM,然后再次转换成依赖平台 2,接着再转换成依赖平台 1、2 和 3。
一般的“模型到模型”转换
相同的概念可应用于一般转换,即任何模型到任何模型。例如,如果存在两个元模型,它们的语言用于表示模型,那么原则上,可建立映射,生成转换定义。这以我们在从 PIM 到 PSM 的转换中已经看到的方法应用。
实施
MDA 指南对“实施”的使用方式与 RUP 的实施模型类似。它是所有需要构造、部署、安装和操作系统的实施元素的规范。
PSM 本身可能是实施或在转成代码之前可能要求进一步改进。请注意,实施 PSM 的产生可跳过显示 PSM 的步骤并直接产生代码。在这种情况下,更抽象的 PIM
能够通过转换引擎直接转成代码。代码可能对于开发人员仍然可见,以帮助其了解,但这可以从代码反向设计。
公认的好处
可移植性和互操作性
通过允许相对稳定的一组 PIM 重新设定以需要什么新技术为目标,MDA 有望控制技术变动的费用和动荡。期望是随着 MDA 接受度的提高,新技术的开发人员也将提供映射,以便能够快速进行转换。
通过为两个平台扩展 PIM-PSM 映射,MDA 建议可在两个 PSM 之间(并最终在两个实施之间)“搭一座桥”,以便可跨平台分发
PIM。大多数公司面临使用新旧混合的技术为不同类型环境进行开发的现实,因此实现互操作性的此功能可能非常有用。
降低生命周期成本
生产力
使用 MDA 开发的焦点变成更抽象的 PIM。使用强有力的工具集来生成 PSM(或代码),这样一个环境应更有成效,同样,用高级语言工作比用汇编程序工作更有成效,特别是在给定通常以用作 RUP 中的设计模型(例如)的任何方式开发
PIM(或类似物)的时候。生产力利润关键依赖于在转换流程中需要多少手动干涉。
质量
理想情况下,在 MDA 中,维护的目标是 PIM。因而,由于 PIM 体系结构组织良好,因此在产品使用期限内缺陷应更少,因为人们更少有机会产生缺陷,而且利用自动转换的好处,对已发现缺陷的修正应花费更低。PIM
的焦点也更密切地符合领域问题,因而应更可能满足用户的需要。
|