http://qs321.pair.com?node_id=67248

gregor42 has asked for the wisdom of the Perl Monks concerning the following question:

One thing that's been bugging me lately is the serious lack of UML tools that are available in the first place. In particular, anything open source... But in especially, why is it that no one seems to support OOPERL in any UML editor/development tool?

If I'm wrong on this point, PLEASE someone straighten me out.

Heck, I'd consider building one myself, as a challenge, but with the heavy graphics that would be involved I'd personally be more inclined to write it using Java, which strikes me as very weird indeed if the object of the exercise is to ouput PERL code skeletons...

Does anyone else use UML in general & have you used it for PERL?



Wait! This isn't a Parachute, this is a Backpack!

Replies are listed 'Best First'.
Re: UML for PERL?
by dws (Chancellor) on Mar 26, 2001 at 23:33 UTC
    For an open source UML tool, I recommend that you acquiant yourself with ArgoUML. It's in Java, and requires Swing. A cool piece of work.

    There's more to UML than emitting code skeletons. I often use Visio when designing, mostly to draw Event Trace diagrams to describe protocols and walk through object interactions. Event traces are largely independent of implementation language. They work just as well with Perl as they do with Java (or whatever).

    The last experience I had generating code skeletons from diagrams wasn't particularly successful. We ended up extracting attributes from the diagrams, and automating the generation of (skeletal) class definitions and accessors. Strictly one-way, and, in hindsite, barely worth the effort.

      Beware of ArgoUML. It's broken in important ways (object ID's get lost, property pages don't work, it loses your drawings, etc. etc.). I used it for the beginnings of a project (twice, with 0.8 and 0.91) and stopped using it after it had lost my work (twice) and saved itself in a mode it wouldn't open. I was on the argouml mailing list for a while, and the developers there seem to be banging away on their different corners without getting a handle on underlying design problems. Their UML parser comes from a different group, and every time the UML parser changes, Argo breaks. I suspect that the design needs a serious re-thinking.

      (I wrote a Perl script that will diagnose broken Object ID's in Argo output files, if anyone's interested)

      If you want a resonably stable diagramming tool that outputs a parseable file format, you might look at TCM (though it only runs on Unix systems under X Windows).

      My approach to this was to write my own UML editor in Squeak. If you have Squeak, you can get a taste of this editor by looking at the NK-ConnectorsDemo.056.pr project on Bob's Super Swiki (via the FIND button in the Squeak Project Navigator).

      I am building this into a real product. I am, however, unclear as to exactly what support I could provide for Perl in it. Perhaps someone has some suggestions.

      I have also built a Perl module for accessing Rational Rose models via its OLE Automation interface; if you're interested, contact me.

Re (PotPieMan): UML for PERL?
by PotPieMan (Hermit) on Mar 26, 2001 at 22:30 UTC
    In my opinion, Unified Modeling Language (UML) is useful only for really large projects where object relationships must be clearly defined from the very beginning. In (my) reality, object relationships change. (This is quite contrary to the opinion of my computer science department, where they require UML diagrams for even the simplest projects. I'm talking Java programs that draw a square to the screen.)

    I personally don't do any projects that justify the use of UML--in any language. Nonetheless, I found ArgoUML, which appears to be an open source UML development tool written in Java. You might be able to extend it to generate Perl code skeletons (it claims to be "modular and extensible").

    Hope this helps.

    --PotPieMan

      Brother, I don't understand. I mean, certainly you are entitled to your opinion. But isn't one of the precepts of programming that you do your planning properly up front?

      In (my) reality, object relationships change.

      If you take the time to plan out your project from the beginning, you should be able to reduce the amount of coding time, by skipping the "throwaway" prototype phase. Are you talking about their relationships changing with subsequent versions or during the initial development cycle?

      I mean I suppose it depends on what you're doing. CGI's for example, benefit very little from UML, but then I don't write CGI's using OOPERL. That's just me...

      I don't know that a project has to be very big to benefit from a decent UML tool either. I for one, mostly use UML to build code skeletons for Java. I was thinking that it might be nice to have a tool that could do the same for me in PERL. That's all. Call me lazy, but laziness can be a virtue too.



      Wait! This isn't a Parachute, this is a Backpack!
        Planning from the start involves having a good spec. Demanding this is a case of making life easy for the developer at the cost of making it impossible for the customer. Thereby giving both sides plenty to complain about.

        People typically are unable to envision the consequences of the spec they hand you without the feedback of seeing how it would work. With a rigid product cycle this leads to the classic conflict where the developers complain that the spec is incomplete and changing, and the clients complain that the developers do not understand what they want and are unresponsive to their needs. And they are both right. The spec is changing and that is a real problem for the developers. But human and fallible clients are unable to give you a decent spec 18 months out, things change!

        Various incremental design techniques exist that try to get a rapid feedback cycle. A little more is specified, a little more is developed. Clients try it out and can figure out what they want added. Developers aim to have a design that can be readjusted and refactored.

        This strategy is emphatically not a question of not taking time out to plan the project. Rather it is a question of intentionally using design strategies that have evolved to avoid the classic problems that come with more rigid strategies.

        And yes, I have seen this kind of thinking applied (OK applied slightly hapazardly) to reasonably complex CGI projects that were based on a backend that deliberately had a lot of OO in it. (Well it didn't up front, but after a few iterations it did. :-)

Re: UML for PERL?
by Beatnik (Parson) on Mar 27, 2001 at 15:27 UTC
    Dia does UML, and is OpenSource but AFAIK it doesn't parse perl code... it does load up XML so if you can somehow convert it, it shouldn't be a problem.

    Greetz
    Beatnik
    ... Quidquid perl dictum sit, altum viditur.

      Yeah, I'm writing an XML to Perl1. um thingy that takes an XML init file to say what elements relate to what functions in the second XML file. Since Dia can output to XML IIRC, it should be possible to create Perl from Dia, albeit a round-about route.

      Although for my two-penneth, generated Perl is a bad idea2, generated C,C++, Python or Java are okay, because you have to write loads of stuff in those languages anyway.

      1. Yes this is generated Perl code, but it's not for me, it's for clients ;-)
      2. If you worked at Oven UK and see that as a major U-Turn, what can I say? I know better now.

      --
      
      Brother Frankus.
        Dia2Code exists (as well as AutoDia if one is interested in round-trip): should be easy enough to add a Perl "plugin" for it.
Re: UML for PERL?
by coreolyn (Parson) on Mar 27, 2001 at 19:58 UTC

    I've been having to do java code via a product called togethersoft which is an IDE/UML/XML roundtrip editor (Definately NOT Open Source). As I've learned to hack without any University Enducation I've always laughed at flow charts, but UML is a whole new ball game. It's allowing me to get my code to communicate at a different level as well as teaching me to visualize what I'm working on in a way others think it.

    Writing a Perl/UML tool in java would not be the wrong choice. It would be a huge challenge given the 'loose coupling' of Perl OO, but from what I've seen it would bring more legitimacy to Perl as a corporate tool. I'm seeing where Perl and Java could have a symbiotic relationship. Java needs Perl for Application management and distribution, using Java to make a Perl app doesn't seem like too big of a sin *g*.

    An interesting side note the togethersoft people use SLASHcode for their community site.

    coreolyn