Trufun Kant实现模型驱动架构

简介:
  模型驱动架构(Model Driven Architecture,MDA)是由OMG定义的一个软件开发框架。它是一种基于UML以及其他工业标准的框架,支持软件设计和模型的可视化、存储和交换。和UML相比,MDA能够创建出机器可读和高度抽象的模型,这些模型独立于实现技术,以标准化的方式储存。MDA把建模语言用作一种编程语言而不仅仅是设计语言,MDA的关键之处是模型在软件开发中扮演了非常重要的角色。Trufun Kant系列产品就是一款非常便捷的MDA工具,它是基于Trufun Plato UML2.x建模工具基础上开发出来的,因此它的可以实现整个项目的分析、设计、开发过程。可以实现与平台无关的模型,并可将此模型转换为平台相关模型。 ( :Trufun Kant 系列产品有 Trufun Kant for Java ,Trufun Kant for vs.net, Trufun Kant for C++ 以及涵盖了以上三个产品功能和数据库建模的 Trufun kant Studio 大集成产品
      MDA源自于众所周知的把系统操作的规范从系统利用底层平台能力的方式细节中分离出来的思想,MDA工具提供了一种途径(通过相关的工具)来规范化一个平台独立的系统、规范化平台、为系统选择一个特定的实现平台,并且把系统规范转换到特定的实现平台。Trufun Kant系列产品则是完全遵照这些规范的MDA工具,为系统提供了一个统一的实现平台。MDA的三个主要目标是:通过架构性的分离来实现轻便性、互操作性和可重用性。 
     模型驱动架构(MDA)是OMG组织近年来一直热炒的一个新的技术体系,也是众多搞软件模型研究人员的一个新热点,其核心的思路是希望通过对商业模型(比如企业信息化或建筑领域的解决方案)的领域研究。进而提炼出一个相对核心的领域模型,同时抽象出一个PIM(平台无关模型)。之后根据不同的开发平台(例如.net或Jave),应用平台(windows或unix)形成相应的 PSM(平台相关模型)。Trufun Kant 系列MDA工具已经可以完整地生成相应的代码框架,保障了项目从需求开始到后面的实现框架的统一和稳定。 
      模型驱动架构(MDA)的发展阶段理论还处在一个探索期,很多工具的也是跟着MDA的思想在一步步完善,从目前的趋势而言,要完全实现OMG提出的MDA 思想,MDA工具至少还需要数年的努力才能完全成熟。目前MDA工具的实现还局限于类图与代码的对应,代码框架的生成,但是大多数工具还无法实现两者之间的反复正反向同步,而Trufun Kant产品则已经很好的解决了这一问题,使无论修改模型还是修改已经生成的代码都能够保障实时同步到另一边,保障项目过程中模型和开发的始终统一。 
        MDA 目前在以下领域得到了应用:  
      *银行业 
      *保险业 
      *公共企业(特别在金融管理领域) 
      *嵌入式系统 
      *后勤保障系统 
目前Trufun Kant系列产品的应用已经基本覆盖以上领域。 
      您也会看到,MDA的确在其中起到了作用。MDA的实现主要集中在以下3个步骤: 
      1 首先,您用UML对您的应用领域进行高度抽象的建模,这个模型和实现它的技术(或者底层技术)完全没有关系。这个模型我们称之为平台无关模型(PIM)。 Trufun Kant 系列产品是基于UML2.1最新标准的UML建模工具——Trufun Plato实现的,因此对于这一点的支持是毋庸置疑的。 
      2 然后,PIM将被转换为一个或多个平台相关模型(PSM)。这个转换过程一般是自动实现的。PSM将用一个特定的实现技术来描述您的系统。Trufun Kant系列产品实现这一过程的自动转换,并且可以将PIM模型转化为10多种面向对象的语言相关的PSM。这一步是MDA流程中最难的,它要求您对您要应用的基础技术具有丰富且巩固的知识,另一方面,源模型(PIM)必须具备自动生成PSM所要求的足够信息量。 
      3 最后,PSM将被转换成源代码。Trufun Kant 系列产品利用了桥接器技术和代码框架技术来实现这块功能,其中代码框架可以正向完成模型到代码的转换,而桥接器则保障了模型和代码的实时同步。 
       使用 MDA 的前提  
      * 业界(甚至是整个世界)一个被广泛接受的事实是:只有变化是永恒的。技术永远在革新。这在中间件领域尤其明显,当然还有数据库技术,操作系统,甚至是编程语言都经常变化。这些技术明显比应用领域的基本概念要变化的快。 
      * 如果您在某一特定的应用领域工作,在这个领域中的项目都具有一定的相似性。整个应用程序族或者不同的项目都属于同一个应用领域,那么,MDA或者生成流程将特别适合于您。 
       MDA 的优点  
      * 您对建模的投资将更加持久的有效--远长于您目前实现它所应用的技术。这将更有利于保护您的投资。 
      * 您具有了技术上的灵活性。 
      * 您将不再受技术或应用所具有的不同变化周期的影响--在MDA的帮助下,您可以中立的保持两方面的多样性。 
       MDA 的缺点  
      * MDA意味着更多的"组装"而不是"开发"--在为一个应用建立PIM的时候,您基本上没有技术上的周旋空间。这对于今天的很多开发人员来说,还是难以想象的。 
      * 软件开发的创造性在一定程度上减弱了。开发人员常常觉得,就一种新技术展开争论,在技术的前沿工作,是十分吸引人的。可是在MDA流程下,大量的工作是建立模型,这和具体的技术相距甚远,但符合OMG的建议。 
      * 潜在的不成熟性。UML2.x初长成,基于此的MDA工具出现的时间也相对较短,后期的发展还会不断。 
MDA 的软件开发周期  
     在MDA中软件开发过程是由软件系统的建模行为驱动的。下面是MDA的软件开发周期: 
 
      MDA生命周期和传统生命周期没有大的不同,主要的区别在于开发过程创建的工件,包括PIM(Platform Independent Model,平台无关模型)、PSM(Platform specific Model,平台相关模型)和代码。PIM是具有高抽象层次、独立任何实现技术的模型。PIM被转换为一个或多个PSM。PSM是为某种特定实现技术量身定做。开发的最后一步是把每个PSM变化为代码,PSM同应用技术密切相关。传统的开发过程从模型到模型的变换,或者从模型到代码的变换是手工完成的。但是在Trufun Kant系列MDA工具中,这些变换都是工具自动完成的。从PIM到 PSM,再从PSM到代码都可以由工具自动实现。PIM, PSM,和Code 模型被作为软件开发生命周期中的设计工件,在传统的开发方式中是文档和图表。重要的是,它们代表了对系统不同层次的抽象,从不同的视角来看待我们的系统,将高层次的PIM 转换到PSM 的能力提升了抽象的层次。能够使得开发人员更加清晰地了解系统的整个架构,而不会被具体的实现技术所“污染”,同时对于复杂系统,也减少了开发人员的工作量。 
      MDA的出现,为提高软件开发效率,增强软件的可移植性、协同工作能力和可维护性,以及文档编制的便利性指明了解决之道。MDA被面向对象技术界预言为未来两年里最重要的方法学。当今建模的主要问题在于,对于很多企业来说它只是纸面上的练习。这就造成了模型和代码不同步的问题,代码会被不断修改,而模型不会被更新,或者,需求变动了,模型也修改了,但是代码修改不是从模型过来的,这样模型和代码就无法保障从始至终的统一,模型不能反映系统,不是代码最终的实现,模型也就失去了意义,这方面的问题一方面是开发过程管理问题,一方面是有些MDA工具还无法保障这两者的统一,而Trufun Kant系列工具则已经很好了解决后者这个问题,为我们实现这一操作提供平台。弥补建模和开发之间的鸿沟的关键就在于将建模变为开发的一个必不可少的部分,并且使其成为我们可以重新利用和参考的有价值的部分,是我们的开发不因为代码因为开发人员的变动而增加额外成本。MDA 是模型驱动开发的框架,MDA 的愿景是定义一种描述和创建系统的新的途径。MDA 使得UML 的用途走得更远,而不仅仅是美丽的图画。很多专家预言MDA 有可能会带领我们进入软件开发的另一个黄金时代。 
MDA最大的好处就是业务模型的持久价值,但是付出的代价是增加了抽象层,Trufun产品在建模技术方面,提供了OCL最新版本的精确建模支持,可扩展更多的机制来支持精确建模和分析模型。也可以根据用户的实际需要进行业务模型的定制。 
MDA 的相关标准  
      为了实现MDA这一宏大构想,OMG制定了一系列的标准: 
      UML:UML被MDA用来描述各种模型。它并不是为MDA而生,但是作为目前最为风行的建模语言,UML已经占据了全球建模语言领域90%的市场份额,成为了建模语言事实上的标准,因此OMG将它作为MDA技术的基础是自然而然的明智选择。它是MDA的基础,也是MDA最有力的武器。 
      MOF:MOF(Meta Object Facility 元对象机制)是比UML更高层次的抽象,它的目的是为了描述UML的扩展或者其它未来可能出现的类UML的建模语言。虽然MOF也不是为MDA而生的,但是我们可以体味到OMG的工程师们良苦的用心和长远的目光。 
      XMI:XMI(XML-based metadata Interchange)是基于XML的元数据交换。它通过标准化的XML文档格式和DTDs(Document Type Definitions)为各种模型定义了一种基于XML的数据交换格式。这使得作为最终产品的模型可以在各种不同的工具中传递,这一点是非常重要的,它保证了MDA不会在打破了一种束缚之后再被加上一层新的束缚。Trufun Kant系列产品支持生成标准的XMI文档,并且可以导入标准的XMI文档,也可以通过它的转换来导入其他uml模型。 
      CWM:CWM(Common Warehouse Metamodel 公共仓库元模型)提供了一种数据格式变换的手段,在任意级别的模型上都可以使用CWM来描述两种数据模型之间的映射规则,比如将数据实体从关系数据库变换为XML格式。在MOF的框架下,CWM使得通用的数据模型变换引擎成为可能。 

      在OMG的蓝图中,UML、MOF、XMI、CWM等一系列标准分别解决了MDA的模型建立、模型扩展、模型交换、模型变换这几个方面的问题。OMG试图通过标准化的定义,扩大MDA的应用范围。同时通过这样一个可扩展的建模语言环境,IT厂商可以自由实现自己的建模语言,以及语言到可执行代码的映射,然而不管怎么样,都必须处于OMG的标准化框架之下。



本文转自 trufun 51CTO博客,原文链接:http://blog.51cto.com/trufun/134446,如需转载请自行联系原作者

相关文章
|
19天前
|
机器学习/深度学习 自然语言处理 分布式计算
大规模语言模型与生成模型:技术原理、架构与应用
本文深入探讨了大规模语言模型(LLMs)和生成模型的技术原理、经典架构及应用。介绍了LLMs的关键特点,如海量数据训练、深层架构和自监督学习,以及常见模型如GPT、BERT和T5。同时,文章详细解析了生成模型的工作原理,包括自回归模型、自编码器和GANs,并讨论了这些模型在自然语言生成、机器翻译、对话系统和数据增强等领域的应用。最后,文章展望了未来的发展趋势,如模型压缩、跨模态生成和多语言多任务学习。
67 3
|
21天前
|
运维 监控 负载均衡
动态服务管理平台:驱动微服务架构的高效引擎
动态服务管理平台:驱动微服务架构的高效引擎
22 0
|
2月前
|
存储 分布式计算 API
大数据-107 Flink 基本概述 适用场景 框架特点 核心组成 生态发展 处理模型 组件架构
大数据-107 Flink 基本概述 适用场景 框架特点 核心组成 生态发展 处理模型 组件架构
96 0
|
2天前
|
机器学习/深度学习 测试技术 定位技术
新扩散模型OmniGen一统图像生成,架构还高度简化、易用
近期,一篇题为“OmniGen: Unified Image Generation”的论文介绍了一种新型扩散模型OmniGen,旨在统一图像生成任务。OmniGen架构简洁,无需额外模块即可处理多种任务,如文本到图像生成、图像编辑等。该模型通过修正流优化,展现出与现有模型相当或更优的性能,尤其在图像编辑和视觉条件生成方面表现突出。OmniGen仅含3.8亿参数,却能有效处理复杂任务,简化工作流程。尽管如此,OmniGen仍存在对文本提示敏感、文本渲染能力有限等问题,未来研究将继续优化其架构与功能。
30 16
|
1月前
|
机器学习/深度学习 自然语言处理 C++
TSMamba:基于Mamba架构的高效时间序列预测基础模型
TSMamba通过其创新的架构设计和训练策略,成功解决了传统时间序列预测模型面临的多个关键问题。
99 4
TSMamba:基于Mamba架构的高效时间序列预测基础模型
|
16天前
|
网络协议 网络架构
TCP/IP协议架构:四层模型详解
在网络通信的世界里,TCP/IP协议栈是构建现代互联网的基础。本文将深入探讨TCP/IP协议涉及的四层架构,以及每一层的关键功能和作用。
72 5
|
17天前
|
机器学习/深度学习 存储 人工智能
【AI系统】模型演进与经典架构
本文探讨了AI计算模式对AI芯片设计的重要性,通过分析经典模型结构设计与演进、模型量化与压缩等核心内容,揭示了神经网络模型的发展现状及优化方向。文章详细介绍了神经网络的基本组件、主流模型结构、以及模型量化和剪枝技术,强调了这些技术在提高模型效率、降低计算和存储需求方面的关键作用。基于此,提出了AI芯片设计应考虑支持神经网络计算逻辑、高维张量存储与计算、灵活的软件配置接口、不同bit位数的计算单元和存储格式等建议,以适应不断发展的AI技术需求。
28 5
|
2月前
|
机器学习/深度学习 网络架构 计算机视觉
目标检测笔记(一):不同模型的网络架构介绍和代码
这篇文章介绍了ShuffleNetV2网络架构及其代码实现,包括模型结构、代码细节和不同版本的模型。ShuffleNetV2是一个高效的卷积神经网络,适用于深度学习中的目标检测任务。
87 1
目标检测笔记(一):不同模型的网络架构介绍和代码
|
2月前
|
消息中间件 监控 NoSQL
驱动系统架构
【10月更文挑战第29天】
30 2
|
2月前
|
存储 前端开发 API
DDD领域驱动设计实战-分层架构
DDD分层架构通过明确各层职责及交互规则,有效降低了层间依赖。其基本原则是每层仅与下方层耦合,分为严格和松散两种形式。架构演进包括传统四层架构与改良版四层架构,后者采用依赖反转设计原则优化基础设施层位置。各层职责分明:用户接口层处理显示与请求;应用层负责服务编排与组合;领域层实现业务逻辑;基础层提供技术基础服务。通过合理设计聚合与依赖关系,DDD支持微服务架构灵活演进,提升系统适应性和可维护性。