We don’t allow questions seeking recommendations for software libraries, tutorials, tools, books, or other off-site resources. You can edit the question so it can be answered with facts and citations.
Closed 9 years ago.
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(3)
我的两点意见:
我为 Sybase PowerDesigner 编写了一个扩展(.xom 文件)。该工具有一个强大的元类编辑器,您可以使用 vbscript 和专有语言 GTL 编写脚本。它还拥有大量可定制的元类和模板。
我的 PowerDesigner 扩展非常老套,包含一些我没有清理的陈旧代码。因此我没有发表任何东西。它对我有用,而且只对我有用。从我的脑海中学到的一些经验教训:
我想做 UML 建模和代码生成,你也想做吗?
Moose 非常注重属性,因此在这方面值得采用 UML 方法。
没有太多使用角色,但我还是尝试将它们映射到接口。
我对如何建立关系模型不满意。 UML 概念和 moose/perl 概念的许多边缘情况和“阻抗不匹配”。 (顺便说一句,“关联类”在驼鹿中的等价物是什么?)
本机特征是 Moose 中的一个很好的功能,但我还没有成功创建用于编辑它们的 GUI
通过为类型强制设计一个可理解的 GUI 也伤害了我的大脑(我经常需要检查+强制日期值)
静态属性是 UML 中的一个重要功能,但在 Moose 中不太重要。问题是 perl/moose 中没有“static”关键字,但你必须声明一个“use MooseX::ClassAttribute”或任何它被调用的东西,并且每个类只执行一次,但在正确的位置(顺序问题)
生成的代码不可能完美打印,所以通常我会立即通过 perltidy 发送它,以使其成为“规范”形式,从而使比较和版本控制/提交到 SVN 变得更容易。
当生成一个类时,Moose类的紧凑性消失了,你将拥有svn属性,头注释,大量的“use”+“use lib”语句,大量的POD,每个子声明后的一些注释行使用参数传递文档,强制性页脚(“没有驼鹿...”)-
不幸的是,逆向工程Perl 代码(从代码更新 UML 模型)是不可能的。因此,在某些时候我必须停止使用 UML 工具,并开始直接编辑 perl 代码,放弃模型。稍后必须手动检查这些更改,非常耗时且需要小心。
优点:
生成正确的 POD 文档化代码是通过执行所有这些 UML 建模获得的主要生产力提升,恕我直言。适合“企业”编程环境。
恕
您可以自动生成带有测试用例(或测试用例存根)的 *.t 文件。需要一些思考来设计智能测试,并避免 Dave Rolsky 在这篇博文中提到的问题:“add(ing) 绝对没有 Moose 本身尚未测试过的内容"
您可以在模型中定义自定义检查,例如“检查构建器方法是否为所有声明的属性都存在,如果不存在,则创建一个存根,或者(问我该怎么做)”
将噩梦般的数据库表轻松映射到驼鹿类。 (我必须处理许多无法触及的多列表)。构建您自己的图形 ORM-Mapper!
可能还有更多优势
My two cents:
I have written an extension (a .xom file) for Sybase PowerDesigner. This tool has a powerful metaclass editor that you can script with vbscript and a proprietary language, GTL. It also has large collections of customizable metaclasses and templates.
My PowerDesigner Extension is quite hacky and contains some stale code that I didnt clean up. Therefore I haven't published anything. It works for me, and only for me. Some lessons learned, from the top of my head:
I wanted to do UML modeling and code-generation, do you want to do that, too?
Moose is quite attribute-heavy so a UML approach is worth doing in this respect.
Didn't use roles much, but I tried to map them to interfaces anyway.
I am not satisfied with how to model relationships. Lots of edge-cases and "impedance mismatches" of UML concepts and moose/perl concepts. (BTW, Whats the moose equivalent of an "association class"? )
Native traits are a nice feature in Moose but I haven't succeeded in creating a GUI for editing them
I also hurt my brain by designing a comprehensible GUI for type coercions (I often need to check + coerce date values)
Static attributes are an important feature in UML but less important in moose. The problem is that there is no "static" keyword in perl/moose, but you have to declare a "use MooseX::ClassAttribute" or whatever it is called, and do it only once per class, but in the right place (order matters)
the code generated is impossible to pretty-print, so usually I send it through perltidy right away, to bring it to a "canonical" form, making diffing and versioning / committing to SVN easier.
When a class is generated , the compactness of Moose class is gone, you'll have svn properties, header comments, lots of "use" + "use lib" statements, lots of POD, some comment lines after each sub declaration with parameter-passing doc, the the obligatory footer ("no moose ....")-
unfortunately, reverse engineering Perl code (to update a UML model from code) is impossible. Thus, at some point I must stop working in the UML tool, and start to edit the perl code directly, abandonig the model. Checking back in these changes must be done manually at some later time, is very time consuming and requires care.
Advantages:
Generating properly POD-documented code is the main productivity gain you'd get by doing all this UML modeling, IMHO. Good for "enterprisey" programming environments.
you can autogenerate *.t files with testcases (or stubs of testcases). Requires some thinking to design smart tests, and to avoid the problems Dave Rolsky has written about in this blog post: "add(ing) absolutely nothing that isn't already tested by Moose itself"
You can define custom checks in the model such as "check if builder methods for all declared attributes exist, and if they don't exist, create a stub, or (ask me what to do)"
easy mapping of nightmarish database tables to moose classes. (I have to work with lots of multi-column tables that cannot be touched). Build your own graphical ORM-Mapper!
there might be even more advantages
我还没有看到 Moose 的 UML 工具。建造一个并没有那么困难,只是需要一点劳动力密集型。大多数情况下,它需要爬行给定类的元类树并为每个步骤输出正确的 UML 标记。如果有兴趣构建这样的东西,您可以访问 irc.perl.org 上的 #moose。我确信有人可以帮助您指明正确的方向。
I haven't seen a UML tool yet for Moose. It wouldn't be that difficult to build one, just a little labor intensive. Mostly it would require crawling the meta-class tree for a given class and outputting the proper UML markup for each step. If are interested in building something like this, you can stop by #moose on irc.perl.org. Someone I'm sure can help point you in the right direction.
在寻找“UML Moose perl”时偶然发现了你的问题。
抛出的其他链接之一是一个名为 umlclass.pl 的实用程序,它看起来很有趣。
看到效果如何后,我将发布后续内容。
Just stumbled across your question while looking for "UML Moose perl".
One of the other links thrown up was to a utility called umlclass.pl that looks quite interesting.
I'll post a follow-up after seeing how well it works.