Standalone Python functions in UML?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Roman Susi

    Standalone Python functions in UML?

    Hi!

    Out of curiosity, how do I draw functions outside classes with UML? How
    module could be drawn in this case?

    More theoretical question is if I create classes on the fly, how UML can
    reflect that?

    (I know that Python code itself is best at communication design ideas,
    but there are some people which prefer to talk UML.)

    (Have not found anything relevant with google)

    Thanks!

    Regards,
    Roman Suzi

  • Ravi Teja

    #2
    Re: Standalone Python functions in UML?

    >> Out of curiosity, how do I draw functions outside classes with UML? How
    module could be drawn in this case?

    As a utility class.
    [color=blue][color=green]
    >> More theoretical question is if I create classes on the fly, how UML can[/color][/color]
    reflect that?

    "On the fly" usually means "at runtime". I guess you mean if you
    "change code" will my diagram stay in sync?. You will have to use round
    trip tools. I don't know any tool supports round trip for Python code.
    But if you just mean reverse engineering, lookup PyNSource, Boa
    Constructor, PyReverse among others
    [color=blue][color=green]
    >> (I know that Python code itself is best at communication design ideas,[/color][/color]
    but there are some people which prefer to talk UML.)

    Actually no. Python is a good tool for "prototypin g" which is not the
    same as "communicat ing design ideas". Diagrams are better for the later
    and do not need to be executable. At least from what I know, except
    Eiffel, no language makes that claim. UML is really the only contender
    currently for design notation.

    Comment

    • Rob Cowie

      #3
      Re: Standalone Python functions in UML?


      Roman Susi wrote:[color=blue]
      > Hi!
      >
      > Out of curiosity, how do I draw functions outside classes with UML? How
      > module could be drawn in this case?[/color]

      I would say that within a class diagram, you can't. In other UML
      diagrams (such as sequence interaction), the function is simply used as
      if it were a method belonging to an object. If you need to make it
      clear where this function is located within the code, use a note on the
      diagram.

      Remember, UML is not able to accurately capture all implementation
      details of a system; It's not meant to.
      [color=blue]
      >
      > More theoretical question is if I create classes on the fly, how UML can
      > reflect that?[/color]

      Again, don't try to depict fine-grained implementation details. If the
      dynamically generated class is important to the class diagram, include
      it but don't include all of it's internals (methods etc.). Use a note
      to exaplin how/when/why it is generated.
      [color=blue]
      >
      > (I know that Python code itself is best at communication design ideas,
      > but there are some people which prefer to talk UML.)
      >
      > (Have not found anything relevant with google)
      >
      > Thanks!
      >
      > Regards,
      > Roman Suzi[/color]

      Rob C

      Comment

      • Philippe Martin

        #4
        Re: Standalone Python functions in UML?

        Roman Susi wrote:
        [color=blue]
        > Hi!
        >
        > Out of curiosity, how do I draw functions outside classes with UML? How
        > module could be drawn in this case?
        >[/color]
        I'm not up to par on the latest UML specs (or not too old) - but I don't
        believe UML handles that: it is called a class diagram after all.
        [color=blue]
        > More theoretical question is if I create classes on the fly, how UML can
        > reflect that?[/color]

        You mean objects I think: by using a 0..n in you agregation ?
        [color=blue]
        >
        > (I know that Python code itself is best at communication design ideas,
        > but there are some people which prefer to talk UML.)
        >
        > (Have not found anything relevant with google)
        >
        > Thanks!
        >
        > Regards,
        > Roman Suzi[/color]

        Regards,

        Philippe

        Comment

        • bruno at modulix

          #5
          Re: Standalone Python functions in UML?

          Ravi Teja wrote:
          (snip)[color=blue][color=green][color=darkred]
          >>>More theoretical question is if I create classes on the fly, how UML can[/color][/color]
          >
          > reflect that?
          >
          > "On the fly" usually means "at runtime". I guess you mean if you
          > "change code" will my diagram stay in sync?.[/color]

          Nope, the OP really meant "on the fly", as in "at runtime". In python,
          it is possible to create new classes at runtime. Remember,
          everything-is-an-object implies that classes are objects too.

          --
          bruno desthuilliers
          python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
          p in 'onurb@xiludom. gro'.split('@')])"

          Comment

          • bruno at modulix

            #6
            Re: Standalone Python functions in UML?

            Philippe Martin wrote:[color=blue]
            > Roman Susi wrote:
            >[/color]
            (snip)
            [color=blue][color=green]
            >>More theoretical question is if I create classes on the fly, how UML can
            >>reflect that?[/color]
            >
            >
            > You mean objects I think:[/color]

            Yes : class objects !-)

            Python's classes *are* objects. And you can create new classes at runtime.

            (snip)
            --
            bruno desthuilliers
            python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
            p in 'onurb@xiludom. gro'.split('@')])"

            Comment

            • Roman Susi

              #7
              Re: Standalone Python functions in UML?

              Ravi Teja wrote:[color=blue][color=green][color=darkred]
              >>>Out of curiosity, how do I draw functions outside classes with UML? How[/color][/color]
              >
              > module could be drawn in this case?
              >
              > As a utility class.[/color]

              So, function could be a utility class method. If there are no better ways.
              [color=blue][color=green][color=darkred]
              >>>More theoretical question is if I create classes on the fly, how UML can[/color][/color]
              >
              > reflect that?
              >
              > "On the fly" usually means "at runtime". I guess you mean if you
              > "change code" will my diagram stay in sync?. You will have to use round
              > trip tools. I don't know any tool supports round trip for Python code.
              > But if you just mean reverse engineering, lookup PyNSource, Boa
              > Constructor, PyReverse among others[/color]

              No. I do not need it. I just want to know if UML is capable of doing it.
              [color=blue]
              >[color=green][color=darkred]
              >>>(I know that Python code itself is best at communication design ideas,[/color][/color]
              >
              > but there are some people which prefer to talk UML.)
              >
              > Actually no. Python is a good tool for "prototypin g" which is not the
              > same as "communicat ing design ideas". Diagrams are better for the later
              > and do not need to be executable. At least from what I know, except
              > Eiffel, no language makes that claim. UML is really the only contender
              > currently for design notation.[/color]

              Well, maybe SOL (Semantic Object Language) could also be quite
              beneficial in some cases. At least, it depends with whom to communicate
              design ideas and what level of formality to maintain.

              Also, my argument that Python is quite good at communicating design
              ideas is supported by the fact that Python developers do not use UML (or
              other modelling tools/languages) as often as say Java programmers, nor
              feel the need to. And probably Python is too dynamic for UML. That is
              another reason rountrip tools aren't there.

              --
              Roman

              Comment

              • Philippe Martin

                #8
                Re: Standalone Python functions in UML?

                But not in UML: a class diagram will represent classes while a sequence
                diagram objects.

                Philippe



                bruno at modulix wrote:
                [color=blue]
                > Philippe Martin wrote:[color=green]
                >> Roman Susi wrote:
                >>[/color]
                > (snip)
                >[color=green][color=darkred]
                >>>More theoretical question is if I create classes on the fly, how UML can
                >>>reflect that?[/color]
                >>
                >>
                >> You mean objects I think:[/color]
                >
                > Yes : class objects !-)
                >
                > Python's classes *are* objects. And you can create new classes at runtime.
                >
                > (snip)[/color]

                Comment

                • Ravi Teja

                  #9
                  Re: Standalone Python functions in UML?

                  > So, function could be a utility class method. If there are no better ways.

                  What I mean is <<utility>> is the formal notation for a class in which
                  global functions are aggregated. It's not a hack.
                  Python is not alone here. Most OO languages aside Java and Smalltalk
                  have functions outside classes and UML accomodates though not
                  encourages free functions.
                  [color=blue]
                  > Well, maybe SOL (Semantic Object Language) could also be quite[/color]
                  beneficial in some cases. At least, it depends with whom to communicate
                  design ideas and what level of formality to maintain.

                  I don't know what Semantic Object Language is. One important
                  requirement of choosing communication notations is that they should be
                  sufficiently popular that everyone understands. Kind of beats the
                  purpose if you are the only person who knows it. I got 146 hits on
                  Google for "Semantic Object Language" and UML. Too few for me to care.
                  If it is a deserving notation, hopefully that will change in the
                  future.
                  [color=blue]
                  > Also, my argument that Python is quite good at communicating design[/color]
                  ideas is supported by the fact that Python developers do not use UML
                  (or
                  other modelling tools/languages) as often as say Java programmers, nor
                  feel the need to.

                  I guess you and I mean VERY different things when we say "Design
                  Ideas". You seem to imply pseudo code. I mean overall archetecture. I
                  think Python devs will use UML tools if there are good ones available.
                  I know I would. I could really use a round trip class and package
                  diagram editor now.
                  [color=blue]
                  > And probably Python is too dynamic for UML. That is another reason rountrip tools aren't there.[/color]

                  As you probably already know, UML diagrams are structural and
                  behavioural (plus interactional with 2.0). Round trip tools only model
                  structural diagrams. Python is dynamic but only once the program starts
                  executing :-). Even though Python classes "can" change, they do so only
                  at runtime ( wouldn't it be scary if they decided to change as code
                  when you are not looking :-) ). So dynamism of Python should not be as
                  much of an issue. I think the reason we don't have good UML round trip
                  tools for Python is primarily a market issue rather than a language
                  issue. If Python gets the same market share as Java, it will surely get
                  all these tools and more.

                  Comment

                  • Marc 'BlackJack' Rintsch

                    #10
                    Re: Standalone Python functions in UML?

                    In <mailman.4054.1 144138640.27775 .python-list@python.org >, Roman Susi
                    wrote:
                    [color=blue]
                    > Out of curiosity, how do I draw functions outside classes with UML? How
                    > module could be drawn in this case?[/color]

                    I just create a (UML) class for modules. After all a Python module can be
                    seen as a class definition for a singleton which is instantiated at import
                    time.

                    Ciao,
                    Marc 'BlackJack' Rintsch

                    Comment

                    • bruno at modulix

                      #11
                      Re: Standalone Python functions in UML?

                      Ravi Teja wrote:
                      (snip)[color=blue]
                      >[color=green]
                      >> And probably Python is too dynamic for UML. That is another reason[/color]
                      > rountrip tools aren't there.
                      >
                      >
                      > As you probably already know, UML diagrams are structural and
                      > behavioural (plus interactional with 2.0). Round trip tools only model
                      > structural diagrams. Python is dynamic but only once the program starts
                      > executing :-). Even though Python classes "can" change, they do so only
                      > at runtime[/color]

                      Well, you can have a lot of things happening during the import stage. Is
                      this 'runtime' or not ?-)

                      And you can actually *create* (not 'change') classes at runtime too.
                      [color=blue]
                      > So dynamism of Python should not be as
                      > much of an issue.[/color]

                      Not so sure about this.

                      --
                      bruno desthuilliers
                      python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
                      p in 'onurb@xiludom. gro'.split('@')])"

                      Comment

                      • bruno at modulix

                        #12
                        Re: Standalone Python functions in UML?

                        Philippe Martin wrote:
                        <meta> please don't top-post - corrected</meta>
                        [color=blue]
                        > bruno at modulix wrote:
                        >
                        >[color=green]
                        >>Philippe Martin wrote:
                        >>[color=darkred]
                        >>>Roman Susi wrote:
                        >>>[/color]
                        >>
                        >>(snip)
                        >>
                        >>[color=darkred]
                        >>>>More theoretical question is if I create classes on the fly, how UML can
                        >>>>reflect that?
                        >>>
                        >>>
                        >>>You mean objects I think:[/color]
                        >>
                        >>Yes : class objects !-)
                        >>
                        >>Python's classes *are* objects. And you can create new classes at runtime.
                        >>
                        >>(snip)[/color]
                        >
                        > But not in UML: a class diagram will represent classes while a sequence
                        > diagram objects.[/color]

                        Yes, there's in UML a fundamental distinction between classes and
                        objects - distinction that does not exist in a lot of OO languages. This
                        greatly limits UML's usability for some common idioms in dynamic OOPL's.
                        Seems like UML has been designed to express only the restricted subset
                        of OO supported by rigid static languages like C++, Java and ADA.

                        My 2 cents
                        --
                        bruno desthuilliers
                        python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
                        p in 'onurb@xiludom. gro'.split('@')])"

                        Comment

                        • Ravi Teja

                          #13
                          Re: Standalone Python functions in UML?

                          > Well, you can have a lot of things happening during the import stage. Is
                          this 'runtime' or not ?-)

                          Runtime.
                          [color=blue]
                          > And you can actually *create* (not 'change') classes at runtime too.[/color]

                          Yes sir! By now I am quite well aware what 'dynamic typing' means. Once
                          again, round trip tools today model program structure/code/text, not
                          runtime magic - all the stuff a dynamically typed language such as
                          Python does differently from statically typed languages like Java. So
                          this does not affect them much.

                          Languages like Python with metaclasses and other dynamic aspects do
                          present an interesting case for modelling but what I am talking about
                          is round trip tools, not the full scope of modelling and UML. Round
                          trip implementations today get at class and package diagrams
                          (structural), not object diagrams and collaboration diagrams. Class and
                          Package diagrams are concerned with the layout, not intricate runtime
                          behaviour, mutations and mutilations of classes and packages. That
                          would be the domain of behavioural diagrams of which I made no
                          assertions. There isn't much magical about Python as far as code layout
                          is concerned. Metaclasses can for example change the very behaviour of
                          the class construct but modelling that is not the purpose of a class or
                          package diagram.

                          Rather than going hypothetical and us miscommunicatin g in the abstract
                          plane, could you just tell me why you could not draw a class or package
                          diagram for your last project? That will probably make me see what I am
                          missing from your points.

                          Comment

                          • Ben Sizer

                            #14
                            Re: Standalone Python functions in UML?

                            Ravi Teja wrote:[color=blue]
                            > What I mean is <<utility>> is the formal notation for a class in which
                            > global functions are aggregated. It's not a hack.
                            > Python is not alone here. Most OO languages aside Java and Smalltalk
                            > have functions outside classes and UML accomodates though not
                            > encourages free functions.[/color]

                            It doesn't seem to sit well with the common Python idiom of having
                            several free functions packaged in a module, sadly.
                            [color=blue]
                            > Python is dynamic but only once the program starts
                            > executing :-). Even though Python classes "can" change, they do so only
                            > at runtime ( wouldn't it be scary if they decided to change as code
                            > when you are not looking :-) ). So dynamism of Python should not be as
                            > much of an issue.[/color]

                            But on a similar note, I was wondering about classes such as
                            BaseHTTPServer where the function to be called is looked up by name,
                            and may or may not exist, or the situation where multiple function
                            calls with similar signatures can be redirected to one using some
                            getattr trickery - these don't seem to play well with the static nature
                            of UML. (Or editor auto-completion, or cross-referencing code in an
                            IDE...) I tend to shy away from such constructs for these reasons.

                            --
                            Ben Sizer

                            Comment

                            • Nicola Musatti

                              #15
                              Re: Standalone Python functions in UML?


                              Roman Susi wrote:
                              [...][color=blue]
                              > Also, my argument that Python is quite good at communicating design
                              > ideas is supported by the fact that Python developers do not use UML (or
                              > other modelling tools/languages) as often as say Java programmers, nor
                              > feel the need to. And probably Python is too dynamic for UML. That is
                              > another reason rountrip tools aren't there.[/color]

                              Another reason is probably the problem you started this thread with;
                              UML class diagrams are very much centered around Java style object
                              orientation. Other paradigms, like the procedural and the generic ones,
                              do not fit well. Nor is it well suited to represent the shift to a meta
                              level that is involved when you start creating types at execution time.

                              Cheers,
                              Nicola Musatti

                              Comment

                              Working...