Modellierung / Design / UML und Python
- Autor
- Stefan Schwarzer
Raum 1, Samstag, 12:30 Uhr
Einführung
Die Unified Modeling Language (UML) ist eine standardisierte grafische Notation für die Softwareentwicklung. Aktuell ist die Version 2.3, die 14 Diagramm-Arten definiert.
Eine ausführliche Video-Reihe zur UML gibt es auf YouTube (Bereich "Uploads" auf der rechten Seite). Eine Kurzreferenz gibt es von der Firma OOSE. Eine nicht ganz so kurze Referenz ist UML 2 kompakt von Heide Balzert.
Vorurteile
Öfter als an Modellierungsproblemen scheitert der Einsatz der UML an Vorurteilen. Hier einige davon und Hinweise dazu:
- "Die UML ist zu aufwändig." - Man muss nur modellieren, was man braucht. In vielen Fällen reichen zum Beispiel im Klassendiagramm einige wenige Klassen. Diese brauchen auch nur die Attribute und Operationen enthalten, die zur Beschreibung einer Problemlösung nötig sind.
- "UML-Diagramme sind zu unübersichtlich." - Siehe oben. Wenn man nur die nötigsten Informationen unterbringt, sind die Diagramme meist hinreichend übersichtlich. Wenn man feststellt, dass man viele Informationen im Diagramm braucht, um ein Problem zu diskutieren, ist wahrscheinlich auch das Problem komplex. Auch, wenn man relativ viel in ein Diagramm einträgt, kann man je nach UML-Werkzeug trotzdem vorübergehend Attribute und Operationen ausblenden.
"Nur aufgeblasene bürokratische Entwicklungsprozesse verwenden UML." - Nein, auch in agilen Softwareentwicklungsprozessen kann man UML verwenden. Mehr unter http://www.agilemodeling.com.
"UML-Tools sind schwer zu benutzen." - Es gibt unterschiedlich schwer zu benutzende Werkzeuge, die noch nicht einmal zwingend auf einem Rechner laufen müssen. Gerade für Design-Diskussionen von mehreren Entwicklern eignen sich Whiteboards. Ein übersichtliches Software-Werkzeug für den UML-Einstieg ist das Open-Source-Programm VioletUML. Das kommerzielle Visual Paradigm for UML enthält viel mehr Funktionen, lässt sich aber dennoch relativ leicht bedienen. Von dem Programm gibt es auch eine kostenlose Community-Edition, die aber nicht kommerziell verwendet werden darf.
Besonderheiten bei der Modellierung von Python-Code
Ich beziehe mich hier nur aufs Klassendiagramm, das nach meinem Eindruck der am häufigsten von Softwareentwicklern benutzte Diagrammtyp ist. Wenn das UML-Software-Modell erst einmal so wie beschrieben erstellt ist, sind für andere Diagramme keine speziellen Anpassungen mehr nötig.
Konstanten und Funktionen
Die meisten Diagramme der UML gehen von reinen objektorientierten Softwaresystemen aus. Python-Code enthält aber auch Funktionen und Konstanten direkt auf Modul-Ebene. Dennoch kann man auch diese in UML-Klassendiagrammen modellieren. Ich (Stefan) habe mir dazu folgenden Ansatz ausgedacht, aber es ist natürlich möglich, dass ich nicht der erste bin, der auf diese Ideen kommt. 
- In der UML gibt es "Pakete" ("Packages"), die eigentlich für eine Sammlung von Klassen, zum Beispiel in einem Unterverzeichnis des Dateisystems, gedacht sind. Die UML sieht aber auch so genannte Stereotypen vor. Das sind Anmerkungen, die die standardmäßige Bedeutung eines Symbols verändern können. Ein Python-Modul kann man demnach modellieren, indem man ein Package zeichnet, das man mit einem Stereotyp "module" auszeichnet. Das "Package" definiert hier kein Verzeichnis, sondern nur den Namensraum eines Python-Moduls.
- Innerhalb des Pakets zeichnet man die enthaltenen Klassen, wenn man will, mit Vererbungspfeilen, Assoziationen und so weiter.
- Die Funktionen und Konstanten eines Moduls modelliert man durch eine Klasse, der man einen Stereotyp "global" zuordnet. Die Konstanten des Moduls gehen in den Bereich für (UML-)Attribute, die Funktionen in den Bereich für die Operationen. (Im Gegensatz zur Python-Terminilogie bezeichnet ein "Attribut" in der UML-Terminilogie nur einen Wert, aber keine Methode/Operation.)
- Hier eine Beispiel-Grafik:
In einer etwas einfacheren Variante kann man das umgebende Paket weglassen und die Pseudo-Klasse ModulnameGlobals oder ähnlich nennen. Die einfachere Diagramm-Erstellung erkauft man sich im Einzelfall damit, dass gleichnamige Klassen in unterschiedlichen Modulen nicht modellierbar sind. Ein UML-Modell erlaubt keine zwei gleichnamigen Klassen in der gleichen Gliederungs-Ebene.
Duck Typing
- Ein UML-Modell/Diagramm und dessen Implementierung müssen nicht zwangsweise übereinstimmen. Das in Python häufig angewandte Duck Typing lässt sich daher relativ klar formulieren, indem man den hypothetischen "Duck Type" als Interface modelliert:
Hinweis: In diesem Wiki gibt es noch einen Beitrag zu Python und UML.
Tipp: UML Diagramme in Doks einbinden:
Create and share simple UML diagrams in your blogs, wikis, forums, bug-trackers and emails.
- [get | view] (2011-04-19 05:52:35, 4.3 KB) [[attachment:duck_typing.png]]
- [get | view] (2011-04-19 05:52:21, 8.2 KB) [[attachment:modul.png]]
