Python2UML

[DonnerCobra]

Hallo,

ich bin verzweifelt auf der Suche nach einem Python2UML Converter. Ich weiß, bei Laufzeit können Klassen und Objekte verändert werden, aber das außen vor.

Hat jemand eine Ahnung wo ich einen solchen Converter herbekomme (was auch noch mit Py2.6.3 funktioniert und nicht 400 Abhängigkeiten hat) das Python Code in ein UML Diagramm umwandelt?


Ich dake euch. Bis dann,

donnerCobra

[lunar]

@DonnerCobra: Die Möglichkeit der Veränderung von Klassen zur Laufzeit wäre noch das geringste Problem. Wer macht das schon? Viel schwerer wiegt, dass UML keine Ahnung von Funktionen und dergleichen hat. Jeder Quelltext, der Funktionen für einen noch so geringen Teil an wirklicher Funktionalität nutzt, kann durch UML nur unzureichend abgebildet werden.

Ähnliches gilt beispielsweise für Klassenmethoden. Auch die gibt es in UML nicht.

[DonnerCobra]

Mir würde ein reines Klassendiagramm völlig ausreichen (ohne jegliche Member).

[ms4py]

Ähnliches gilt beispielsweise für Klassenmethoden. Auch die gibt es in UML nicht.

Können aber genauso gut als statische Methoden notiert werden, so korrekt muss man auch wieder nicht sein.

Außerdem kann UML durch eigene Stereotypen an Python problemlos angepasst werden. Was spricht gegen den Klassen-Stereotypen "module" mit Funktionen als statische Methoden?

So einen Konverter kenne ich allerdings nicht. Aus SE-Sicht wäre eine Konverter in die andere Richtung (UML->Python) allerdings auch viel sinnvoller.

[pillmuncher]

Ein weiteres Problem besteht IMO darin, dass UML Duck Typing nicht so recht ausdrücken kann. Grad hab ich mir PyUML für Eclipse installiert, und AFAICS findet es zwar Vererbungsbeziehungen, aber keine Containmentbeziehungen. Ausprobiert hab ich es mit meinem Prolog-Interpreter. Da gibt es eine Klasse CompoundRule, die Terme der zB. Form foo(A,B) :- goal1(A), goal2(A,B) repräsentieren soll. Dazu besitzt sie eine Liste mit Parametern und eine mit Goals, die aber von außen, dh. vom Compiler befüllt werden. Es gibt zwar die Methoden add_param(p) bzw. add_goal(g), aber dass p bzw. g Terme sein müssen, geht aus dem Quelltext nicht hervor, und damit auch nicht, dass die Parameter- und Goal-Listen nur Terme enthalten. Solcherlei typisierte und mit der entsprechenden Kardinalität dargestellte Beziehungen machen ein UML-Tool nützlich, einen reinen Vererbungsgraphen kann ich mir auch von Hand zeichnen.

Kurz gesagt also, wenn dir Vererbungsgraphen genügen, versuch es mal mit PyUML (Eclipse vorausgesetzt), alles andere bleibt nur Handarbeit, und ich vermute, dass es auch bei anderen Py --> Uml Werkzeugen so ist.

Gruß,
Mick.

PS 1: PyUML scheint mit with statements noch nicht zurechtzukommen. Es kann sie vermutlich verstehen, will aber, dass man ein "from __future__ import with_statement" einfügt, was aber, in 2.6.2 wenigstens, ziemlich unsinnig ist.

PS 2: Vorsicht, es ändert eigenmächtig den source code indem es Kommentare einfügt und zumindest bei mir

Code: Alles auswählen

class RefTest(unittest.TestCase):
    ...

dahingehend geändert hat:

Code: Alles auswählen

class RefTest(TestCase):
    ...

Sowas mag ich gar nicht.

[lunar]

@DonnerCobra: Einfache Vererbungsdiagramme kann man leicht zeichnen, in dem man die Module lädt, nach Klassen durchsucht, und deren Vaterklassen nach oben durchsucht. Daraus kann man dann einfach Graphviz-Graphen generieren. Sphinx beispielsweise bietet eine Erweiterung für Vererbungsdiagramme, die so funktioniert.

@ice2k3: Statische Methoden sind etwas anderes als Klassenmethoden. Ob das relevant ist, hängt vom Diagramm ab. Dynamische Methoden verhalten sind in Vererbungshierarchien jedenfalls anders als statische Methoden.

Gegen einer Darstellung von Modulen als Klassen spricht, dass Module nun mal keine Klassen sind. Es gibt beispielsweise keine Vererbungshierarchien zwischen Modulen.

Eine Konvertierung in umgekehrter Richtung (UML->Python) ist auch nicht sinnvoll. In UML kann man nur Typen, aber keine Protokolle modellieren. Damit verschließt man sich die gesamten Möglichkeiten dynamischer Typisierung.