Topic: http://www.python-forum.de/topic-8629.h ... hlight=24h
Besteht Interesse zu so einem Programm?
lg
EDIT: Genaue Beschreibung im Post 4 von diesem Thread.
PySource2UML -> Umfrage!
UML den datenbankdesignern und javanern.
fuer *beliebige sprachen* koennte man etwas gebrauchen, was die grobe struktur visualisiert, als schnelluebersicht. aber ob das unbedingt in *UML* sein muss (denn tool-intern ist das wurscht, ob du s-expressions oder binaerstrukturen benutzt)
na ich weiss ja nicht...
fuer *beliebige sprachen* koennte man etwas gebrauchen, was die grobe struktur visualisiert, als schnelluebersicht. aber ob das unbedingt in *UML* sein muss (denn tool-intern ist das wurscht, ob du s-expressions oder binaerstrukturen benutzt)
na ich weiss ja nicht...
...meh...
@cracki:
0o -> http://de.wikipedia.org/wiki/Klassendiagramm
UML:
0o -> http://de.wikipedia.org/wiki/Klassendiagramm
Code: Alles auswählen
class foo(object):
pass
class bar(foo):
pass
BTW: Erstmal ist nur die Umsetzung von Klassendiagrammen geplant als UML. Dort wird es möglich sein, neben den Klassenvererbungen (wie auf dem Bild) auch Attribute der Klassen anzuzeigen, und auch Docstrings der Klassen bzw. Attribut Beschreibungen die in reSTR (-> #: Diese Atribut...)geschrieben sind. Selbstverständlich lassen sich Docstrings und Attribute ausblenden, damit es nicht überladen aussieht Das ist vorerst geplant.
Hier mal eine Übersicht was für ein Klassendiagram alles nacher anzeigbar sein wird.
Übersicht:
Paketdiagramm sind in Späteren Versionen auch geplant: http://de.wikipedia.org/wiki/Paketdiagramm
Alle anderen Diagramtypen von UML wird es wahrscheinlich nicht geben, da die Realisierung wohl ein wenig schwierig wird und mMn auch unnötig ist.
...
Wie dem Titel zu entnehmen soll also eine Python-Quellendatei geladen werden aus dem das Programm dann selbständig ein Klassendiagramm erzeugt
lg
P.S.: Bevor ich mich aber an die Arbeit mache, will ich erstmal die Ergebnisse dieser Umfrage abwarten. Schließlich soll das ein Projekt werden an dem mehrere Leute interessiert sind.
Hier mal eine Übersicht was für ein Klassendiagram alles nacher anzeigbar sein wird.
Übersicht:
- Anzeigbare Attribute und Methoden jeder Klasse. Per Knopfdruck lassen sich die wenn gewünscht auch ausblenden und wider einblenden.
- Es wird eine Sichtbarkeitskenzeichnung von Methoden und Attributen geben.
"+" für public
"#" für protected
"-" für private
Auch das lässt sich ein und ausblenden. - Zu jeder angezeigten Klasse lassen sich Docstrings ein- und ausblenden (das ist erst später geplant. Vorerst wird es das nicht geben).
- Atrtributs und Methodenbeschreibungen lassen sich ein- und ausblenden (das ist erst später geplant. Vorerst wird es das nicht geben).
Paketdiagramm sind in Späteren Versionen auch geplant: http://de.wikipedia.org/wiki/Paketdiagramm
Alle anderen Diagramtypen von UML wird es wahrscheinlich nicht geben, da die Realisierung wohl ein wenig schwierig wird und mMn auch unnötig ist.
...
Wie dem Titel zu entnehmen soll also eine Python-Quellendatei geladen werden aus dem das Programm dann selbständig ein Klassendiagramm erzeugt
lg
P.S.: Bevor ich mich aber an die Arbeit mache, will ich erstmal die Ergebnisse dieser Umfrage abwarten. Schließlich soll das ein Projekt werden an dem mehrere Leute interessiert sind.
Ich finde UML in Verbindung mit Python auch nicht so toll. Sollte man wirklich den Javaianern überlassen. Das ist ein überspezifiziertes "Monster". UML 1.0 hat schon keiner so wirklich verstanden und richtig angewendet.
Ausserdem ist alles so typisch klassenzentriert auf Java zugeschnitten. So etwas wie Module oder Funktionen, die auch Objekte sind, sind nicht wirklich vorgesehen. Und wie man Metaklassen in UML unterbringt, ist mir auch nicht so ganz klar.
Bestehende Projekte wären wohl diverse Python-IDEs, PyUT und Gaphor. Man könnte auch einen Python-Quelltext nach XMI Konverter schreiben und jedes UML-Tool benutzen das XMI lesen kann. Zur Analyse von Python-Quellen gibt's sicher einiges in den Quelltexten von PyLint.
Ausserdem ist alles so typisch klassenzentriert auf Java zugeschnitten. So etwas wie Module oder Funktionen, die auch Objekte sind, sind nicht wirklich vorgesehen. Und wie man Metaklassen in UML unterbringt, ist mir auch nicht so ganz klar.
Bestehende Projekte wären wohl diverse Python-IDEs, PyUT und Gaphor. Man könnte auch einen Python-Quelltext nach XMI Konverter schreiben und jedes UML-Tool benutzen das XMI lesen kann. Zur Analyse von Python-Quellen gibt's sicher einiges in den Quelltexten von PyLint.
Auf UML bezogen oder generell Projekte? Wenn ich was zu "Python-Quellendatei zu UML-Klassendiagram" gefunden hätte würde ich sicherlich nicht so ein Projekt starten. So ein Programm gibt es aber nicht.cracki hat geschrieben:hast du nach bestehenden projekten gesucht?
Jack, es geht doch nicht darum das ganze UML umzusetzen. Es geht doch nur um simple Klassendiagramme und um mehr nichtBlackJack hat geschrieben:[...]Das ist ein überspezifiziertes "Monster". UML 1.0 hat schon keiner so wirklich verstanden und richtig angewendet.
ja das ist mir auch schon aufgefallen, das man Funktionen nicht abbilden kann bzw. nicht in den specs sind. Aber Module sind kein Problem -> Packages. Ob das Package ein Modul oder eben ein Python "Package", ist irrelevant.BlackJack hat geschrieben: [...]So etwas wie Module oder Funktionen, die auch Objekte sind, sind nicht wirklich vorgesehen. Und wie man Metaklassen in UML unterbringt, ist mir auch nicht so ganz klar.
XMI? Was ist das? Meinst du das hier -> http://de.wikipedia.org/wiki/XMIBlackJack hat geschrieben:Man könnte auch einen Python-Quelltext nach XMI Konverter schreiben und jedes UML-Tool benutzen das XMI lesen kann.
Dafür habe ich doch schon meinen Parser der rudimentäre alles in nem AST abbildet Mehr als Klassenname, Attribute und Methoden und die Vererbung muss man ja nicht auswerten und das ist ziemlich simple EDIT: selbst import statements sind kein Problem. Auswerten, Laden und "anfügen".BlackJack hat geschrieben: Zur Analyse von Python-Quellen gibt's sicher einiges in den Quelltexten von PyLint.
*eineböseideehab* Warum erfinden wir nciht einfah selber was das zu Python passt? Das Klassendiagramm Schema kann man schon zu ca. 60% Übernehmen (Dies ganze Datentyp Sache kann man ehe weglassen). Dann noch irgendwas überlegen für Objekte und Funktionen Dann was ausdenken um die Beziehungen zwischen den Elementen darzustellen. Blöde Idee?sape hat geschrieben:ja das ist mir auch schon aufgefallen, das man Funktionen nicht abbilden kann bzw. nicht in den specs sind. Aber Module sind kein Problem -> Packages. Ob das Package ein Modul oder eben ein Python "Package", ist irrelevant.BlackJack hat geschrieben: [...]So etwas wie Module oder Funktionen, die auch Objekte sind, sind nicht wirklich vorgesehen. Und wie man Metaklassen in UML unterbringt, ist mir auch nicht so ganz klar.
Ja das meinte ich.sape hat geschrieben:XMI? Was ist das? Meinst du das hier -> http://de.wikipedia.org/wiki/XMIBlackJack hat geschrieben:Man könnte auch einen Python-Quelltext nach XMI Konverter schreiben und jedes UML-Tool benutzen das XMI lesen kann.
Ziemlich simpel?Dafür habe ich doch schon meinen Parser der rudimentäre alles in nem AST abbildet Mehr als Klassenname, Attribute und Methoden und die Vererbung muss man ja nicht auswerten und das ist ziemlich simple EDIT: selbst import statements sind kein Problem. Auswerten, Laden und "anfügen".BlackJack hat geschrieben: Zur Analyse von Python-Quellen gibt's sicher einiges in den Quelltexten von PyLint.
Code: Alles auswählen
import sys
if sys.platform.startswith('win'):
import winspam as spam
else:
import realspam as spam
eggs = __import__(spam.eggs_name())
class A(object):
def __init__(self, arg):
self._attr = arg
def __str__(self):
return 'A %s' % self.attr
def _get_attr(self):
return '<%s>' % self._attr
attr = property(_get_attr)
to_string = __str__
def spam(self):
print 'hello I am of class', self.__class__.__name__
B = type('C', (A,), { 'greet': spam })
class C(object):
pass
Module würde ich übrigens eher als Klassen modellieren. Sie werden ab und zu ja auch als Singletons benutzt.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ich habe für "Nein" gestimmt. Warum? Weil ich den Sinn von so etwas nicht sehe. Schön, da habe ich dann ein Klassendiagramm, welches aber Aufgrund der Dynamik von Python stimmen kann, oder aber auch sehr falsch sein kann. BlackJack hat ja schon angesprochen, dass sich einige Sachen in UML nicht darstellen lassen. Mir ist auch unklar, wie es mit den dynamisch erstellen Attributen aussieht. Zum Beispiel kann man durchaus Klassen haben, deren Attribute erst erstellt werden, wenn auf sie zugegriffen wird und danach wieder verschwinden. __getattr__ und __getattribute__ sind in dieser Hinsicht ein gutes Werkzeug um das Klassendiagramm sinnlos zu machen.sape hat geschrieben:*eineböseideehab* Warum erfinden wir nciht einfah selber was das zu Python passt? Das Klassendiagramm Schema kann man schon zu ca. 60% Übernehmen (Dies ganze Datentyp Sache kann man ehe weglassen). Dann noch irgendwas überlegen für Objekte und Funktionen Dann was ausdenken um die Beziehungen zwischen den Elementen darzustellen. Blöde Idee?
Andererseits ist es sicher lustig ein paar Kästchen zu haben in denen die Klassennamen geschrieben sind und die mit Pfeilen verbunden sind. Aber wie soll mir das beim Programmieren helfen? Ich kann auch in die Deklarationszeile eier Klasse schauen und dann bin ich auch so schlau. Für die Dokumentatiion nehme ich sowieso help() oder IPythons ``??``-Werkzeug.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
OK Leo und Jack, wenn da kein Interesse besteht, stecke ich da meine Energie auch nicht weiter rein und Schmeiße dann alles in den Papierkorb Das entprodukt sollte nacher halt Klassen- und Packagediagramme darstellen und auch eine _vernümftige_ Metrik von einem Quellcode anzeigen, wo nicht nur angezeigt wird wieviel Code, Docstrings, Blanks im ganzen Sourcecode vorhanden sind, sonder angezeigt wird wieviel eine Klasse vom genannte hat deren Methoden, Funktionen...Egal. Der Mülleimer wird sich mal wider freuen ^^
lg und danke für das ehrliche Feedback cracki, Jack und Leo
sape
Ja Erste Testläufe brachten erwartet Ergebnisse Aber egal, Thema erledigt.BlackJack hat geschrieben: Ziemlich simpel?
lg und danke für das ehrliche Feedback cracki, Jack und Leo
sape
Daher auch die Frage in meine Zitat, das du Zitiert hast, wegen eines eigenen neuen Format das auf Python zugeschnitten ist.Leonidas hat geschrieben: BlackJack hat ja schon angesprochen, dass sich einige Sachen in UML nicht darstellen lassen.
Hast du dir mal z.B. die Klassenhirachie von Epidoc angesehen? 0o -> Ich finde das sehr hilfreich, dass in der Dokumentation auch Klassendiagramme/Packagediagramme benutzt werden. Gerade für außenstehende ist es so einfacher zu sehen was aufeinander aufbaut um die API zu verwenden...Leonidas hat geschrieben: Andererseits ist es sicher lustig ein paar Kästchen zu haben in denen die Klassennamen geschrieben sind und die mit Pfeilen verbunden sind. Aber wie soll mir das beim Programmieren helfen? Ich kann auch in die Deklarationszeile eier Klasse schauen und dann bin ich auch so schlau. Für die Dokumentatiion nehme ich sowieso help() oder IPythons ``??``-Werkzeug.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Naja, die "Ja"-Wertungen sind in der überzahl, nur haben die die für "Nein" gestimmt haben ihre Argumente dagegen gepostet.sape hat geschrieben:OK Leo und Jack, wenn da kein Interesse besteht, stecke ich da meine Energie auch nicht weiter rein und Schmeiße dann alles in den Papierkorb
Löst das Problem aber nicht. Metaprogrammierung kann nicht ohne weiteres dargestellt werden. Ein anderes Problem ist eben, dass Code in Python oft erst zur Ausführzeit vorhersehbar ist. Wenn eine Klasse ein Attribut nicht im Quellcode hat, muss es nicht heißen, dass es dieses Attribut nicht irgendwann zur Ausführzeit haben wird.sape hat geschrieben:Daher auch die Frage in meine Zitat, das du Zitiert hast, wegen eines eigenen neuen Format das auf Python zugeschnitten ist.Leonidas hat geschrieben: BlackJack hat ja schon angesprochen, dass sich einige Sachen in UML nicht darstellen lassen.
Nein, habe ich nicht. Also das heißt nur mal zum interessehalber, nachdem jemand eine solche schon generiert hat. Habe dafür nie Bedarf gehabt. Das einzige was ich bisher genutzt habe, sind die simplen Vererbungsgraphen der PyGTK-Dokumentation und das auch nur, um zu sehen in welcher Ebene ein Attribut definiert wurde. Sonst ist es nicht nötig gewesen. Die Python-Dokumentation hat so einen Graphen nicht, weil sie in der Regel ziemlich flach ist (flat is better than nested). Django hingegen ist eher schon verschachtelt, aber dank der genialen und umfassenden Dokumentation ist es nicht nötig die genaue Vererbungsstruktur zu wissen. In der Tat bringt es auch nicht viel, sie zu wissen, denn es interessiert eigentlich auch nicht. Es Interessiert welche Klasse welche Methoden hat, nicht aber wo diese Methoden herkommen. Mir ist es egal, ob eine Klasse die ich nutze von dieser oder jener Klasse abgeleitet ist. Solange sie die Funktionen bereitstellt, die ich benötige ist das doch völlig unwichtig. Es kann auch sein, dass die Klasse in Zukunft von einer anderen Klasse abgeleitet ist. Aber auch in diesem Fall ist, solange sich die API nicht ändert, kein Problem zu sehen.sape hat geschrieben:Hast du dir mal z.B. die Klassenhirachie von Epidoc angesehen? 0o -> Ich finde das sehr hilfreich, dass in der Dokumentation auch Klassendiagramme/Packagediagramme benutzt werden. Gerade für außenstehende ist es so einfacher zu sehen was aufeinander aufbaut um die API zu verwenden...
Als mich für einen außenstehenden ist es vor allem wichtig zu verstehen wie die API funktioniert, und nicht warum die API so ist wie sie ist.
Edit: Markup korrigiert.
Zuletzt geändert von Leonidas am Mittwoch 3. Januar 2007, 14:51, insgesamt 1-mal geändert.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Was genau ist das?Leonidas hat geschrieben: Löst das Problem aber nicht. Metaprogrammierung kann nicht ohne weiteres dargestellt werden.
Stimmt -> Mixins! Das habe ich ganz und gar nicht berücksichtigt da ich bisher keine Mixins genutzt habe (und immer noch nicht nutze) aber schon davon gelesen habe :-[ Jetzt wo du es erwähnst fällt mir auf das Mixins sowas sind. Oder? -> Also zur Laufzeit hinzugefügte Attribute und Methoden.Leonidas hat geschrieben: Ein anderes Problem ist eben, dass Code in Python oft erst zur Ausführzeit vorhersehbar ist. Wenn eine Klasse ein Attribut nicht im Quellcode hat, muss es nicht heißen, dass es dieses Attribut nicht irgendwann zur Ausführzeit haben wird.
Python ist zu dynamisch ^^ Nun verstehe ich auch BlackJacks einwand mit dem "Einfach?" als ich meinte das die Auswertung Simple ist.
OK, Jungs, vergessen wir das Thema. War ne sehr blöde Idee im nachhinein.
lg
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Metaprogrammierung kann man als Technik ansehen die Programme schreibt. Mit Metaklassen ist es möglich, das Verhalten von Klassen stark zu verändern. Ein simples Beispiel bringt Ian Bicking.sape hat geschrieben:Was genau ist das?Leonidas hat geschrieben: Löst das Problem aber nicht. Metaprogrammierung kann nicht ohne weiteres dargestellt werden.
Nein. Nimm mal diesen Code:sape hat geschrieben:Stimmt -> Mixins! Das habe ich ganz und gar nicht berücksichtigt da ich bisher keine Mixins genutzt habe (und immer noch nicht nutze) aber schon davon gelesen habe :-[ Jetzt wo du es erwähnst fällt mir auf das Mixins sowas sind. Oder? -> Also zur Laufzeit hinzugefügte Attribute und Methoden.
Code: Alles auswählen
class Everything(object):
def __getattr__(self, name):
return True
Code: Alles auswählen
>>> e = Everything()
>>> e.something
True
>>> e.something_else
True
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Ja, stimmt im Wiki hatte ich mal glaube ich was davon gelesen aber nicht so recht verstanden.Leonidas hat geschrieben:Metaprogrammierung kann man als Technik ansehen die Programme schreibt. Mit Metaklassen ist es möglich, das Verhalten von Klassen stark zu verändern. Ein simples Beispiel bringt Ian Bicking.sape hat geschrieben:Was genau ist das?Leonidas hat geschrieben: Löst das Problem aber nicht. Metaprogrammierung kann nicht ohne weiteres dargestellt werden.
Ja das meine ich doch. Das nennt man doch Mixins.Leonidas hat geschrieben:[...]Nein. Nimm mal diesen Code:sape hat geschrieben:Stimmt -> Mixins! Das habe ich ganz und gar nicht berücksichtigt da ich bisher keine Mixins genutzt habe (und immer noch nicht nutze) aber schon davon gelesen habe :-[ Jetzt wo du es erwähnst fällt mir auf das Mixins sowas sind. Oder? -> Also zur Laufzeit hinzugefügte Attribute und Methoden.
Code: Alles auswählen
class Everything(object): def __getattr__(self, name): return True
Du siehst: eigentlich hat dei Klasse zur Definitionszeit die Attribute ``something`` und ``something_else`` nicht. Zur Lautzeit werden sie aber verfügbar.Code: Alles auswählen
>>> e = Everything() >>> e.something True >>> e.something_else True