模型驱动开发有什么好处?

发布于 2024-07-09 03:28:08 字数 216 浏览 8 评论 0 原文

因开罗而闻名的微软正在开发奥斯陆,这是一个新的建模平台。 Bob Muglia,微软服务器与高级副总裁 Tools Business 指出,建模的好处一直是显而易见的。

简而言之,奥斯陆为其用户带来了哪些明显的好处?

Microsoft, of Cairo fame, is working on Oslo, a new modeling platform. Bob Muglia, Senior Vice President of Microsoft Server & Tools Business, states that the benefits of modeling have always been clear.

In simple, practical terms, what are the clear benefits that Oslo bestows upon its users?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

自此以后,行同陌路 2024-07-16 03:28:08

从理论上讲,有一些好处:

  • 具有业务知识的人可以创建软件模型,这样您就不太可能在翻译过程中丢失任何东西。
  • 当非技术股东创建模型时,它迫使他们“像开发人员一样思考”。 他们发现,当你将其形式化时,他们认为显而易见且简单的事情实际上很困难。
  • 效率更高。 业务人员有业务知识,技术人员有技术知识,为什么不让每个小组在自己擅长的领域设计一个系统呢? 随着业务专家重新解释电话游戏对开发人员的意义,不再有电话游戏。 开发人员不再因神秘的业务需求而分心。 他们可以专注于高科技系统之间的交互。

在实践中,这要困难得多:

  • 模型很难,仅此而已。 仅仅因为您将模型创建推给不同的团队并不意味着您会得到万无一失的模型。 软件开发都是关于建模的,因此开发人员已经习惯了它。 当第二组开始正式确定他们对业务需求的理解时,您实际上可能会失去效率。
  • 模型驱动的开发与 OO 概念紧密相关。 面向对象对很多事情都有好处,但不是对所有事情都有好处。 如果您真正需要的东西超出了建模工具的能力,会发生什么?
  • 根据我的经验,业务人员和技术人员之间的划分是人为的。 最高效的人是具有技术头脑的业务人员或具有业务头脑的技术人员。 他们让事情发生。 如果将业务任务与技术任务分开,就会破坏交叉培训和交叉思考的机会。

In theory, there are a few benefits:

  • The people with the business knowledge can create the software models so you're less likely to lose anything in translation.
  • When non-technical shareholders create models, it forces them to "think like a developer". They see that what they considered obvious and easy is actually difficult when you formalize it.
  • It's more efficient. Business people have business knowledge and technical people have technical knowledge so, why not let each group design a system in their area of expertise? No more games of telephone as business experts re-explain what they mean to a developer. Developers are no longer distracted by cryptic business needs. They can focus on the interaction between highly technical systems.

In practice, it's a lot trickier:

  • Models are hard and that's that. Just because you push model creation to a different group doesn't mean you get foolproof models. Software development is all about modeling so developers are used to it. You may actually lose efficiency as a second group comes to grips with formalizing their understanding of a business need.
  • Model driven dev is tightly linked to OO concepts. OO is good for a lot of things, but not everything. What happens if what you really need falls outside the abilities of your modeling tool?
  • In my experience, the division between business and technical people is artificial. The most effective people are technical-minded business people or business-minded technical people. They make things happen. If you separate business tasks from technical tasks, you ruin the opportunity for cross-training and cross-thinking.
怪我入戏太深 2024-07-16 03:28:08

我认为建模只是下一个抽象级别。 一旦建立起来,就会带来更高的生产力。

如今的 MDSD(主要以代码生成的形式)可以节省时间。 为软件的不同部分复制工作模式并且仅手动编写真正的业务代码可以稍微提高生产力,但很可能会带来更好的软件质量和更干净的架构。

I think modeling is just about the next abstraction level. Once it is established it will lead to higher productivity.

MDSD Today - mostly in form of code generation - saves time. Duplicating working patterns for different parts of your software and only writing real business code manually boosts productivity a little bit, but most likely leads to better software quality and more clean architecture.

温柔嚣张 2024-07-16 03:28:08

我认为简短的答案是研究项目!

如果您想进一步了解,可以从 Doug Purdy 的 PDC 演讲“A lap around Oslo”开始,您可以参阅 此处。 他解释了奥斯陆如何“在没有仪式的情况下捕捉代码的本质”,……无论这意味着什么。

HTH。

I think the short answer is research projects!

A good place to start though If you're keen to look into it more is Doug Purdy's PDC talk "A lap around Oslo" which you can see here. He explains how Oslo "captures the essence of the code without the ceremony",..whatever that means.

HTH.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文