模型驱动的体系架构MDA
模型驱动的嵌入式系统设计
空间控制技术与应用Aerospace Con tro l and Applicati o n 第34卷 第1期2008年2月模型驱动的嵌入式系统设计吴一帆,张毅玲,周世安(北京控制工程研究所,北京100080)摘 要:随着嵌入式系统设计周期越来越短,功能越来越复杂,越来越多领域的设计人员参与设计,市场需求导向致使需求变更越来越多,以传统文档形式的需求来驱动开发已根本不能满足时间和成本方面的要求。
本文提出了采用可执行模型、动态需求规格和接口控制文档共同作用的驱动嵌入式系统设计方法,它能够较好地满足目前系统设计的要求。
在文中,我们首先介绍了当前嵌入式系统设计中存在的一些问题,然后介绍了模型驱动设计的方法、语言和优点,并对动态需求规格和接口控制文档的执行给出了建议,最后得出模型驱动的嵌入式系统设计是一种行之有效途径的结论。
关键词:模型驱动;统一建模语言;动态需求规格;接口控制文档中图分类号:TP3 文献标识码:A 文章编号:1674 1579(2008)01 0060 05M ode lD ri ven Em bedded Sy ste m D eve l op m entWU Y ifan,Z HANG Y ili n g ,ZHOU Sh ian(B eijing Institute o f Control Engineeri n g,B eijing 100080,China)Abst ract :This paper presen ts a m e t h od for developm ent of e m bedded syste m s .It addresses issues ho w to desi g n a m ulti technolog ies syste m w ith he l p o fm ode,l specs and interface contro l docum ents(I C D ).Theex isti n g proble m s w ith the desi g n are first analyzed .Then the paper addresses the issues that m ode,l acti v e specs and I CD can drive the deve l o pm ent o f e m bedded syste m s effectively during t h e design phase .F i n all y ,so m e usef u l conclusions for t h e e m bedded syste m developm en t driven by m odel are g i v en .K eyw ords :m ode l dri v en ;UM L ;active spec ;I CD收稿日期:2007 12 09作者简介:吴一帆(1972-),男,四川人,高级工程师,研究方向为电子线路设计(e ma i:l w uy @f bice .org .cn)。
一种基于MDA的容错软件开发工具框架设计
［ ｙｗｏｄ Ｉｍｏ ｅ ｒ ｅ ｃ ｉｃｕｅＭＤＡ）ｆｕｔｏｅａｔ Ｔ ｓｆ ｒ； ｎｆ ｄｍｏ ｅ ｎ ｎ ｕｇ （ ＭＬ Ｋｅ ｒｓ ｄ ｌ ｉ ｎａ ｈｔ ｔｒ（ ｄｖ ｒ ｅ ；ａｌｔｌｒｎ（ ） ｏ ｗａ ｕ ｉｅ ｄ ｌ ｇｌ ｇ ａ ｅＵ ） － Ｆ ｔ ｅ ｉ ｉ ａ
当今软件变得越来越复杂 ，开发人 员发现软件开发仅使
ｐ ｏ ｌ ｍｓｏ ｅ ｄ ｓ ｒｐ ｉ ｎ ｏ ｏ ｗａ ｅ ｆ ｕ ｔｔ ｌｒ ｎ ｅ ｐ ｏ ｅ ｉ ｓ ａ ｄ ｉ ｃ ｅ ｓ ｓ ｔ ｅｅｆ ｃ ｅ ｃ ｆｓ ｆｗａ ｅｄ ｖ ｌ ｐｍｅ ｔ ｒ ｂ ｅ ｆ ｅ ｃ ｔ ｆｓ ｆ ｒ ａ ｌ ｏ ｅ ａ ｃ ｒ ｐ ｒ ｅ ， ｎ ｒ ａ ｅ ｆｉ ｉｎ ｙ ｏ ｏ ｈ ｔ ｉ ｏ ｔ － ｔ ｎ ｈ ｔ ｒ ｅ ｅｏ ｎ．
维普资讯
第３ ３卷 第 ２ 期 ｌ
ｂ ３３ ｔ Ｎｏ２ ．Ｊ
计
算
机
工
程
２０ ０ ７年 ｌ １月
Ｎｏ ｍ ｂｅ ０ ７ ｖｅ ｒ２０
Ｃｏ ｐｕｔ ｒＥｎｇ ｎｅ ｒ ｎ ｍ ｅ ｉ ｅｉ ｇ
・ 开发研究与设计技术 ・
一
文 编 １ ０ ３ ８ ０ ）＿ ２ ＿ ３ 文 标 码。 章 号： ｏ － ４ （ ０２ ＿ ７ ＿ ｏ— ２ ２ ７ １ ｏ ＆ ０ 献 识 Ａ
随着现代软件 工程技术 的发展 ，特 别是统一建 模语言
（ｎｆ ｄｍｏｅｉｇｌ ｇ ａｅ Ｕ ） ｕ ｉｅ ｄｌ ａ ｕｇ ， ＭＬ及一些支持 ＵＭＬ的建模工 ｉ ｎ ｎ 具如 Ｒ ｔ ｎｌ ｏｅ的出现 ，软件 开发者能够在更高级另 的抽 ａｉ ａ Ｒ ｓ ｏ ０
象上完成工作 ，通 过这些工具工作在设计级别 的团队向工作
SOA_术语概述
SOA 术语概述第1 部分，服务、体系结构、治理和业务术语引言在任何领域中，语义都非常重要，而在面向服务的体系结构（Service-oriented architecture，SOA）中更是如此。
由于SOA 涉及多个团队和组织，因此就相关术语达成一致至关重要。
本系列将带着您开始SOA 之旅，为您定义基础术语和主要概念。
您将了解SOA 领域中所使用的各个词汇。
对于每个术语，将说明其为何对SOA 重要、其在这种情况下的含义、相关的标准有哪些以及与其他术语的区别如何。
关于组织方式的说明以下列出的术语并不是按照字母顺序排列的，也不是按照其重要性进行排列。
我们将按照构建块的方式对其进行排列。
首先讨论的是“服务”，因为这个术语可能是理解SOA 框架的最基本概念。
我们将以服务为基础形成“体系结构”、“治理”和“业务”概念的定义。
在很多情况下，我们都将较大的术语分解为较小的组成部分进行讨论。
服务服务显然是面向服务的体系结构的核心，术语服务的使用非常广泛。
不过，这个术语对于不同的人有不同的含义，“什么是服务？”这个问题经常会引发激烈的争论。
我听到过人们讨论业务任务、业务服务、应用程序功能、技术服务或基础设施服务。
我将基于IBM Rational® Method Composer Plug-in for SOA Governance 和IBM Rational® Unified Process for Service-Oriented Architecture 给出一个定义。
（有关更多信息，请参见参考资料部分。
）“服务是执行可重复任务的可发现资源，由外部化的服务规范进行描述。
”由于存在多种不同的定义，通过定义“服务”来开始本文的讨论比较困难。
例如，您可能会认为上述定义过于偏重于技术。
请记住，一定不要过于依赖于服务的正式定义，而要将重点放在服务背后的主要概念上，包括：∙业务一致性：服务并不基于IT 功能，而是基于业务的需求。
一种支持MDA的模型转换方法
ｓ ｆｗａ ｅ ｅ ｇ ｎ ｅ ｎ ｍｐ ｅ ｎ ａ ｏ ． ｉ ｐ ｒ ａ ｈ ｍａ ｅ ｅ ｔ ｒｕ ｅ ｏ ａ ｅ ｂ ｅ ｌｎ ｓｅ ｔ ｂ ｉｈ ｄ ｂ ｏ ｗａ ｅ ａ ｃ ｉ ｃｕ ｅ ｂ ｔ ｅ ｈ ａ ｅ ｆ ｏ ｔ ｒ ｎ ｉ ｅ ｒ ｇ ｉ ｌ ｍｅ ｔ ｔ ｎ Ｔｈ ｓａ ｐ ｏ ｃ ｋ ｓ ｂ ｔ ｓ ｆｔ ｃ ａ ｌ ｉ ｋ ｓａ ｌ ｅ ｙ ｓ ｆ ｒ ｈ ｔ ｔ ｒ ｅ ｗｅ ｎ ｔ ｅ ｐｈ ｓ ｓｏ ｉ ｉ ｅ ｒ ｓ ｔ ｒ ｅ ｓ ｆｗａ ｅ ｌ ｅ ｙ ｌ ，ａ ｄ ｉ ｃ ｎ ｂ ｓ ｄ ｔ ｕ ｐ ｒ ｕ ｏ ｔ ｄ ｔ ｎ ｆ ｒ ａ ｏ ｏ ＰＩ ｓｔ ＳＭ ｓ ｏ ｗａ ｅ ａ ｃ ｉ ｃ ｕ ｅ ｂ ｃ ｍｅ ｈ ａ ｉ ｏ ｙ ｔｍ ｏ ｔ ｒ ｉ ｃ ｃ ｅ ｎ ｔ ａ ｅ ｕ ｅ Ｏ ｓ ｐ ｏ ｔａ ｔ ｍａ ｅ ａ ｓ ｏ ｆ ｒ ｍ ｔ ｎ ｆ ｍ Ｍ Ｏ Ｐ ｉ ｒ ．Ｓ ｆ ｒ ｈ ｔ ｔ ｒ ｅ ｏ ｓ ｔ ｅ ｂ ｓ ｓ ｆ ｓ ｓｅ ｔ ｒ ｅ ａ ａ ｙ ｉ ｎ ｄ ｌ ｒ ｎ ｆ ｒ ａ ｉ ｎ ａ ｈ ａ ｍｅ． ２ ｎ ｌ ｓ ｓ ｄ ｍｏ ｅ ａ ｓ ｏ ａ ｔ ｍ ｔ ｔ ｅ ｓ ｍｅ ｔ ｏ ｔ ｉ Ｊ ＥＥ ｓ ｄ ａ ａ ｇ ｔ ｌ ｔｏ ｅ ｐ ｉ ｔ ｒ ｒ ｔｎ ｈ ｒ ｃ ｓ ｆｕ ｉ ｇ ｔｉ ｐ ｒ ａ ｈ ｉ ｕ ｅ ｓａｔ ｅ ａｆ ｒ ｔ ｈ ｌ ｎ ｅ ｐ ｅ ｉ ｇ ｔ ｅｐ ｏ ｅ ｓｏ ｓｎ ｈ ｓａ ｐ ｏ ｃ ． ｓ ｒ ｐ ｍ ｏ
模型驱动的软件开发模式
开发计 划是否 得到用 户 的认可 ？ 是 否 向项 目组 成员传 达 了被 批准 的开 发计 划 ？
开发计 划变更 的方 法是 否明确 ？
项 目中越来越 展现 出卓越 的解 决 问题 的 能力和强大 的生命力 。 基 于 ＭＤ Ａ的软件 开 发生命 周期 是 由软件 系统 的建模 行 为驱动 的 ，整 个开 发过程 都是 围绕模 型 的创 建和 变换开 展的 ，如 图 ｌ
所示 。
从 整体 来看 ，当完 整实 现 ＭＤ 后 ，对 生命周 期 的关 注 点 Ａ 从 “ 代码 ”转 移到 了 “ 模型 ” 。与传统 开发 过程相 比较 ，ＭＤＡ 开发 过程有许 多地 方没有 改变 ， 仍然 需要先 找 出需 求并加 以表 示 ，需要测试 系统 、部署系 统 。改变较 大 的是 分析 、设 计和编
综上所述 ， Ｑ Ｓ Ａ相 关活 动的开 展和 建立是 一个持 续 改进 的过程 ，需 要单位领 导 的全 力支 持和全 员 的积 极 参与 。软件 研发 单位只有 真 正建立 了 Ｓ Ａ 规范 ，培养 了专 业 的 Ｓ Ａ 人员 ，建立起 Ｓ 体系 ，软件 项 Ｑ Ｑ ＱＡ
目管 理才 能实现 由人治到法 治 ，才 能彻 底提 高软件 开发过 程质 量 ，从 而保证 软件 质量 和开 发进度 。
技术 界预言 为未来几 年 内最 重 要 的方法 学 。
６２ 基 于 Ｊ Ｅ ．４ ２ Ｅ过 滤 器 技术 的统 一 身 份 认 证 与访 问控 制 技 术
陶 以政 吴 志 杰
企业 级信息系 统 的安全 性 己成 为信 息化 建设 过程 中至 关重要 的一环 ，从信 息系统本 身 的角度 来看 ，信 息 系统本 身 的安全 性包 括通 信 加密 、用 户认证 、用 户访 问控 Ｓ（ Ｕ 用户 授权 ） 数据存 储加 密等 。用 户认 证 、 和 用户 访 问控 制是企业 级信 息系 统必 须解 决 的首要 问题 ，用 户认 证是信 息系 统安全 性 的第 一道 防线 ，是对用 户 身份进行 合法性 认证 ，而 访 问控 制是 对合法 用户 的身份 进行 确认 ，根据 用户身 份进行 不 同的授 权 ，授权
genexus介绍..
智能信息系统开发与维护工具GeneXus源于卓越理念的精良开发工具是开发项目成功的奥秘之一现在，您也有机会使用一个革命性的工具来提高您的竞争力令开发与维护效率成倍提高满足现在和将来的需要智能信息系统开发与维护工具—GeneXus一、什么是GeneXus随着技术进步，软件系统开发工具的改变一直都没有停止。
从汇编语言，高级语言，到集成调试环境(IDE), 开发工具的抽象层次在不断越升。
目前，模型驱动构架（Model Driven Architecture MDA）的软件开发革命已经到来。
GeneXus是目前世界上第一个获得广泛成功应用的模型驱动构架开发工具。
GeneXus由ARTech公司开发，是个智能化的、支持多平台应用的开发工具。
虽然MDA是最近几年才提出的概念和方法，但GeneXus技术已经历了十多年发展。
在MDA概念提出前就已经实现了MDA 的主要理念。
GeneXus已在全球30多个国家被数万个软件开发机构应用，众多软件公司和用户机构用其成功开发出许多关键大、中型管理应用系统。
另有更多最终用户使用着100%完全用Genexus开发的产品。
GeneXus真正作到了软件设计、开发、维护自动化，大大提高了软件开发效率，降低开发、维护成本。
1、业务模型驱动开发工具与传统的强调信息技术、强调数据建模的开发方式不同，GeneXus的开发方式是直接从用户业务角度出发来架构系统，使用GeneXus的开发过程就是用GeneXus来描述用户业务。
开发完成的直接结果是描述用户的业务规则，业务流程等业务内容的业务模型。
在GeneXus技术中，这个业务模型被称为知识库（Knowledge Base,KB）。
知识库主体独立于具体的信息技术，与具体程序语言和数据库系统无关。
开发过程就是业务建模过程。
建立运行系统的其他工作——设计生成数据库、设计生成程序代码、维护等，都是由GeneXus根据知识库中的业务模型完全自动转化完成。
面向对象分析模型总结
2
主要原则
（1）抽象 什么叫抽象？ OO方法广泛地运用抽象原则，例如： ·系统中的对象是对现实世界中事物的抽象， ·类是对象的抽象， ·一般类是对特殊类的进一步抽象， ·属性是事物静态特征的抽象， ·操作是事物动态特征的抽象。 过程抽象 任何一个完成确定功能的操作序列，其使用者都 可把它看作一个单一的实体，尽管实际上它可能 是由一系列更低级的操作完成的。 数据抽象 根据施加于数据之上的操作来定义数据类型，并 限定数据的值只能由这些操作来修改和观察。
汽车
奖杯
钟表
操作员 职员
天平 楼房 飞机
起重机
23
如何发现参与者 ——考虑人员、设备、外系统
人员—— 系统的直接使用者 直接为系统服务的人员 设备—— 与系统直接相联的设备 为系统提供信息 在系统控制下运行 不与系统相连的设备 × 计算机设备 × 外系统—— 上级系统 子系统 其它系统
24
用况（use case）
7
基本模型——类图 面向对象的建模中最重要、最基本的模型图 集中而完整地体现了面向对象的概念 为面向对象的编程提供了直接、可靠的依据 可以从三个层次来看
对象层
需求模型——用况图 每个用况是一项系统功能使用情况的 说明，把每一类参与者对每一项系统 功能的使用情况确切地描述出来，便 全面地定义了系统的功能需求
数据接口部分设计
构件化与系统部署
向OOP输出OOD模型
12
OOA与OOD的关系
一致的概念与表示法 OOA和OOD采用一致的概念和表示法，从而不存在分析与 设计之间的鸿沟。 不同的内容、目标和抽象层次
OOA：研究问题域和用户需求，运用面向对象的观点发现 问题域中与系统责任有关的对象，以及对象的特征和相互 关系。目标是建立一个直接映射问题域，符合用户需求的 OOA模型。 OOD：在OOA模型基础上，针对选定的实现平台进行系统 设计，按照实现的要求进行具体的设计，目标是产生一个 能够在选定的软硬件平台上实现的OOD模型。 OOA模型：抽象层次较高，忽略了与实现有关的因素 OOD模型：抽象层次较低，包含了与实现平台有关的细节
基于MDA的工作流建模技术的研究与实现
生成业 务过程 代码 的快 速高效 的 开发过 程 。
（ ｄ ｌ ｒ ｅ ｕ ｔ ｅ 环 境对 Ｘ Ｍｏ ｅ Ｄ ｉ ｎＲ ｎｉ ） ｖ ｍ ＭＬ进 行解 析 、 维护和
张 英 ， 丽 芳 ， 泽 军 王 蒋
（ 西北 工 业大 学 计 算机 学 院， 西 西 安 ７ ０ ２ ） 陕 １ １９
摘
一
要： 为提 高企 业 ｗｅ ｂ应 用 系统 开发 效 率 ， 弥补 模 型 驱 动 架构 在 业 务 逻 辑 建 模 方 面 的 不 足 ， 出 提 种 基 于模 型 驱动 的 工作 流 建模 方 法 。 以 Ｐｔ 网 为 理 论 基 础 ， 出基 于 Ｘ Ｌ的 工作 流 过 程 定 义 ， ｅｒ ｉ 提 Ｍ
使 用互联 网进 行 商 业 运 作 和 信 息 交 流 。传 统 的 Ｗｅ ｂ 应用 开发 主要依 靠 手 工 编 码实 现 ， 由于 其 需 求不 断变 更 以及规模 和 复杂 度 的 日渐提 高 ， 这 种 方 法实 现 的 用 Ｗｅ 用难 以维 护和 扩展 ， 重影 响 了开 发 的效 率 和 ｂ应 严
关键 词 ： Ａ； ＭＤ 工作 流 建 模 ； ＭＬ Ｐｔ 网 Ｘ ；ｅｒ ｉ
中 图 分 类 号 ：Ｐ １ Ｔ３ １ 文献标识码 ： Ａ 文章 编 号 ：６ １ ６４ ２ １ ）６ ０ ２ ． ６ １７ — ５ Ｘ（０ ０ ０ １ ３ ０
引言
随着 Ｗｅ ｂ技术 的快 速发 展 ， 来越 多 的企 业选 择 越
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
模型驱动的体系架构MDA很多组织已经开始对模型驱动的体系架构（MDA）进行关注，MDA 是一种应用系统设计和实现的方法。
对于几个原因来说这都是非常积极的发展。
MDA 鼓励在软件的开发过程中有效的使用系统的模型，并且它支持创建类似系统的最佳实践的重用。
所谓由对象管理组织（OMG）定义的标准，MDA 是一种组织和管理被自动化工具支持的企业体系架构和用于定义模型和推动不同模型类型之间的转换的服务的方法。
当被 OMG 定义的 MDA 标准和用于创建和进化企业级软件系统的术语在业界被广泛的引用时，仅仅到目前为止， OMG 和它的成员，包括 IBM Rational ，已经能够在 MDA 意味着什么、MDA 将向哪里发展、MDA 的哪些方面对于今天的技术是可能的和如何在实践中利用 MDA 上提供清晰的指导。
有效的企业软件开发今天开发企业级的应用要求一种软件架构的方法，这种方法应该能够以一种灵活的方式帮助架构师来发展他们的架构。
这种方法应该允许在及时的实现业务功能的新的能力的情况下重用已有的劳动成果，甚至是当目标基础架构本身在一直的演进。
两个重要的思想现在被认为是应对这种挑战的中心：• 面向服务的体系架构(SOA)。
企业解决方案能够被视作通过良好的说明定义了他们的服务接口契约连接的服务联合。
结果的系统设计通常被称作面向服务的体系架构（SOAs）。
通过将一个系统组织成为被封装好的服务集合，这些服务可以通过他们定义的服务接口被操作，系统的灵活性被大大的增强了。
现在很多组织用一系列的服务和服务之间的相互连接表示他们的解决方案。
• 软件的产品线。
通常，在一个组织开发和维护的系统中，存在着大量的可公用的部分。
从捕获核心业务过程和领域概念的标准领域模型，到开发人员在代码中使用的实现设计的实现细节方案，我们在企业的软件项目的每一个级别上看到了重用的方法。
当模式能够被经验丰富的从业者开发出来并在跨越组织的范围内传播时，软件开发组织将获得大量的效率。
这表现了一种朝着促进计划的资产重用，增加自动化的级别来实现被开发系统大部分的方案的软件产品线开发视图的迁移。
更加普遍的情况下，我们能够将在开发的产品线视图中定义良好模式的应用理解成为一种从一个抽象级别到一个更底层抽象级别的方案转化描述的方法。
这两种思想对对象管理组织（OMG）的思想有着重大意义的影响，一个开发和支持规范以改进企业软件开发和部署实践的软件组织联盟（在下一个部分 OMG 将扮演更重要的角色）。
OMG 已经创建了一个概念性的框架，这个概念性的框架将平台选择与独立的面向业务的决定分离开来以使在架构和演进这些系统时允许更大的灵活性。
这个概念性框架和帮助实现它的标准就是 OMG 称为的"模型驱动的体系架构（MDA）."。
应用的架构师使用 MDA 框架作为表示他们企业架构的蓝图，并且使用在 MDA 中的开发标准作为他们独立于供应商和技术的"未来的证明"。
OMG 的 MDA 的概念通过 OMG 的构建模型的标准对系统的交互性提供了一种开放的、供应商中立的方法：统一建模语言（UML），Meta-Object Facility (MOF)，XML Metadata Interchange (XMI) 和Common Warehouse Meta-model (CWM) 。
企业应用的描述能够使用这些建模标准被建立并被转化到一种主流的开发的或者是私有的平台上，包括 CORBA ，J2EE ，.NET 和基于 Web 的平台。
在我们开始深入的了解 MDA 之前，让我们考虑一下在软件开发中进行建模的基本概念和好处。
建模的基本原理模型提供了一个物理系统的抽象，模型可以让工程师们通过忽略无关的细节而把注意力放到系统的重要部分来思考系统。
工程中的所有工作形式都依赖模型来理解复杂的、真实世界的系统。
模型被用在很多的方面：预期系统的质量，当系统的某些方面变化时推理特定的属性，和为各种涉众沟通关键的系统特征。
模型也可以作为实现物理系统的先驱被开发，或者模型可以根据一个已存在的系统或者开发中的系统被产生作为理解系统行为的帮助手段。
系统和模型转换因为一个系统的很多方面也许都是让人感兴趣的，你可以及时的根据系统相关的部分在任何点上使用各种不同的建模概念和符号来突出一个或者多个特定透视图或者视图。
此外，在一些情况下，你可以使用提示或者规则来添加一些模型，这可以帮助你将模型从一种表示法转换成为另一种表示法。
通常在相同的抽象级别上转换到系统的不同视图是必要的（例如，从架构视图到行为视图的转换），并且模型的转换将使它更加容易。
在其他的情况下，模型之间的转换是在一个特定的方面上进行的，这种转换是从一个抽象级别到另一个抽象级别，这往往是通过按照转换的规则添加更多的细节从更加高的抽象视图到低的抽象视图进行的。
模型、建模和 MDA模型和模型驱动的软件开发是 MDA 方法的核心。
因此，为了更好的理解 MDA ，我们应该首先来了解一下企业应用开发人员是如何利用建模的。
追溯到程序设计的最早的日子，在软件工程的世界里，建模有着悠久的传统。
多数近期的革新都是关注于符号和工具的，这些工具允许用户非常容易的映射到在特定的操作系统上能够被编译的编程语言代码的方式来表示对软件的架构师和开发人员有价值的系统透视图。
这些实践的当前情况是使用统一建模语言（UML）作为首选的建模符号。
UML 允许开发团队在相应的模型中获取一个系统的各方面的重要特征。
这些模型之间的转换主要是手工进行的。
UML 建模工具典型的支持需求的跟踪和模型元素之间的依赖关系，通过支持文档和补充的咨询信息提供如何作为大范围开发工作的一部分来维护同步模型的最佳实践的指导。
一个有用的刻画当前实践特色的方法是看一下用于同步模型和源代码的不同的方法。
这在图 1 中被列举7图 1 显示了今天软件从业者使用的建模方法的光谱。
每一个类型代表了一种独特的帮助软件从业者创建能够运行在特定运行时平台上的应用（代码）和模型与代码之间的关系的模型的使用。
8图 1: 建模的光谱今天，多数的软件开发人员仍然在使用单独－代码的方法（在建模光谱的左端，图1）并且根本没有分离的定义模型。
他们几乎完全的依靠他们编写的代码，并且他们直接在一种集成的开发环境（IDE）中（比如，IBM WebSphere Studio ， Eclipse 或者 Microsoft VisualStudio 9）通过第三代的编程语言如 Java 、C++ 或者 C# 直接的表示他们正在建立的系统的模型。
他们所做的任何"建模"都是以嵌入在代码中的编程的抽象形式进行的（比如，包、模块和接口等等），这些方式是通过程序库和对象层次的机制进行管理的。
任何分离的体系架构的设计模型都是不正规的和依靠直觉的，并且存在于白板上、PowerPoint 幻灯片上或者开发人员的脑袋中。
然而这种方法对于个体开发者和小的开发团队也许是足够的，但是这种方法使在业务逻辑实现的细节中理解系统的关键特性十分的困难。
此外，随着系统的范围和复杂度的增加，系统的演进或者在原来的设计团队成员不能直接的与维护系统的团队沟通时，这种方法对于管理这些方案的演进将是更加困难的。
一个改进是在一些适当的建模符号中提供了代码可视化。
当开发人员创建或者分析一个应用时，他们通常希望通过一些辅助理解代码的结构或者行为的图形化符号来可视化代码。
作为一种编辑基于文本代码的可选方式利用图形化的符号也是可能的，所以可视化的描写变成了一种代码的直接表示。
这种描写有时称作代码模型，或者实现模型。
在允许这种画图的工具中（比如，IBM WebSphere Studio 和 Borland Together/J），代码的视图和模型的视图可以被同时显示；当开发人员对其中的一个进行操作时，另一个视图也将立即进行同步。
在这种方法中，图与代码表示紧紧的联系在一起，并提供了在代码级别上观看和编辑的可选方法。
建模的更深层次的利益是通过双向工程（RTE）得到的，双向工程提供了一种在描述系统的架构或者设计和代码的模型之间进行双向交换的机制。
典型的情况下，开发人员将系统设计细化到一定的详细级别，然后通过应用模型－代码的转换创建第一轮的实现，这通常是手工完成的。
例如，一个工作在高级别设计的团队也许会向工作在实现级别上的团队提供设计模型（也许是通过简单的打印出模型图或者为实现团队提供包含模型的文件）。
实现团队转换这个抽象、高级别的设计成为详细的设计模型的集合和编程语言的实现。
其中表示上的重复将作为错误出现，这些错误既可以在设计模型中更正也可以在实现模型中更正。
因此，如果没有良好的纪律，抽象模型和实现模型常常—并很快—的因为步调不一致而结束。
工具能够自动化的进行最初的转换，也可以在设计模型和实现模型进行演进时帮助他们保持步调一致。
典型的，工具可以从用户必须进一步细化的设计模型生成代码的框架。
对代码的更改必须要在一些点上与原有的模型相一致（也就是术语"双向工程"或者 RTE）。
为了实现这一点，你需要一种方法来识别出被产生的用户定义的代码；在代码中放置标记就是一种方法。
实现这个方法的工具，比如 IBM Rational Rose 能够支持在模型与不同实现语言之间双向提供多种转换服务。
在一种以模型为中心的方法中，系统模型具有足够的细节能够从这些模型中生成整个系统的实现。
为了实现这一点，模型也许应该包括，比如持久数据和非持久数据、业务逻辑和表示层元素的表示法。
如果存在任何与遗留数据和服务的集成，对那些元素的接口也需要被建模。
然后代码生成过程应用一系列的模式将模型转换成代码，通常允许开发人员对被应用的模式进行一些选择（比如，选择各种不同的部署拓扑）。
这种方法常常使用标准的或者私有的应用框架和运行时服务，这些应用框架和运行时服务能够通过限制被生成应用的类型使代码生成任务更加容易。
因此，使用这种方法的工具典型的专攻于特定应用类型的生成（例如，用于实时嵌入式系统的 IBM Rational Rose Technical Developer 和用于企业 IT 系统的IBM Rational Rapid developer）。
然而，在所有的情况下，模型都是被开发人员创建和操作的主要产物。
一个单独模型的方法在图 1 中的编码/建模光谱的最右端。
在这种方法中开发人员把模型纯粹的作为理解业务或者方案领域，或者分析被提议的方案架构的辅助手段。
模型通常被作为讨论、交流和在一个单独的组织或者是跨多个组织的项目中进行分析的基础来使用。
这些模型常常出现在新工作的建议中，或者装饰在办公室的墙上和在软件实验室中作为一种促进对一些复杂领域理解的方法并建立一个共享的在完全不同的团队中的词汇表和概念集。