uml code generator

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
jonbob
User
Beiträge: 14
Registriert: Montag 24. November 2008, 10:40

Hallo miteinander

ich lerne gerade Python und suche einen Code-Generator der aus UML Diagrammen Python-Code generiert.

Hat jemand von euch eine Idee?

Ich weiß das es Zahlreich UML-Code Generatoren für Java gibt.

Habe im Forum gesucht und bisher noch nichts darüber gefunden. Was vielleicht auch jemand wo unterschiedliche Code-Generatoren verglichen werden?

Vielen Dank für Eure Hilfe

Jon

ps.: am besten währe ein Eclipse-Plugin
Zuletzt geändert von jonbob am Donnerstag 4. Dezember 2008, 15:43, insgesamt 1-mal geändert.
würmchen
User
Beiträge: 255
Registriert: Mittwoch 7. November 2007, 14:17

Umbrello kann das soweit ich weiß
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

"dia" wäre da auch mal nen Blick wert! Dafür gibts viele Zusatz-Module.
BlackJack

Wobei sich mir die Frage stellt wie man in UML (Python-)Packages, Module und Funktionen darstellt. Was ist mit Properties?

UML ist für statisch typisierte, klassenfixierte Sprachen gedacht, und man kann halt nicht alles ausdrücken, was mit Python möglich ist. Wenn man nicht aufpasst schreibt man schnell Java-Programme in Python.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Wieso sollte man in Python autogenerierten Code haben wollen? Der ist läng, hässlich und meiner Meinung und Erfahrung nach völlig unnütz.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
jonbob
User
Beiträge: 14
Registriert: Montag 24. November 2008, 10:40

@ würmchen und Hyperion danke für die Tipps. Habt ihr die Programme schon mal benutzt?

@BlackJack ob und wie man die einzelnen Elemente modelliert weiß ich auch noch nicht genau. Jedoch ist mit UML und deren Stereotypen fast alles möglich. Außerdem ist mir der eigentliche Code nicht so wichtig mir geht es eher darum das ich erst mein Programm modellieren kann ( aus Dokumentation s- / Kommunikations- und Verständnisgründen) und dann ‚Skeletoncode‘ bekomme. Wenn es ein Java Programm in Python wird fände ich es nicht so schlimm, da ich Python benutze weil viele Sachen einfacher um zu setzen sind (das einzige Problem was ich daran sehe ist das die Performance da durch in den Keller gehen könnte). Jedoch ist mir wichtig das es OO ist, so das ich gewisse Elemente widerverwänden und austauschen kann. Also Klassenbasiert ;-)

@Leonidas wie gut die Codegeneratoren sind weiß ich nicht aber wie oben erwähnt geht es mir eher um ein Codegerüst. Ich habe bis her nur mit einem GUI- builder rumgespielt war von dem auch nicht so begeistert. Jedoch habe ich mit Java schon ganz gut Erfahrungen mit UML Code Generatoren oder GUI builder gemacht.

Wie würde ihr den Python Programme aus Dokumentations- / Kommunikations- und Verständnisgründen modellieren?
Eine weitere Frage besteht noch: Was vielleicht auch jemand wo unterschiedliche Code-Generatoren verglichen werden?

Vielen Dank
Jon
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

jonbob hat geschrieben:Jedoch ist mit UML und deren Stereotypen fast alles möglich.
Eben nicht. Dynamisch entstehende Attribute, Attribute die nur situationsabhängig vorhanden sind, Erweiterung der Basisklassen zur Laufzeit aber eben auch Attribute die von selbst Werte ausrechnen (eben Properties) sind nicht durch UML darzustellen weil UML eben statische Strukturen darstellt, keine Strukturen die sich je nach Zustand ändern.
jonbob hat geschrieben:Jedoch ist mir wichtig das es OO ist, so das ich gewisse Elemente widerverwänden und austauschen kann. Also Klassenbasiert ;-)
Klassenbasiert ist nicht gleich OOP. Und besonders in Java wird einem OOP schwergemacht.
jonbob hat geschrieben:Jedoch habe ich mit Java schon ganz gut Erfahrungen mit UML Code Generatoren oder GUI builder gemacht.
Weil man in Java mehr Boilerplate-Code schreiben muss?
jonbob hat geschrieben:Wie würde ihr den Python Programme aus Dokumentations- / Kommunikations- und Verständnisgründen modellieren?
Mit einem Editor. Dabei würde ich gar nicht mal zuanfangs OOP nutzen, womöglich ist es sogar sinnvoller eben keine Klassen zu nutzen, wenn das Problem sie nicht erfordert.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

jonbob hat geschrieben:@ würmchen und Hyperion danke für die Tipps. Habt ihr die Programme schon mal benutzt?
Ja, aber nicht wegen UML ;-) Mir ging es um ERD und die Erzeugung von SQL.
BlackJack

@jonbob: Wenn Du Java programmieren möchtest, dann programmier doch auch in Java. Wenn Du Python benutzt weil damit vieles einfacher geht als in Java, dann macht es einfach keinen Sinn es künstlich so kompliziert wie in Java zu machen.

OOP muss nicht klassenbasiert sein und eine generische Funktion ist auch wiederverwendbar, die muss man dafür nicht zwangsweise in eine Klasse stecken. Immer dran denken, dass in Python alles was man an einen Namen binden kann ein Objekt ist, auch Funktionen.

OOP ist kein Selbstzweck und nicht automatisch die richtige Lösung für alle Probleme. Die Stärke von Python ist IMHO gerade verschiedene Werkzeuge zur Verfügung zu stellen.
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Nett ist für den Überblick mal ein Ausflug zu Scheme, da lernt man alle Paradigmen!
Benutzeravatar
rudolfo.christ
User
Beiträge: 11
Registriert: Freitag 5. Dezember 2008, 18:47
Wohnort: Trier

Dynamsiche Attribute gibt es schon in der UML. Diese werden allerdings oft als abgeleitete Attribute bezeichnet und bei der OOA mit einem "\" dargestellt.

Als Beispiel: Eine Klasse Automodell, das ein Attribut "Listenpreis" besitzt. Desweitern gibt es für jedes Objekt vom Typ Auto auch ein Rabatt- Attribut. Der tatsächliche Preis ergibt sich jetzt aus der Berechnung von Listenpreis und Rabatt.

Als UML-Klassendiagramm:
---------------------
Auto
---------------------
listenpreis
rabatt
\ preis
---------------------

Mehr braucht man auch nicht bei der OOA zu modellieren, da das Ziel eine iplementierungsunabhängige Darstellung der Klassenbeziehungen ist.

Um zu zeigen wie sich solche dynamsichen Attribute oder sonstiges verhalten, wählt man sowieso kein Klassendiagramm. Denn Klassendiagramme sind laut UML für das statische modellieren gedacht.

Für das Verhalten eines Attributs gibt es andere Diagramme, z.B. ein Zustandsautomat oder ein Aktivitätsdiagramm, oder auch ein Sequenzdiagramm.

Ob es jetzt Tools gibt die aus all den verschieden Diagrammen Source Code generieren, weiß ich nicht.

Bin nach wie vor der Meinung, das das beste Tool zur modellierung Stift und Papier ist. Und bei einer vernünftigen Modellierung schreibt sich der Code sowieso von ganz alleine.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

audax, wenn du alle Paradigmen lernen willst, weiß ich nicht ob Scheme so optimal ist. Man kann zwar alle Paradigmen implementieren (siehe: 7 verschiedene Implementationen von OOP, Contracts, etc. die alle Implementationsabhängig sind), aber manchmal ist "the real thing" doch lehrreicher. Also für funktionale Programmierung ist Scheme nicht übel, man sollte aber nicht vergessen auch eine rein funktionale Sprache wie ML oder Haskell anzusehen. Für OOP würde ich wohl zu Smalltalk oder Common Lisps CLOS raten, evtl noch Io um mal prototypenbasiertes OOP zu sehen. Für logische Programmierung ist wohl zum reinschnuppern Prolog wohl das Mittel der Wahl. Wenn man das alles gesehen hat und es in einer einzigen Sprache haben will kann man dann Scheme zur Hand nehmen :)
rudolfo.christ hat geschrieben:Um zu zeigen wie sich solche dynamsichen Attribute oder sonstiges verhalten, wählt man sowieso kein Klassendiagramm. Denn Klassendiagramme sind laut UML für das statische modellieren gedacht.
Eben und da in Python sehr seltsame Dinge möglich sind die in vielen Sprachen nichtmal vorstellbar sind macht es wenig sinn sich in diese Richtung festzulegen. Zudem idR. die Klassenstrukturen in Python ja auch nicht dermaßen kompliziert sind, da man ja nicht zu OOP gezwungen ist. Außnahmen gibt es zwar auch, aber da würde man auch keinen Code aus UML generieren sondern es wohl auf anderem Wege planen.
rudolfo.christ hat geschrieben:Für das Verhalten eines Attributs gibt es andere Diagramme, z.B. ein Zustandsautomat oder ein Aktivitätsdiagramm, oder auch ein Sequenzdiagramm.
Ab dem Punkt kann es oftmals klarer sein direkt einen Prototypen zu schreiben statt hübsche Diagramme zu malen die Leute die keine Ahnung haben beeindrucken die aber von begrenzten praktischen nutzen sind. In der Zeit wo so ein Diagramm gemacht wird, kann man oftmals die Implementation schon fertig haben.
rudolfo.christ hat geschrieben:Bin nach wie vor der Meinung, das das beste Tool zur modellierung Stift und Papier ist. Und bei einer vernünftigen Modellierung schreibt sich der Code sowieso von ganz alleine.
Da stimme ich absolut zu. Alle bunten Kästchen helfen mir wenig wenn ich nicht schnell in dem Ding rumschmieren kann, Szenarien durchspielen kann etc wie es auf dem Papier dass eben jegliche Flexibilität bietet, möglich ist. Oft reichen mir bei Problemen kurze Skizzen die ich dann nicht mehr im Kopf durchspielen muss sondern direkt anschauen kann um einen Lösungsansatz zu finden.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
rudolfo.christ
User
Beiträge: 11
Registriert: Freitag 5. Dezember 2008, 18:47
Wohnort: Trier

Ab dem Punkt kann es oftmals klarer sein direkt einen Prototypen zu schreiben statt hübsche Diagramme zu malen die Leute die keine Ahnung haben beeindrucken die aber von begrenzten praktischen nutzen sind. In der Zeit wo so ein Diagramm gemacht wird, kann man oftmals die Implementation schon fertig haben.
Ehhrr, kann ich jetzt nur bedingt zustimmen. Keine Frage das wir uns einig sind das die Code Generierung nicht besonders sinvoll ist, oder besser gesagt nicht meiner (oder vielleicht auch deiner?) Arbeitsweise entspricht.

Dennoch bin ich froh wenn ich zu Quellcode auch eine Übersicht in UML bekomme.

Gerade bei Sequenzdiagrammen kann man sehr schon die Aufrufhirachie erkennen. Weiß sofort welche Operationen wann welche Objekte erzeugt. Und finde das auch angenehmer als mich im Editor durch wieviel Tabs zu klicken und nachzuschauen was einzelen Operationen machen.

Dennoch hast du Recht das dieses ganze Digrammzeug auch für manche (vor allem nicht OO) Projekte ein echter overkill ist und in der Zeit wo man akribisch Diagramme malt, hätte auch schon das Programm laufen können.

Finde deshalb die Reverse Engineering Funktion die einige Tools (vielleicht auch für Python) mitbringen ein vielfaches interessanter

Hab ein Tool zur Python Generierung gefunden:
http://bouml.free.fr/
Überzeugt mich allerdings wenig.
Hatte es damals nur mit Java getestet. Vielleicht ist es für Python besser geeignet?
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

rudolfo.christ hat geschrieben:Gerade bei Sequenzdiagrammen kann man sehr schon die Aufrufhirachie erkennen. Weiß sofort welche Operationen wann welche Objekte erzeugt. Und finde das auch angenehmer als mich im Editor durch wieviel Tabs zu klicken und nachzuschauen was einzelen Operationen machen.
Einen Call Graph kann man sich automatisch generieren lassen. Hat auch den Vorteil dass es immer up-to-date ist und die eigentliche Implementierung beschreibt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Leonidas hat geschrieben:audax, wenn du alle Paradigmen lernen willst, weiß ich nicht ob Scheme so optimal ist. Man kann zwar alle Paradigmen implementieren (siehe: 7 verschiedene Implementationen von OOP, Contracts, etc. die alle Implementationsabhängig sind), aber manchmal ist "the real thing" doch lehrreicher. Also für funktionale Programmierung ist Scheme nicht übel, man sollte aber nicht vergessen auch eine rein funktionale Sprache wie ML oder Haskell anzusehen. Für OOP würde ich wohl zu Smalltalk oder Common Lisps CLOS raten, evtl noch Io um mal prototypenbasiertes OOP zu sehen. Für logische Programmierung ist wohl zum reinschnuppern Prolog wohl das Mittel der Wahl. Wenn man das alles gesehen hat und es in einer einzigen Sprache haben will kann man dann Scheme zur Hand nehmen :)
Ich hab tolle Profs in der Scheme Vorlesung, die haben für uns nen entchlacktes OOP-Pack geschrieben das sich sehr gut nutzen lässt. Das Objektmodell ist das gleiche wie in Py :D
Haskell schau ich mir momentan noch parallel an und ne Kurzeinführung in die logische Programmierung erfolgt erstmal in Scheme, nach der Vorlesung werd ich mir Prolog auf die Liste der Sprachen, die ich noch zu lernen habe, setzen.

Ich befürchte nur, ich bleib bei der funktionalen Programmierung hängen :D
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Zu Scheme und Objektorientierung findet man bei http://library.readscheme.org/page4.html mehr als man je wissen wollte. Ob Pythons Objektmodell gut zu Scheme passt, müssen da die Professoren beurteilen. Ich hätte mich an Dylan orientiert, aber da es relativ einfach ist, die Konzepte umzusetzen, gibt es diverse Ansätze.

Scheme entstand ja, weil Steele und Sussman versuchten, das Actor-Modell, welches auch beeinflusst von den selben Ideen wie Smalltalk ist, in Lisp umzusetzen und sie erkannten, dass Funktionen und Objekte gleichmächtig sind. Siehe http://research.sun.com/projects/plrg/J ... public.pdf

Stefan
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

audax hat geschrieben:Ich befürchte nur, ich bleib bei der funktionalen Programmierung hängen :D
Armer audax! Nein, im Ernst, wenn du an Scheme hängen bleibst dann hast du so oder so eine gute Nische erwischt. Scheme ist als Sprache eine sehr tolle Sache - wenn dir das Objektmodell nicht passt nutztst du einfach ein anderes. Eigentlich ist Lisp auch keine Sprache an sich sondern eine Meta-Sprache die einem erlaubt problemorientiete DSLs zu schreiben.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Antworten