我不喜欢MDD,但喜欢UML——如果我认为它没用,为什么我应该使用MDD?

发布于 2024-10-15 01:39:34 字数 941 浏览 6 评论 0原文

我是一名 Java 软件开发人员/架构师,我喜欢 UML。

话说我也讨厌java生成的代码。

我没有看到尝试生成应用程序骨架有任何价值:

  • 创建空类非常容易,我不需要工具来做到这一点,
  • 而且我也无法重用生成的代码,因为它的生成方式使得不可能重用

对我来说,困境在于我的需求变化如此之快,以至于我需要能够立即将新需求实现到现有代码中。

我的问题是,如果我从模型生成代码,然后在生成的代码库中手动开发,我无法使用模型再次生成代码,因为我的修改将被删除。

除了我来回复制/粘贴更改之外。这是一项巨大的努力,但成果却太少。因此我不使用MDD,但仍然大量使用UML。

如果没有 MDD 代码生成,UML 能否在项目中取得成功?

我问这个问题是因为我有一位新老板想要通过 IBM RSA 引入完整的 MDD 流程,而今天我更喜欢实时代码和模型同步或与 Omondo 合并。

  • 为什么要改变一个正在运行且经过验证的系统?
  • 为什么要从模型系统地生成代码,而我可以直接在代码中生成代码,然后将其与模型合并?
  • 为什么要生成垃圾数据库代码,甚至无法部署,而我可以添加构造型以获得 java 注释并将它们与 hibernate 一起使用来生成我的数据库?

老板改变的原因之一是为了获得更好的 HTML 格式的项目文档。我非常怀疑这一点,并认为他正在寻求对交付的更多控制,并且不知道还能发明什么!

其他争论理由:

  • 使用来自大型且稳定的公司的产品。
  • 拥有可用的完整模型,可以用任何其他语言部署。
    (这就是为什么对我来说 MDD 很愚蠢,因为不可能仅从模型中部署到任何平台、任何服务器、任何数据库。那么为什么要浪费我的时间呢?)

请给我一些论据,以便在下次会议上回来让这个愚蠢的 MDD 新粉丝崩溃吧,他想重组我们今天的工作方式!

I am a java software developer/architect and I like UML.

Saying that I also hate the java generated code.

I don't see any value trying to generate the skeleton of my application:

  • creating empty classes is really easy and I don't need a tool to do that
  • also I cannot reuse the generated code because the way it is generated makes it impossible to reuse

The dilemma for me is that my requirements changed so quickly that I need to be able to implement the new demand immediately into an existing code.

My problem is that if I generate my code from my model and then manually develop inside the generated codebase, I cannot generate code again using a model because my modification would be erased.

Except I copy/paste the changes back and forth. That is an enormous effort for too few results. Therefore I do not use MDD but still use a lot UML.

Could UML be successful in a project without MDD code generation ?

I am asking this question because I have a new boss who wants to introduce full MDD process with IBM RSA and today I prefer to have live code and model synchronization or merge with Omondo.

  • Why change a running and proven system?
  • Why systematically generate code from a model while I can do it directly in the code and just merge it later with the model?
  • Why get crap database code generation which cannot even be deployed while I can add stereotype in order to get java annotation and use them with hibernate to generate my database?

One of the reason for boss's change is to get a better project documentation in HTML format. I highly doubt this and think he is looking for more control on delivery and does not know what else to invent!

Other argumentative reasons:

  • Use a product from a large and stable company.
  • Have a full model available which could be deployed in any other language.
    (This is why for me MDD is stupid because it is impossible to deploy on any platform any server, any database just from a model. So why to waste my time?)

Please give me some arguments in order to come back at next meeting and crash this stupid new MDD fan who wants to reorganize the way we work today!

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

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

发布评论

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

评论(3

匿名。 2024-10-22 01:39:34

我想你的帖子里已经有答案了。

MDD 一直受到两个基本问题的困扰:

  1. 输入(建模语言)的表达能力不足以捕获整个问题。结果:您需要用另一种语言(代码)来完成规范。
  2. 生成器(即将模型转换为代码的规则)通常不完整和/或不开放供开发团队修改和/或生成质量较差的代码。

把这两件事放在一起,你就会得到你提到的可怕的混乱。结果:尝试将手写代码与质量较差的生成代码拼接在一起。结果:不漂亮。

然而。请不要从上面推测我是反对 MDD 的。我不是——事实上恰恰相反。但是:工具和流程需要解决上述两个基本问题。

我遇到/很少/很少这样做。我几年前使用过 RSA,但它绝对不是其中之一。 (但是它已经有一段时间来改进,所以现在可能就在那里)。

一个简单的“温度检查”问题就是询问该工具是否提供完整的动作语言。如果不这样做,就会遇到问题(1)。如果失败了,你很可能会陷入痛苦。

如果您的老板真正想要的是良好的 HTML 文档,那么只需集成 UMLGraph 或 apiviz< /a> 进入你的构建。

因此,回答您的具体问题:

在没有 MDD 的情况下能否成功使用 UML?是的。通常有两种方式:

  1. 作为白板草图的非正式或半正式符号,同时找出问题和/或解决方案(Martin Fowler 称之为 UML as Sketch
  2. 作为构建过程中从代码自动生成的文档。

您最终会浪费非生产性时间的地方是创建与代码没有直接链接的正式 UML 图(通常使用昂贵的工具)。

嗯。

I think your post has the answer in it.

MDD has been plagued with 2 fundamental problems:

  1. An input (modelling language) that is insufficiently expressive to capture the entire problem. Result: you need to complete the specification with another language (code).
  2. The generators - i.e. the rules that convert models to code - are generally incomplete and/or not open for modification by the development team and/or generate poor quality code.

Put those two things together and you get the horrible mess you mention. Consequence: trying to splice together hand-written code with poor-quality generated code. Result: not pretty.

However. Please don't surmise from above that I'm anti-MDD. I'm not - in fact the opposite is true. BUT: the tooling and process need to address the two fundamental issues above.

I've come across /very/ few that do. I used RSA several years ago and it definitely wasn't one of them. (However it's had the intervening time to improve, so it may be there now).

A simple "temperature check" question is to ask whether the tool provides a full Action Language. If it doesn't, it'll fall foul of problem (1). If it fails that, chances are you're in for pain.

If all your boss really wants is good HTML documentation, then simply integrate UMLGraph or apiviz into your build.

So to answer your specific question:

Can UML be used successfully without MDD? Yes. Generally in two ways:

  1. As an informal or semi-formal notation for whiteboard sketching while figuring out the problem and/or solution (what Martin Fowler calls UML as Sketch)
  2. As auto-generated documentation from the code as part of the build process.

Where you'll end up burning unproductive time is creating formal UML diagrams (often with an expensive tool) that have no direct link to the code.

hth.

撩发小公举 2024-10-22 01:39:34

如果您无法控制生成,则您可能使用了错误的工具。

您生成的内容(骨架或框架特定代码)也取决于工具。使用允许您创建自己的模板的工具。

认为往返工程永远有效的想法是错误的。您无法将不太详细的模型转换为更详细的代码,然后再转换回来而不丢失信息。解决这个问题的一种方法是在模型中拥有与代码相同级别的细节,这不是一件好事。

更好的方法是使用从模型生成的一种方式,并结合一些良好实践来组合生成的代码和手动编写的代码。

您可以将受保护区域用于手动编写的代码:

  • 您在模板位置指定 - 例如方法体,在重新生成时不应覆盖

或代沟模式:

  • 您使用具体类的骨架生成抽象类和代码,您手动完成) 。

还有另一种方法可以解决这个问题 - 完整代码生成。

它可能看起来类似于使用模型进行编码的不良做法,但重点是专门生成某种类型的应用程序 - Web 应用程序、嵌入式应用程序。您生成的基本上是特定于框架的代码,通常可以使用模型来表达和维护。

不要忘记,建模不仅仅是图表,您还可以使用文本 DSL。

对于你的问题 - UML 最初并不是为 MDD 设计的(许多 MDD 实践者根本不使用 UML...),因此你可以根据需要将它用于 OO 分析和设计。

当涉及到你的老板和 RSA 时,尝试找出你的老板真正需要和想要什么,然后尝试为他提供一些更好的工具或实践。

正如另一个答案中提到的,有很多文档工具。

If you cannot control the generation, you are probably using the wrong tools.

What you generate - skeletons or framework specific code - is also depending on the tool. Use tools which allow you to create your own templates.

It is wrong to assume roundtrip engineering will ever work. You cannot transform less detailed model to more detailed code and then back without losing information. One way to solve this would be having same level of details in models as in code, which is not a great thing.

Better approach is to use one way generation from models combined with some good practices for combinening generated and manually written code.

You can use protected regions for manually written code:

  • you specify in template places - e.g. method bodies, which should be not overwritten when regenerating

Or the generation gap pattern:

  • you generate abstract classes and code using skeletons of concrete classes, which you complete manually).

There is still one other way to approach this - full code generation.

It might look similar to the bad practice of coding using models, but the point is to specialize for generating certain kind of applications - web apps, embedded apps. What you generate is then basically a framework specific code, which can be often expressed and maintained using models.

Don't forget, that modeling is not just about diagrams, you can use textual DSLs as well.

To your question - UML was not originally ment for MDD (many MDD practicioners don't use UML at all...), so you can use it for OO analysis and design as you like.

When it comes to your boss and RSA, try to find out what your boss really needs and wants, then try to provide him some better tools or practices.

As mentioned in the other answer, there are many tools for documentation.

黎歌 2024-10-22 01:39:34

使用 MDD,对设计进行更改有望变得更便宜:如果需求发生变化,在您的方法中,您必须更新基于 UML 的文档和代码。现在,如果可以自动生成代码,那么对代码的更改应该自动跟随对模型的更改,并且您不必手动执行此操作(至少在那些不添加新内容或不添加新内容的地方)需要改变业务逻辑)。

假设 MDD 有效(是的,对;),您能否证明维护模型(用于文档和设计)和代码的双重成本是合理的?

对你有利的一个论点可能是,如果项目不是太大(无论这意味着什么),那么就不值得承担所有开销。

With MDD, making changes to the design hopefully becomes cheaper: if the requirements change, in your approach you have to update the UML-based documentation, and the code. Now, if the code could be automatically generated, the changes to the code should follow automatically from the changes to the model, and you wouldn't have to do it manually (at least in those places where you don't add new stuff or need to change the business logic).

Assuming that MDD works (yeah, right ;), could you justify the double cost of maintaining the model (for documentation and design), and the code?

One argument in your favour could be that if the project isn't too big (whatever that means), that it's not worth having all the overhead.

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