in reply to Perl UML conventions

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

Replies are listed 'Best First'.
Re: Re: Perl UML conventions
by gildir (Pilgrim) on May 17, 2001 at 16:23 UTC
    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.

[reply]
      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.

[reply]

In Section Seekers of Perl Wisdom