Wenn ich mich manchmal mit Leuten unterhalte und sie nach UML frage, kommt öfter einmal die Antwort, das seien doch die Klassendiagramme. Auch vor allem in älteren Büchern zu dem Thema kann man teilweise den Eindruck gewinnen, die UML-Klassendiagramme wären das allerwichtigste Diagramm der Modellierungssprache.

Nach 15 Jahren Anwendung von modellbasierter Entwicklung kann ich inzwischen sagen, dass UML und auch SysML viel mehr ist als Klassendiagramme – oder Blockdefinitionsdiagramme in SysML. Sie sind zwar wichtig und nützlich für Daten- und Klassenmodellierung, jedoch ist dies nur ein kleiner Teil, wenn es darum geht modellbasiert eine Software oder ein System zu spezifizieren und zu beschreiben. Klassendiagramme sind vom Abstraktionsgrad nah an der Implementierung dran. Für einen Softwareentwickler hat daher das Klassendiagramm auch nur eine untergeordnete Bedeutung, da er meist sowieso täglich in seiner Entwicklungsumgebung seine Klassen vor Augen hat und diese auch gut überblickt.

Viel wichtiger als Klassendiagramme sind eigentlich die Diagramme, die eine größere Struktur eines Softwaresystems aufzeigen und beschreiben. Dazu zählt zum Beispiel das Komponenten-, Kompositionsstruktur- oder Deploymentdiagramm in UML oder das Interne Blockdiagramm in SysML.

Außerdem extrem hilfreich in der Praxis sind die Verhaltensdiagramme, mit denen man das Verhalten von Komponenten oder des Gesamtsystems beschreiben kann. Vielen Anwendern der UML und SysML kaum bewusst, ist dass man die strukturellen und die dynamischen (Verhaltens-)Aspekte in einem Modell wirklich richtig formal koppeln kann. Dies unterstützt die Definition von UML von Hause aus und es wird durch die Modellierungswerkzeuge – zum Beispiel in Sparx Systems Enterprise Architect – auch umgesetzt.

Mann kann also durch geschicktes Kombinieren von strukturellen und Verhaltensdiagrammen eine Software so genau spezifizieren, das ein Codegenerator aus einem solchen Modell komplett ausführbare Software generieren kann.

LieberLieber kann Sie dabei unterstützen modellbasierte Entwicklung schrittweise weiterzuentwickeln, damit Modellsimulation, Codegenerierung und noch vieles mehr möglich wird. Den Klassendiagrammen werden Sie dabei zwar ab und an auch noch begegnen, aber eher am Rande.