Im starting working with Moose/Perl and im searching for an UML Tool to create diagrams and representing the Moose OO System. I already worked with Astah (former Jude) but it is designed for Java OO System. Can someone give recomend other UML tool to work with Moose/Perl?
UML Tool for Moose Perl
842 Views Asked by Newton At
3
There are 3 best solutions below
1

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.
0

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.
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