Hallo,
ich versuche gerade, mich in die OOP einzuarbeiten bzw. einzulesen und zu den wohl eher theoretischen(?) Aspekten gehört es, UML in der Entwurfsphase zu nutzen. Mich würde nun interessieren, ob UML in der Praxis tatsächlich als Design-Entwurf (also nicht lediglich zur Kommunikation mit Kunden bei kommerziellen Projekten) eingesetzt wird. Wenn ihr also ein Projekt, welches über ein paar Zeilen Code hinaus geht, startet, nutzt ihr tatsächlich eine UML Software und entwerft ein solches Diagramm? Bzw. ist das sogar eine empfehlenswerte Herangehensweise?
OOP: nutzt tatsächlich jemand UML?
@Grendel: Also irgend jemand wird das wahrscheinlich so machen. Ich denke bei Python und ähnlichen Sprachen nicht so wirklich viele Leute. Bei Java und ähnlichen Sprachen vielleicht schon eher weil es dort Werkzeuge gibt die aus UML Code erstellen können und aus Code UML erstellen können. Da kann man das also eher praktisch nutzen. Bei Python hat man ja zum Beispiel auch das Problem das UML eher auf statischere Sprachen ausgerichtet ist und man nicht alles aus Python so einfach in UML ausdrücken kann.
Zumal man mit Python normalerweise, je nach Sichtweise, auch gar kein reines OOP macht. Obwohl in Python ja *alles* ein Objekt ist das man an einen Namen binden kann, also auch Module und Funktionen zum Beispiel.
Zumal man mit Python normalerweise, je nach Sichtweise, auch gar kein reines OOP macht. Obwohl in Python ja *alles* ein Objekt ist das man an einen Namen binden kann, also auch Module und Funktionen zum Beispiel.
- sls
- User
- Beiträge: 480
- Registriert: Mittwoch 13. Mai 2015, 23:52
- Wohnort: Country country = new Zealand();
Hi,
ich weiß nicht wie professionelle Python-Entwickler das sehen, aber für mich als Einsteiger in die OOP ist UML sehr wichtig, da ich häufig das Problem habe zu schauen, welche Klasse man erstellen sollte, welche Eigenschaften und Methoden sie beinhalten sollte, und wie die Beziehung zu anderen Klassen sein soll (Komposition, Aggregation, Vererbung usw. usf.)
In Java war das bis zu dem Zeitpunkt für mich verständlich, als dass man für jede Klasse i.d.R. eine eigene Quell-Code-Datei anlegt, in Python ist das schon wieder etwas anders, hier stehe ich häufig vor dem Problem zu erkennen, wann z.B. factory Funktionen zur instanziierung sinnvoll sind, oder man gleich auf OOP verzichten sollte. Da sagen einem Unit-tests vielleicht am ehesten "dein 'Algorithmus' ist grottig, such dir eine bessere Lösung". Weniger gefallen mir dabei immer die "real world examples" mit irgendeiner Fahrzeug-Hauptklasse und PKW-, LKW-Klassen welche von dieser dann erben usw.
Problematisch wird's halt dann, wenn man reelle Anwendungen programmieren möchte, und durch fremden Source-Code durchsteigen will. Wie gesagt, bis ich das mal perfekt beherrsche werden noch etliche Jahre verstreichen, evtl. sehe ich das dann auch anders und benötige UML nicht mehr so wie jetzt, wo vieles nicht abstrakt betrachtet werden kann.
Viele Grüße,
sls
ich weiß nicht wie professionelle Python-Entwickler das sehen, aber für mich als Einsteiger in die OOP ist UML sehr wichtig, da ich häufig das Problem habe zu schauen, welche Klasse man erstellen sollte, welche Eigenschaften und Methoden sie beinhalten sollte, und wie die Beziehung zu anderen Klassen sein soll (Komposition, Aggregation, Vererbung usw. usf.)
In Java war das bis zu dem Zeitpunkt für mich verständlich, als dass man für jede Klasse i.d.R. eine eigene Quell-Code-Datei anlegt, in Python ist das schon wieder etwas anders, hier stehe ich häufig vor dem Problem zu erkennen, wann z.B. factory Funktionen zur instanziierung sinnvoll sind, oder man gleich auf OOP verzichten sollte. Da sagen einem Unit-tests vielleicht am ehesten "dein 'Algorithmus' ist grottig, such dir eine bessere Lösung". Weniger gefallen mir dabei immer die "real world examples" mit irgendeiner Fahrzeug-Hauptklasse und PKW-, LKW-Klassen welche von dieser dann erben usw.
Problematisch wird's halt dann, wenn man reelle Anwendungen programmieren möchte, und durch fremden Source-Code durchsteigen will. Wie gesagt, bis ich das mal perfekt beherrsche werden noch etliche Jahre verstreichen, evtl. sehe ich das dann auch anders und benötige UML nicht mehr so wie jetzt, wo vieles nicht abstrakt betrachtet werden kann.
Viele Grüße,
sls
When we say computer, we mean the electronic computer.
UML ist nicht wirklich "unified", sondern es ist im Wesentlichen von den Hauptakteuren der 90ziger um IBM und Rational ohne (oder gegen) Microsoft entstanden. So kommt's dann auch, dass ein wunderbares Diagramm fehlt, dass in Microsoft Produkten viel Anwendung findet: das Objektmodell.
@MagBen: Was ist denn das Objektmodell von Microsoft? Vielleicht finde ich auch nicht die richtigen Suchbegriffe — ich bekomme viele Treffer von API-Beschreibungen von MS-Produkten aber keine Diagramme.
Sag ich ja, es fehlt.BlackJack hat geschrieben:Was ist denn das Objektmodell von Microsoft?
Google Bildersuche nach "object model" liefert einige brauchbare Bilder, z.B.:
https://www.safaribooksonline.com/libra ... 06s05.html
Und ja es geht um ein Microsoft Produkt. Der Punkt ist aber, dass wenn man sowas für eigene Anwendungen macht, es sehr hilfreich ist.
https://www.safaribooksonline.com/libra ... 06s05.html
Und ja es geht um ein Microsoft Produkt. Der Punkt ist aber, dass wenn man sowas für eigene Anwendungen macht, es sehr hilfreich ist.
@MagBen: Und die Information kann man nicht in UML ausdrücken?
Wie ist das denn zu lesen? Also grundsätzlich die Baumstruktur ist mir klar, aber bei „Explorers“ passiert in dem Diagramm ja noch mehr. Da sind Knoten eingerückt als wären sie Kinder von „Explorers“, obwohl sie Kinder von „Application“ sind, und „Panes“ ist ebenfalls so eingerückt wie ein Kind von Explorers, obwohl es die Wurzel eines eigenen Baums ist.
Gibt es eine Definition von diesem Diagrammtyp?
Wie ist das denn zu lesen? Also grundsätzlich die Baumstruktur ist mir klar, aber bei „Explorers“ passiert in dem Diagramm ja noch mehr. Da sind Knoten eingerückt als wären sie Kinder von „Explorers“, obwohl sie Kinder von „Application“ sind, und „Panes“ ist ebenfalls so eingerückt wie ein Kind von Explorers, obwohl es die Wurzel eines eigenen Baums ist.
Gibt es eine Definition von diesem Diagrammtyp?
@Magben wo ist denn da der signifikante Unterschied zu UML und seinen diversen Diagrammtypen, die Vererbung und Aggregation darstellen können?
ZB https://de.m.wikipedia.org/wiki/Datei:U ... ramm-1.svg
Da sehe ich jetzt nicht, wo das deine grossse Verschwörung rechtfertigt.
Das so eine Übersicht sinnvoll sein kann steht auf einem anderen Blatt. Doxygen generiert einem sowas ja auch. Aber das ist IMHO auch noch mal ein großer Unterschied zwischen Dokumentation, und dem Versuch, ganze System detailliert abzubilden.
ZB https://de.m.wikipedia.org/wiki/Datei:U ... ramm-1.svg
Da sehe ich jetzt nicht, wo das deine grossse Verschwörung rechtfertigt.
Das so eine Übersicht sinnvoll sein kann steht auf einem anderen Blatt. Doxygen generiert einem sowas ja auch. Aber das ist IMHO auch noch mal ein großer Unterschied zwischen Dokumentation, und dem Versuch, ganze System detailliert abzubilden.
Ergänzend dazu: Auf dem verlinkten UML-Diagramm sind viele Detail-Informationen die man auch weglassen kann und man kann die Elemente natürlich auch so baumartig anordnen wie in dem gezeigten Objektmodell.
Ausreichend wofür?