Startseite > Embedded > Entwicklungstools > Das richtige Diagramm zur richtigen Zeit

Entwickeln mit UML

Das richtige Diagramm zur richtigen Zeit

29. April 2010, 10:42 Uhr | Von Anja Ranft

Wie setzt man die UML ein, um von der Analyse bis zum Feindesign ein durchgängiges und nachvollziehbares Modell zu entwickeln? Nach der Lektüre dieses Artikels ist der Leser zwar noch kein UML-Guru, doch sollte er deutlich erkennen können, worauf es bei der Modellierung ankommt, wie Schritt für Schritt ein Modell entsteht und dass Use-Case-Diagramme nicht gleich Analyse und dass Klassendiagramme nicht gleich Feindesign sind.

▶ Diesen Artikel anhören

Sie möchten in Ihrer Software- oder Systementwicklung die UML einsetzen, haben sich voller Motivation ein UML-Buch gekauft, sich eventuell sogar durch einige der schwerverdaulichen Kapitel der UML-Spezifikation gekämpft und nun ... Ja, und nun wissen Sie immer noch nicht so recht, wie Sie eigentlich beginnen sollen. Dafür kommt Ihnen spontan der gute Doktor Faust in den Sinn »Da steh ich nun, ich armer Tor ...«. Kein Wunder, und Sie stehen sicherlich nicht alleine da. Die UML bietet zwar einen großen Werkzeugkasten gefüllt mit Diagrammen und Notationselementen, doch leider liefert sie keine Gebrauchsanweisung mit.

Zudem ist es notwendig, gleich zu Beginn eine Illusion zu zerstören: Es gibt KEINE exakten, standardisierten Richtlinien für die Erstellung eines UML-Modells. Und das ist auch gut so! Kein Systementwicklungsprojekt ist wie das andere, kein Produkt ist wie das andere, und daher kann auch kein Modell wie das andere sein. Modelle wachsen und entwickeln sich mit dem Projekt. Ihr Inhalt und ihre Detailtiefe hängen von vielen Einflussfaktoren ab, und gerade die Detaillierung kann und wird innerhalb des Modells variieren. Verabschieden Sie sich von Anfang an von dem Gedanken, es gäbe feste Regeln, welche Inhalte darzustellen sind und wie detailliert zu modellieren ist. Die UML gibt hierfür nichts vor und man kann auch nicht ohne weiteres von einem Projekt auf das andere schließen. Die einzige Richtlinie, die Sie haben werden, ist die Frage: »Welchen Nutzen hat Diagramm xy für das Projekt?«.

Hier einige Punkte, wovon Inhalt und Detaillierung Ihres Modells abhängen können und die Sie bei der Modellierung stets berücksichtigen sollten:

Zielgruppe: Wer soll mit dem Modell arbeiten, wer soll Diagramm xy lesen (Fachbereich, Architekten, Entwickler, Kunden)? Wie sind die UML-Kenntnisse der Zielpersonen? Für einen UML-phoben Kollegen aus dem Fachbereich werden Sie ein Diagramm sicher weniger komplex gestalten als für einen UML-affinen Entwickler.
Verwendungszweck: Wofür soll das Modell eingesetzt werden (Kommunikation, Projektplanung, Dokumentation, Basis für Folgeprojekte, Code-Erzeugung, etc.)? Die Erzeugung von Code aus dem Modell erfordert eine detaillierte Modellierung, während dies bei ersten Planungsgesprächen sicherlich fehl am Platze ist, da hier Abstraktion gefordert ist.
Tool: Traurig aber wahr, oft beschränkt die verwendete Software die Möglichkeiten der Modellierung.
Randbedingungen des Projekts: Vorgehensmodell, Zeit, Budget, Anzahl beteiligter Personen, Lebensdauer des Modells, Stabilität der Anforderungen, etc. Sie können nur soviel Geld und somit Zeit in die Modellierung investieren, wie Ihnen zu Verfügung steht, aber die Verteilung auf den Inhalt können Sie selbst gestalten. Arbeiten viele und/ oder wechselnde Personen mit dem Modell über längere Zeit hinweg, so werden Sie mehr Gewicht auf ein sauberes, mit erklärenden Kommentaren versehenes Modell legen als bei einer kleinen, stabilen Zielgruppe und einer kurzen Modell-Lebensdauer. Wenn sich Anforderungen oft ändern, ist eine detaillierte Modellierung weniger sinnvoll, da diese bei jeder Änderung aktualisiert werden muss (»Moving Target«-Phänomen). Hier können ein paar Zeilen Text hilfreicher sein als detaillierte, aber veraltete Diagramme.

Die hohe Kunst liegt darin, das Modell so zu gestalten, dass es den Entwicklungsprozess optimal unterstützt. Die fehlenden Vorgaben und eher abstrakte Semantik der UML sind so gesehen kein Manko, sondern ein großer Vorteil. Der Werkzeugkasten ist universell einsetzbar und äußerst reichhaltig – nur eben für den Neuling etwas unübersichtlich. Ein Beispiel: Use- Cases stellen Funktionen eines Systems dar. Nun ist »System« ein sehr abstrakter Begriff, da von einem Unternehmen bis hin zur kleinsten Komponente einer Software alles ein »System« im eigentlichen Sinne des Wortes ist. Das bedeutet, abhängig vom Kontext lässt sich von Geschäftsprozessen über Systemfunktionen bis hin zu Komponentenfunktionen alles in Use-Case-Diagrammen abbilden.

Mit Klassendiagrammen müssen nicht immer Softwareklassen dargestellt werden. Wir können sie ebenso in der Analysephase als eine Art vernetztes Glossar (Begriffsmodell) einsetzen. Hierfür geben wir den Klassen lediglich weniger kryptische Namen und sehen in den Attributen Eigenschaften von Dingen aus der realen Welt. Die Assoziationen repräsentieren dann Beziehungen und Abhängigkeiten zwischen den Begriffen aus der Fachwelt. Und zudem hängt es vollkommen vom Entwickler ab, ob er mit 20 Klassen das Fachgebiet nur grob umreißt oder mit 200 Klassen eine sehr genaue Repräsentation davon konstruiert. Der Entwickler hat also bezüglich Inhalt und Abstraktionsgrad weitgehend freie Hand.