摘自hawk的blog: http://devhawk.net/MDA+And+Software+Factories++Separated+At+Birth.aspx
我个人并不赞同他的观点,现存的困难和问题并不能掩盖未来的方向。
为方便查看,原文拷贝如下:
MDA And Software Factories - Separated At Birth?
Tonight I went to the monthly meeting of the local chapter of IASA. I should have also blogged thisbefore the meeting, but I forgot. Sorry about that if you live near the Microsoft campus and wanted to go. Next meeting is on 3/30, so mark your calendars.
Anyway, tonight's topic was an MDA workshop featuring AndroMDA. AndroMDA is an open source tool for generating primarily J2EE code for *nix boxes using UML and MDA. (To be fair, the speaker - local chapter president Chris Sterling - demonstrated generating C# code as well. Of course, he ran it under Mono on a Linux box.) This provided a great launching point for a general modeling discussion that helped me get a few things straight in my head. Typically, the UML vs. DSL discussion turns religious pretty quickly. However, I believe that people - like those a the meeting tonight - who are achieving practical success with MDA in the real world are doing so by using a Software Factories style approach.
First off, if you look at how most people use UML for MDA, the class diagram appears to be the most dominant model used. When I say "UML for MDA", what I mean is people using UML as a blueprintoras aprogramming language.While UML has 12 different model types, class diagrams make up the bulk of the modeling effort. (The bulk of AndroMDA code generation works off the UML class diagram, though the BPM4Struts cartridge uses Use Case & State models as well) The other 11 diagrams are primarily used for sketching purposes. That means you're only blueprinting the structural aspect of your system - which in turn means that all the system's behavior has to be implemented by hand. Now, this is not to say that factories suggests you should only model the structural aspect of your system. However, I think this indicates that most pragmatic users have realized MDA doesn't live up to the hype.
Secondly, the class diagram that are used have tobe heavily adorned with custom metadata - typically in the form of stereotypes - in order to be useful for code generation (i.e. blueprint) purposes. AndroMDA has a set of "cartridges" (essentially, target code generators) such as EJB, Hibernate and POJOs. Each of these cartridges has a supported set of stereotypes. While there is some overlap (for example, EJB and Hibernate cartridges both define the Entity stereotype). These stereotypes assign brand new semantics to the elements being modeled. In short, they turn the the generic class modeler into a domain specific modeler!
It appears to me that the pragmatic MDA crowd is using the class diagram as a generic "ball and stick" editor. Model elements that aren't needed are ignored and elements that are needed are added via stereotypes. For example, you can use a class diagram to model a database. Certain elements of the model are ignored (Can a column have protected visibility? Can one table inherit from another?) while other elements specific to the domain being modeled are added (primary and foreign keys, indexes, etc). The problem with this approach is that all of the knowledge of how to build a valid model is in the user's head, rather than the tool. Typically, that means a lot of training as well as a lot of in depth understanding of the framework underlying the model in order to capture the right amount of information. Since all that domain specific information is trapped in the users head, they have to do a ton of menial drudge work. It's different drudge work from things like writing tons of data access code, but it's drudgery nonetheless.
If you're going to need a tool specifically designed for your problem domain, why use a generic tool and a bunch of handwritten rules, when you can codify those rules into a domain specific language of your own? (I mean, other than the obvious "because the DSL Toolkit hasn't shipped yet")
分享到:
相关推荐
将DSL集成到MDA中的主要挑战在于,大多数DSL没有定义符合MDA标准的元模型,使得现有的模型和工具难以直接迁移到MDA环境中。为了解决这一问题,研究者们提出了一种基于高级转换(HOT)的多步骤转换方法。这种方法的...
MDA Distilled is an accessible introduction to the MDA standard and its tools and technologies. The book describes the fundamental features of MDA, how they fit together, and how you can use them in ...
MDA 的关键特点就是软件开发的重点和输出不再是程序,而是各种模型,开发人员的工作是不断拓展模型,只有到了最后阶段才会考虑将其实现。MDA 的核心技术包括统一建模语言(UML)、元对象设施(MOF)、公共仓库元模型...
MDA,全称为Model Driven Architecture(模型驱动架构),是一种软件开发方法,它强调通过模型来定义、理解和构建软件系统。在"MDA-Document: 移动约会应用程序文档"中,我们可以推测这是一个关于如何使用MDA方法...
MDA(Model Driven Architecture,模型驱动架构)是一种软件开发方法论,由OMG(Object Management Group,对象管理组织)提出,旨在通过模型的抽象层次提高软件开发的效率和质量。MDA的核心思想是将软件开发过程中...
MDA的核心思想是将软件开发过程中涉及的系统规约与平台实现相分离,通过创建一系列抽象模型来描述系统功能、架构和行为,然后通过模型转换工具自动生成针对特定平台的代码或配置文件。这种方法不仅促进了软件的重用...
### UML支持MDA开发手册知识点解析 #### 一、UML与MDA概述 - **UML(Unified Modeling ...通过对这些内容的学习和理解,可以帮助开发人员更好地掌握UML和MDA的核心技术和方法论,从而提升软件开发的质量和效率。
MDA,全称Measurement and Diagnostic Application,是INCA软件的一个重要组件,专注于车辆诊断和测量任务。本篇文章将深入探讨INCA中的MDA功能、使用场景以及与INCA版本兼容性的问题。 首先,MDA是INCA软件的核心...
8. **MDA与敏捷开发**:MDA与敏捷方法论的结合是近年来研究的热点,如何在保持MDA的抽象优势的同时,融入敏捷开发的灵活性和快速响应变化的特点。 9. **工具支持**:MDA的实施离不开工具支持,如IBM Rational ...
外接程序(MDA,Managed Add-in)是微软Office应用程序如Word、Excel和Outlook等支持的一种扩展机制,允许开发者创建可插入到Office应用中的独立组件。这些组件能够增强或自定义Office应用的功能,使用户能够执行...
MDA提供了一种通过模型和架构来驱动整个系统(包括物理系统、组织系统和IT系统)全生命周期价值的方法。这种方法从需求到业务建模再到技术实现的整个过程中都能提供支持,能够处理大型系统的复杂性以及组织、人员、...
ICODE-MDA 映射 ICODE-MDA Maps是一种可视化客户端工具,用于在基于 Google 地图的图层上绘制来自数据库的各种数据源。 数据源可以来自海上自动识别系统 (AIS)、沿海雷达或其他具有地理定位信息的目标。 设置 当前...
实际上,MDA与敏捷开发可以很好地结合,通过持续的模型迭代和代码生成,快速响应需求变化,提高软件项目的灵活性和交付速度。 总之,MDA模型驱动开发方法学以其高效、灵活的特点,正逐渐成为现代软件工程领域的一股...
如果发现死锁,MDA可以提供死锁链路,帮助我们理解死锁是如何发生的。 **使用MDA的策略** 有效地利用MDA需要一定的技巧和经验。以下是一些策略: 1. **定期采样和分析**: 设置定期收集MDA数据,然后使用报表工具...
MDA(Model Driven Architecture,模型驱动架构)是一种软件开发方法论,旨在通过将软件开发过程中的核心元素——模型——提升到主导地位,提高软件工程的效率和质量。MDA由OMG(Object Management Group)制定,其...
PCA(主成分分析)和MDA(多维尺度分析)是两种常见的数据分析和降维方法,在计算机视觉领域,特别是人脸识别中被广泛应用。PCA通过线性变换将原始数据转换到一个新的坐标系中,新坐标系的轴是按照数据方差大小排列...
### MDA:新一代软件互操作体系结构 #### 概述 MDA(Model Driven Architecture,模型驱动架构)是OMG(Object Management Group,对象管理组织)于2001年7月提出的一种旨在解决软件互操作性问题的新一代体系结构...