Softwarearchitektur und UML
Sie übernehmen eine Software, die jemand anderes geschrieben hat. Dokumentation gibt es kaum, die Kommentare sind veraltet, und wer den Code kannte, ist nicht mehr da. Trotzdem sollen Sie Fehler beheben und neue Funktionen einbauen – und zwar bald.
Der erste Reflex ist, Datei für Datei zu lesen. Das dauert lange und liefert vor allem Details. Schneller kommen Sie mit einem Bild des Ganzen voran: Welche Teile gibt es, wie hängen sie zusammen, und was passiert in welcher Reihenfolge? Genau dafür gibt es die UML, die Unified Modeling Language.
Statik und Dynamik: zwei Blickwinkel auf denselben Code
Die UML kennt vierzehn Diagrammarten. Für den Einstieg in fremden Code genügen wenige. Sie teilen sich in zwei Gruppen: Diagramme der Statik zeigen den Bauplan, Diagramme der Dynamik zeigen den Ablauf. Erst beide zusammen ergeben den Überblick.
| Diagrammart | Blickwinkel | Frage, die es beantwortet |
|---|---|---|
| Klassendiagramm | Statik | Welche Klassen gibt es, und wer kennt, besitzt oder erbt von wem? |
| Paketdiagramm | Statik | Welche Bausteine, etwa DLLs oder Namensräume, hängen voneinander ab? |
| Sequenzdiagramm | Dynamik | Wer ruft wen in welcher Reihenfolge auf? |
| Zustandsdiagramm | Dynamik | In welchem Zustand ist ein Ablauf, und was bringt ihn weiter? |
| Aktivitätsdiagramm | Dynamik | Welche Tätigkeiten folgen aufeinander, und wo verzweigt der Ablauf? |
So gehen Sie vor
- Einstiegspunkte suchen. Wo beginnt das Programm? Bei Desktop-Software sind das Befehle, Menüeinträge, Schaltflächen oder Ereignisse. Notieren Sie die drei bis fünf Abläufe, die für Ihre Aufgabe wirklich wichtig sind.
- Die Statik zeichnen. Beginnen Sie bei einer Klasse, die Sie schon kennen, und folgen Sie ihren Beziehungen. Zeichnen Sie nur die Klassen, die zu Ihren Abläufen gehören. Attribute und Methoden tragen Sie erst ein, wenn Sie sie brauchen.
- Die Dynamik zeichnen. Gehen Sie jeden wichtigen Ablauf im Debugger durch und halten Sie ihn als Sequenzdiagramm fest: ein Kasten je beteiligtem Objekt, ein Pfeil je Aufruf, die Zeit läuft von oben nach unten. Hat ein Ablauf mehrere Schritte oder Betriebsarten, hilft zusätzlich ein Zustandsdiagramm.
- Diagramme nebeneinanderlegen. Jetzt sehen Sie, was der Code allein nicht zeigt: Klassen, die dasselbe tun. Abläufe, die dieselben Daten mehrfach berechnen. Abhängigkeiten, die in die falsche Richtung zeigen.
- Mit den Fachleuten sprechen. Zeigen Sie die Diagramme denen, die die Software benutzen oder betreuen. Fünf Kästen an der Tafel klären oft in Minuten, wofür man im Code Tage braucht.
Klassendiagramme lesen: Die Linien entscheiden
Eine Klasse ist ein Kasten mit bis zu drei Fächern: Name, Attribute, Methoden. Interessant wird es zwischen den Kästen. Eine durchgezogene Linie heißt „kennt“. Eine leere Raute heißt „hat“: Das Teil kann ohne das Ganze leben, wie ein Baum ohne Wald. Eine gefüllte Raute heißt „besteht aus“: Das Teil lebt und stirbt mit dem Ganzen, wie ein Ast mit seinem Baum. Ein leeres Dreieck steht für Vererbung, also „ist ein“. Ein gestrichelter Pfeil heißt „benutzt“.
Drei Regeln helfen beim Lesen: Die Raute sitzt beim Ganzen, das Dreieck bei der Oberklasse, die Pfeilspitze beim Gekannten. An den Enden einer Linie stehen die Vielfachheiten, etwa 1, 0..1 oder 0..*.
Aus der Praxis: Kalibrierung mit 3 statt 5 Schritten
Ein großer internationaler Sensorhersteller bat uns, die Kalibriersoftware für Laserscanner mit Spiegelrad zu übernehmen. Der bisherige Dienstleister hatte die Arbeit eingestellt. Der Quellcode war kaum lesbar und teilweise verschleiert. Die Kalibrierung bestand aus fünf Schritten, die Systemeinrichter, Integratoren und der Support weltweit bei jeder Einrichtung durchführen.
Wir haben den Code Schritt für Schritt untersucht und die statische Struktur sowie die dynamischen Abläufe als UML-Modell dargestellt. Dabei zeigte sich schnell, dass sich mehrere Kalibrierschritte überschneiden. Im Code war das kaum zu erkennen, im Diagramm schon. Danach haben wir die Schritte mathematisch neu aufeinander abgestimmt und überflüssige gestrichen. Heute braucht die Kalibrierung drei statt fünf Schritte. Weil sie weltweit sehr oft durchgeführt wird, spart das mehrere tausend Arbeitsstunden pro Jahr.
Typische Fehler
- Alles auf ein Bild. Ein Diagramm mit vierzig Kästen liest niemand. Besser sind drei kleine Diagramme, jedes mit einer Frage, die es beantwortet.
- Nur generieren. Viele Werkzeuge erzeugen Klassendiagramme auf Knopfdruck aus dem Code. Das ist ein guter Startpunkt, aber noch kein Überblick. Den schaffen erst Auswählen und Weglassen.
- Nur die Statik. Ein Klassendiagramm zeigt, was es gibt, aber nicht, was passiert. Doppelte Arbeit in Abläufen finden Sie erst im Sequenz- oder Zustandsdiagramm.
- Die Raute an der falschen Seite. Die Raute gehört zum Ganzen. Steht sie beim Teil, besitzt plötzlich das Blatt den Baum.
- Komposition, wo nur verwiesen wird. Nicht jede Referenz im Code ist Besitz. Prüfen Sie, wer ein Objekt anlegt und wer es wieder freigibt.
- Diagramme, die veralten. Ein Diagramm, das nicht mehr zum Code passt, ist schlimmer als keines. Halten Sie es klein und ändern Sie es mit, wenn sich der Ablauf ändert.
So helfen wir
- Wir analysieren fremden oder gewachsenen Code und machen ihn mit UML verständlich: Qualitätsprüfung und Code-Review.
- Wir planen neue Software mit UML, bevor die erste Zeile entsteht: UML in der Softwareplanung.
- Ihr Team lernt, UML-Diagramme zu lesen und selbst zu zeichnen: UML-Schulung im Cadida-Shop.
- Sie haben Code übernommen und wissen nicht, wo Sie anfangen sollen? Vereinbaren Sie ein Erstgespräch.
Quellen: Ebi F. Eilber, AutoCAD .NET API (Fachbuch, erscheint voraussichtlich 2027), Kapitel „UML lesen“; Fallstudie „Kalibrierung von Spiegelradlasern: 3 statt 5 Schritte“, Cadida-Fallstudien.
kununu