I am using MDSD in a project with IBM Rational Rhapsody for C++. The model is pretty close to UML, so there we do not really have a Domain-Specific-Language. But still I would claim to use MDSD. From my experience, there are many benefits with MDSD:
a) Using MDSD helps to bring a SW architecture to a sophisticated level. You always work on a very abstract level, thinking about the big picture. Cowboy coding software usually lacks a good architecture, because a developer is stuck in details. With MDSD, I see a tendency in my work, to solve problems with adequate sized classes, nice patterns, or simply better code.
b) Big picture documentation of the SW tends to be better with MDSD. Of course, there are tools that automatically generate a class diagram out of your code. But these diagrams consists of 1000 classes and you do not see the aspect of interest. With MDSD, you specifically draw one aspect of the system, and the very same diagram is also used to generate a part of your code.
c) Modelling helps to deal with an inherent system complexity. I would say, some systems are just too complex to be built without support from computer-aided design. Nobody would design a CPU without the help of huge SW tools. Use SW to help you write even more complex SW.
d) Using MDSD helps to adhere to coding style guidelines. There is no better way to get coherent code style than letting the code be generated by a rule set.
There are of course also some downsides of MDSD: d) If you have a model, you want every line of code to come from that model. And it may be difficult to include external libraries to a project. So either you live with the fact, that your system is based on external components or you reinvent the wheel to get it into your model.
e) Modelling tools might suffer from problems using versioning tools. Source code is usually simpler to merge than a model diagram. This forces a team to move from the copy-edit-merge to a lock-edit-merge workflow.
Model-Driven Software Development isn't just about MDA, there are a set of other approaches including the, perhaps more popular, Domain-Specific Languages approach.
Sure, the code is 'a' model, but capturing a higher-level model in a DSL is an even more concise way of expressing the same intent. The key is to always generate your code from the model rather than allowing independent modification of generated code.
There's plenty of tooling available, and plenty of published material, including case studies, to tell you how to build your own generators if you're not happy buying an off-the-shelf generator. Arguably this gives you more control than working with a general-purpose programming language.
What I believe in, OTOH, is modeling at runtime. Instead of generating code, keep the model alive at runtime and let your application be a runtime interpreter of these models.
I dont know if this has been done for Java. For Smalltalk see Magritte, which is used in Seaside.
I think it preferable. That is what I was trying to imply on this question about MVC-ARS rather than MVC. The ARS (Action/Representation/State) is contained within the model by design and prevents the overloading of controller or view.
MDA is a bit of an overloaded concept. Sometimes it means turning UML or another type of diagrams in to executable code. I've never seen this work out well with the tools available nowadays. It usually causes projects to get results really fast and then cause a maintanance nightmare because the tools available don't really support big teams working on visual diagrams and because people start working in the diagrams as well as the generated code.
I've seen something that looked a lot like domain driven design being referred to as MDA, if you mean that I'm all for it :-)
针对三层 MDA 方法的实际应用的问题是，这些方法很难设置并适应特定的需求。 想想 ABAP 和 SAP 速率
MDA usually make difficult to integrate the business rules inside the server side layer, as the model view mapping is handled by generated code and functional hooks are provided as event responders.
Still I've not seen a MDA tool as powerful as Forté (or UDS, now dead) + Express were. I imagine that a MDA with the Forté capabilities plus better pattern to achieve an independent service layer (as ActiveRecord, or EntityTransactionManager patterns) would be a killer app for whatever platform.
The problem with actual application aiming at the three tiered MDA approach is that those are terribly difficult to set up and adapt to specific requirements. Just think of ABAP and SAP rates
发布评论
评论（8）
我在 IBM Rational Rhapsody for C++ 的项目中使用 MDSD。 该模型非常接近 UML，因此我们实际上没有特定于领域的语言。 但我仍然声称使用 MDSD。 根据我的经验，MDSD 有很多好处：
a) 使用 MDSD 有助于将软件架构提升到复杂的水平。 你总是在非常抽象的层面上工作，思考大局。 牛仔编码软件通常缺乏良好的架构，因为开发人员陷入细节之中。 通过 MDSD，我在工作中看到了一种趋势，即用足够大小的类、漂亮的模式或更好的代码来解决问题。
b) 使用 MDSD 往往可以更好地记录软件的整体情况。 当然，有些工具可以自动从代码中生成类图。 但这些图由 1000 个类组成，您看不到感兴趣的方面。 使用 MDSD，您可以专门绘制系统的一个方面，并且同样的图表也用于生成代码的一部分。
c) 建模有助于处理固有的系统复杂性。 我想说，有些系统太复杂，如果没有计算机辅助设计的支持，就无法构建。 如果没有庞大的软件工具的帮助，没有人会设计 CPU。 使用 SW 可以帮助您编写更复杂的 SW。
d) 使用 MDSD 有助于遵守编码风格指南。 要获得连贯的代码风格，没有比让代码由规则集生成更好的方法了。
当然，MDSD 也有一些缺点：
d) 如果您有一个模型，您希望每一行代码都来自该模型。 并且将外部库包含到项目中可能很困难。 因此，要么接受这样一个事实，即您的系统基于外部组件，要么重新发明轮子以将其纳入您的模型中。
e) 使用版本控制工具时，建模工具可能会遇到问题。 源代码通常比模型图更容易合并。 这迫使团队从复制-编辑-合并工作流程转向锁定-编辑-合并工作流程。
I am using MDSD in a project with IBM Rational Rhapsody for C++. The model is pretty close to UML, so there we do not really have a Domain-Specific-Language. But still I would claim to use MDSD. From my experience, there are many benefits with MDSD:
a) Using MDSD helps to bring a SW architecture to a sophisticated level. You always work on a very abstract level, thinking about the big picture. Cowboy coding software usually lacks a good architecture, because a developer is stuck in details. With MDSD, I see a tendency in my work, to solve problems with adequate sized classes, nice patterns, or simply better code.
b) Big picture documentation of the SW tends to be better with MDSD. Of course, there are tools that automatically generate a class diagram out of your code. But these diagrams consists of 1000 classes and you do not see the aspect of interest. With MDSD, you specifically draw one aspect of the system, and the very same diagram is also used to generate a part of your code.
c) Modelling helps to deal with an inherent system complexity. I would say, some systems are just too complex to be built without support from computer-aided design. Nobody would design a CPU without the help of huge SW tools. Use SW to help you write even more complex SW.
d) Using MDSD helps to adhere to coding style guidelines. There is no better way to get coherent code style than letting the code be generated by a rule set.
There are of course also some downsides of MDSD:
d) If you have a model, you want every line of code to come from that model. And it may be difficult to include external libraries to a project. So either you live with the fact, that your system is based on external components or you reinvent the wheel to get it into your model.
e) Modelling tools might suffer from problems using versioning tools. Source code is usually simpler to merge than a model diagram. This forces a team to move from the copy-edit-merge to a lock-edit-merge workflow.
模型驱动软件开发不仅仅涉及 MDA，还有一系列其他方法，包括可能更流行的领域特定语言方法。
当然，代码是“一个”模型，但在 DSL 中捕获更高级别的模型是表达相同意图的更简洁的方式。 关键是始终从模型生成代码，而不是允许独立修改生成的代码。
如果您不乐意购买现成的发电机，有大量可用的工具和大量已发表的材料（包括案例研究）可以告诉您如何构建自己的发电机。 可以说，这比使用通用编程语言给你更多的控制权。
Model-Driven Software Development isn't just about MDA, there are a set of other approaches including the, perhaps more popular, Domain-Specific Languages approach.
Sure, the code is 'a' model, but capturing a higher-level model in a DSL is an even more concise way of expressing the same intent. The key is to always generate your code from the model rather than allowing independent modification of generated code.
There's plenty of tooling available, and plenty of published material, including case studies, to tell you how to build your own generators if you're not happy buying an off-the-shelf generator. Arguably this gives you more control than working with a general-purpose programming language.
嗡嗡声。
OTOH，我相信的是运行时建模。 不要生成代码，而是让模型在运行时保持活动状态，并让您的应用程序成为这些模型的运行时解释器。
我不知道Java是否已经这样做了。 对于 Smalltalk，请参阅 Magritte，它在 Seaside 中使用。
Buzz.
What I believe in, OTOH, is modeling at runtime. Instead of generating code, keep the model alive at runtime and let your application be a runtime interpreter of these models.
I dont know if this has been done for Java. For Smalltalk see Magritte, which is used in Seaside.
我认为更可取。 这就是我试图暗示这个问题< /a> 关于 MVC-ARS 而不是 MVC。 ARS（操作/表示/状态）按设计包含在模型中，可防止控制器或视图过载。
I think it preferable. That is what I was trying to imply on this question about MVC-ARS rather than MVC. The ARS (Action/Representation/State) is contained within the model by design and prevents the overloading of controller or view.
MDA 是一个有点超载的概念。 有时，这意味着将 UML 或其他类型的图表转换为可执行代码。 我从未见过使用当今可用的工具可以很好地实现这一点。 它通常会导致项目非常快地获得结果，然后导致维护噩梦，因为可用的工具并不能真正支持大型团队处理可视化图表，并且因为人们开始在图表和生成的代码中工作。
我见过一些看起来很像领域驱动设计的东西被称为 MDA，如果你的意思是我完全支持它:-)
MDA is a bit of an overloaded concept. Sometimes it means turning UML or another type of diagrams in to executable code. I've never seen this work out well with the tools available nowadays. It usually causes projects to get results really fast and then cause a maintanance nightmare because the tools available don't really support big teams working on visual diagrams and because people start working in the diagrams as well as the generated code.
I've seen something that looked a lot like domain driven design being referred to as MDA, if you mean that I'm all for it :-)
如上所述，我发现两本书对理解 MDA 很有用，它是一个广泛的主题。
您不需要阅读所有 Guttman 的内容来了解这个想法，因为案例研究会变得无聊，但介绍读起来很愉快。
Just to throw in two books I found useful in understanding MDA as stated above it is a broad subject.
You don't need to read all of the Guttman to get the idea as the case studies get boring, but the intro was pleasant to read.
这听起来确实不错，但我还没有看到它以实际工作方式实现。
我是这样认为的：《准则》就是模型。 这样您的模型和代码始终是最新的:-)
It sure sounds nice but I have yet to see it implemented in a practially working way.
I hold it like this: The Code is the model. That way your model and your code are always up to date :-)
MDA 通常很难在服务器端层内集成业务规则，因为模型视图映射是由生成的代码处理的，并且功能挂钩是作为事件响应程序提供的。
尽管如此，我还没有见过像 Forté（或 UDS，现在已经死了）+ Express 一样强大的 MDA 工具。 我认为，具有 Forté 功能加上更好的模式来实现独立服务层（如 ActiveRecord 或 EntityTransactionManager 模式）的 MDA 将成为任何平台的杀手级应用程序。
针对三层 MDA 方法的实际应用的问题是，这些方法很难设置并适应特定的需求。 想想 ABAP 和 SAP 速率
MDA usually make difficult to integrate the business rules inside the server side layer, as the model view mapping is handled by generated code and functional hooks are provided as event responders.
Still I've not seen a MDA tool as powerful as Forté (or UDS, now dead) + Express were. I imagine that a MDA with the Forté capabilities plus better pattern to achieve an independent service layer (as ActiveRecord, or EntityTransactionManager patterns) would be a killer app for whatever platform.
The problem with actual application aiming at the three tiered MDA approach is that those are terribly difficult to set up and adapt to specific requirements. Just think of ABAP and SAP rates