代码之家 › 专栏 › 技术社区 › Craig

工具(最佳实践?)对于模型驱动的开发?

mdsd model-driven-development dsl

Craig · 技术社区 · 16 年前

模型驱动的软件开发。

据我所知,它提高了设计的抽象级别,以更好地反映软件将尝试运行的领域。一句话就够了。

领域专家(客户)和开发人员之间的沟通对于使这种方法起作用至关重要。我想知道的是,是否有一个工具套件或一组最佳实践将有助于MDSD的初始推力?一旦该领域得到充实,那么将该模型映射到ORM(或其他)会怎么样?

我只是潜入MDSD和DSL领域,所以任何建设性的想法或评论都会被认同。

5 回复 | 直到 6 年前

orcmid 16 年前

如果您是在微软平台上开发的,您可能还需要查看奥斯陆。这里有一个很好的概述: http://www.pluralsight.com/community/blogs/aaron/archive/2008/11/03/introducing-quot-oslo-quot.aspx

我还没有准备好将领域驱动设计与模型驱动开发等同起来。

您可能还想检查模型驱动的体系结构(omg mda)的透视图,尽管在滚动您自己的方面可能不多。

模型驱动中的一个大问题与从模型派生实现的专业知识来自何处以及在什么级别上进行维护(和调试)有关。我对现有书籍的测试将是它们如何使管道变得可理解,以及人们如何能够很好地理解从建模到部署再到回来的路径。

Manu JCasso 16 年前

如果您在.NET中编程,您应该阅读JimmyNielsson的“应用领域驱动的设计和模式”。他还有一个关于ORM(nhibernate)、SOA和依赖注入的部分。

无论如何,你应该看看埃里克·埃文斯的“领域驱动设计”。这是一个经典的领域驱动设计模式和最佳实践的宝贵信息

jbandi 15 年前

免责声明:我是业务应用程序的开发人员。下面的观点当然是由我在企业IT领域的经验形成的。我知道,软件开发还有其他领域。特别是在工业和/或嵌入式系统开发中,世界可能看起来不同。

我认为MDSD仍然与代码生成有太多的联系。

只有当代码包含大量噪声和/或非常重复时,代码生成才有用。换句话说,当您的代码不能主要集中在基本的复杂性上,而是被偶然的复杂性所污染时。

在我看来,当前平台和框架的趋势正是消除偶然的复杂性,并让应用程序代码关注本质的复杂性。

因此,这些新的平台/框架从MDSD运动的风帆上乘风破浪。

DSL(文本的)是另一种试图使人们只关注本质复杂性的趋势。虽然DSL可以用作代码生成的源代码,但它们主要不与代码生成相关。DSL(尤其是内部DSL)基本上允许它在运行时被解释/执行。[运行时代码生成介于两者之间]。

所以,即使DSL经常与MDSD一起被提到,我认为它们确实是MDSD的替代品。考虑到目前的炒作,他们也将MDSD运动的动力抽走。

如果您已经达到了最终从代码中消除意外复杂性的目标(我知道这是虚构的),那么您就得到了业务问题的文本模型。这不能进一步简化!

好的方框和图表不提供抽象级别的另一个简化或提升!它们可能有助于可视化,但即使是这样也值得怀疑。一张图片并不总是把握复杂性的最佳表现!

此外,MDSD中涉及的工具的当前状态增加了另一个级别的意外复杂性(想想:同步、差异/合并、重构……),这基本上取消了简化的最终目标!

请看下面的ActiveRecord模型,以说明我的理论:

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

我认为这不能再简单了。此外,任何带有方框和线条的图形表示都不会简化,也不会提供任何便利(考虑布局、重构、搜索、差异化…)。

S.Lott 15 年前

MDD可能非常复杂或相对简单。

如果您想自动化从各种模型(例如UML)到代码的转换,并进行往返工程等等,您可以得到一些非常有趣的工具。

或

您可以使用单向(模型到代码)转换,手工绘制模型并或多或少地构建代码。

首先建立模型的想法是一个成熟的最佳实践。它通常被称为“设计”。当人们把设计和规范混为一谈时,就会出现问题。将要构建的模型不是编程规范。它是一个抽象,可用于评估正确性、定义测试用例、编写规范等。

你不必为一切建模。您可以通过拥有一个独立于任何特定实现的数据模型来启动MDD。

你不需要更多。您需要做的是集中精力在处理太多其他问题之前正确地获取模型。

这些问题通常是由软件开发过程中发生的各种过早的优化引起的。早期进入RDBMS物理设计。早期跃进了网页设计领域,并以此驱动数据模型。早期就开始定义服务器体系结构和分配存储。

Romain Bernard 6 年前

您应该阅读这篇关于MDSD最佳实践的优秀论文,来自Markus Voelter: http://www.jot.fm/issues/issue_2009_09/column6.pdf

关于MDSD/DSL选项,EMF生态系统( https://www.eclipse.org/modeling/emf/ )提供了许多有用的构建基块:

减少工具投资的一个有趣的选择也可以是使用可扩展的UML建模器,在重用的建模器之上定义自己的UML概要文件和自定义工具(如果您的UML建模器基于UML2/EMF实现,那么前面的列表仍然足够)。