http://www.perlmonks.org?node_id=81185

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

Fellow monks,

I have decided to start documenting my project at last and was hoping to use UML class diagrams for visualization of class relations in my code. But I just can't figure up how I should write perl function prototypes and data types into UML class diagram.

Let's have method foo:

sub foo { my ($self,$date,$message,$opt_args) = @_; ..... return $sucess; }
Which one of these should I use?
  1. +foo(date: scalar, message: scalar, opt_args: hashref): scalar
  2. +foo($date: Date, $message: String, $opt_args: Hash): boolean
  3. +foo($date: String, $message: String, $opt_args: \Hash): boolean
... or none of these, any of these, combination of these?

And things starts to get even more weird when 'standard' OO constructor calling convention takes place:

sub new { my ($class,%args) = @_; ... my $foobar = $args{foo} . $args{bar}; # Whatever ... }
Should this be written as new(%args: Hash): \Class or new(foo: String, bar: String): Class or just new(args: Hash)?

Please, help poor confused monk to find a stream of light in darkness. Any suggestion appreciated.

Replies are listed 'Best First'.
Re: Perl UML conventions
by Beatnik (Parson) on May 17, 2001 at 14:01 UTC
    checkout AutoDia which can parse perl code into Dia parseable XML. Dia itself can generate the UML schemes you need.

    Greetz
    Beatnik
    ... Quidquid perl dictum sit, altum viditur.
      Here are the latest links to the AutoDia website:-

      http://www.aarontrevena.co.uk/opensource/autodia

      and its metacpan page.
        I tried autodia. It only generates OO diagrams and does nothing for procedural code.
Re: Perl UML conventions
by jorg (Friar) on May 17, 2001 at 15:58 UTC
    UML is not there to be strictly adhered to it. You should pick out the bits and pieces that you need and apply those in a sensible way.
    The most important thing is that you make it clear to people what you're doing. Each of the function prototypes you looked at there clarify what the function expects as argument structure (the first one being a bit more clear in 'perl terms').
    Keep in mind that methodologies are there to help you in design and documentation. You won't get frowned upon when bending the rules a bit to fit your own project. Clarity before all !!

    Jorg

    "Do or do not, there is no try" -- Yoda
      Well, but if there is an existing (and commonly recognised) way of expressing Perl function prototypes and data structures in UML, I should rather use it.
      It will be nice if we all follow the same standard as we can easily understand each other. This is the motivation behind 'Unified' in 'Unified Modeling Language' and behind all the conventions that Perl programmers tend to follow without being enforced to.

      So I would rather find a standard/convetion of expressing Perl in UML and get used to it than invent my very own "standard". Or at least I would ask for "common wisdom" on which way to choose.

        So who is up for creating puml? It would be pretty handy to have as a subliment to perldoc.

        AutoDia exists, so I would imagine it wouldn't be too hard to modify AutoDia to output eps, or some other standard format, instead of dia. Just imagine firing up your favorite ide and automatically getting uml for all your objects and such.

Re: Perl UML conventions
by gregor42 (Parson) on May 17, 2001 at 18:49 UTC

    Though I have been checking, thus far I have not been able to find a 'standard' way of implementing UML as PERL code or vice/versa.

    Generally speaking though, UML is usually used at the beginning of a project, before you have code. This is by no means a hard & fast rule because, of course, if you are picking up a project from where someone else left off, or any one of a dozen other situations you will have code first. But the point here of course is about visualization & planning of your project.

    Personally, I use UML often when doing Java projects. But I mostly take advantage of it to use something like Rational Rose ($ack$) or ObjectPlant (Mac only )-: ) to build code skeletions. It's also a very good documentation method, or at least a place to start your development docs.

    There are some tools that you can use to help, or at least give you a push in the right direction, such as Dia or togethersoft but to tell the truth, there's nothing that I have discovered which is a complete UML IDE for any language yet. (..and some of those tools are very expensive.)

    I see a lot of space here to break new ground.

    I am and have been personally interested in building a toolkit that would be more complete & that would generate PERL code as well, but it's a BIG job, so right now it's still a '| dream'... Of course anyone interested, please /msg me, or send me e-mail.



    Wait! This isn't a Parachute, this is a Backpack!
Re: Perl UML conventions
by thargas (Deacon) on Mar 02, 2015 at 18:44 UTC