Das deutsche Python-Forum

Es heisst nicht umsonst _Objektorientiert_ und nicht _Klassenorientiert_ auch wenn die populaeren OOP Umsetzungen hier einen Fokus legen.

Klassenhierarchien gibt es in Sprachen wie Java v.a. um das Typsystem zufriedenzustellen, da Python aber implizite Verhaltensprotokolle ("es gibt die Methode x und sie arbeitet auf Objekten die sich verhalten wie y und gibt dann Objekte die sich wie z verhalten zurueck") fuer diesen Zweck benutzt, faellt ein Grossteil der Vererbungen weg.

UML ist fuer mich weniger ein Designwerkzeug als ein Dokumentationswerkzeug, da es einen Standard gibt wie visuelle Repraesentationen gelesen werden muessen und man das nicht noch extra dokumentieren muss. Aber deshalb muss man noch lange nicht in UML denken.
UML hat auch nicht nur die meist unbrauchbaren Klassendiagramme, sondern auch Dinge die durchaus nuetzlich sein koennen wie Sequenzdiagramme. Aber allen ist gemein: Wenn sie automatisch generiert werden sind sie meistens fuer die Tonne.

@Mungo1981: Ergänzend zu cofi: Es gibt objektorientierte Programmiersprachen die gar keine Klassen haben sondern nur Objekte. Neue Objekte erstellt man dort in dem man bestehende Objekte klont. Das kann man zum Beispiel auch mit JavaScript realisieren, also einer Programmiersprache die sehr verbreitet ist. Bei so etwas kommt man mit UML auch an Grenzen.

Ein Use Case Diagramm ist in aller Regel nicht ausreichend um tatsächlich einen Use Case zu beschreiben. Dafür braucht man Text. Wenn man den geschrieben hat, ist das Diagramm dazu in sehr vielen Fällen äusserst trivial und bietet über den Text hinaus eigentlich keinen Mehrwert. Das heisst man versteht den Use Case nicht ohne Text, anders herum braucht man wenn man den Text gelesen hat, keine triviale Zeichnung mit einem oder zwei Strichmännchen und zwei bis drei Ovalen mehr.

Welche Verbindungen zwischen Objekten bestehen kann für die Dokumentation manchmal interessant sein, wenn diese Verbindungen nicht offensichtlich und komplex genug sind, dass sich eine Zeichnung dazu lohnt.

Sinn und Zweck von OOP ist in erster Linie das zusammenfassen von zusammengehörigen Daten und Funktionen die auf diesen Daten operieren zu einem Objekt. Um dann aus den Objekten die miteinander kommunizieren ein grösseres System zusammen zu bauen. Durch Vererbung kann man gemeinsames Verhalten von verschiedenen Objekten in ein anderes Objekt auslagern. Aber das muss und sollte man in dynamisch typisierten Sprachen nur machen, wenn es tatsächlich gemeinsames Verhalten gibt, welches man aus den Objekten in ein Elternobjekt heraus ziehen kann. Es ist nicht Sinn und Zweck von OOP einfach so ohne Grund komplizierte Vererbungshierarchien zu erstellen, nur weil man das kann und weil es in UML so schick aussieht.