目前,我作为测试驱动开发的倡导者,不得不与模型驱动软件开发(MDSD) /模型驱动体系结构(MDA)的倡导者竞争。
在我看来,代码生成在我的工具箱中是一个很有价值的工具,在需要时我会大量使用模板和自动化。当我认为这有助于理解内部工作或讨论白板上的架构时,我也会用UML创建图表。但是,我强烈怀疑通过UML (创建状态图和序列图来创建工作代码而不仅仅是代码框架)创建软件对于多层应用程序(数据库层、业务/域层和Gui,甚至是分布式应用程序)是否更有效。在我看来,当谈到MDSD时,CASE工具突然不再仅仅是一个工具了,但它是一个需要满足的东西:一方面,在我看来,MDSDevelopers从更高的抽象中获得了利润,但同时他们也在努力修改代码生成器/模板/引擎,以满足他们的需求,如果将它们从工具箱中使用(VisualStudio,Eclipse,.),可能很容易实现(和测试)这些需求。
所有这些都让我怀疑,是否有一个成功的故事(毫无疑问,该产品是及时推出的,只在稍早的时间内推出,软件中只有很少的bug和部分部分后来被重用),是否有一个真实世界的应用程序,它填满了这个创建体,并使用严格的模型驱动方法开发了它:
发布于 2010-06-23 23:35:12
在模型驱动的软件网络上发布了一个关于MDSD使用的微小但有用的证明:
source=activity
这是一个相对较小的应用程序正在开发,但仍然是一个很好的例子MDSD的行动。
在Metacase的网站(http://www.metacase.com/cases/index.html)上列出了更多的成功案例。Metacase销售MetaEdit+,实现领域专用建模( DSM ).DSM只是MDSD的一种形式。
我还在开发ABSE (基于原子的软件工程),这是MDSD的另一种形式,非常接近DSM。ABSE是在http://www.abse.info上概述的。
发布于 2010-06-30 18:26:48
我在一个嵌入式系统项目中使用了MDA和代码生成,使用了通过CAN连接的4个处理器。我们有20多个运动轴和许多很多传感器。该系统具有很强的鲁棒性和可维护性,对机械部件进行了评价和修改。
我们在模型中工作并生成代码,因此模型总是最新的。我们做了仔细的领域分析,以实现主题的隔离。电机控制要求非常高的性能,因此没有建模或生成。我们的网络驱动程序也是手工编码的,我们编写了接口,允许桥接器服务根据需要将事件发送到系统中的任何地方(尽管这是严格控制的,以便最大限度地减少处理器间的依赖)。
使用这种方法需要一些训练,但是拥有工作模型是很棒的,因为它们可以被非软件类型所审查。
版本控制和模型的差异是一个有点挑战,但我们有一个小的,本地化的团队,所以我们能够避免合并问题。
开拓者解决方案 (我们的工具供应商)的优秀人员可以帮助指导您完成项目。
发布于 2010-06-30 17:55:02
您还可以查看以前代码生成会议的幻灯片。这些会谈中有几次来自成功的案例研究,如http://www.codegeneration.net/cg2009/slides.php
https://stackoverflow.com/questions/3096702
复制相似问题