UML
Die Unified Modelling Language (UML) ist heute der Standard zur Darstellung von Software. Dabei gibt es eine ganze Reihe aufeinander aufbauender Diagramme, sodass eine Software-Entwicklung in allen Phasen von der ersten Idee über Architektur und Entwicklung bis zur Installation dargestellt werden kann.
Dieser Universalitätsanspruch der UML ist sowohl Stärke als auch Schwäche: Die Notation wurde so umfassend und universell angelegt, dass es eigentlich nichts im Umfeld von Soft- und Hardware gibt, dass sich damit nicht darstellen ließe. UML-Diagramm zu lesen ist nicht besonders schwierig. Die UML lässt viel Freiraum für die unterschiedlichsten Arten von Softwareprojekten, was letztendlich aber auch heißt, dass die konkrete Anwendung im Projekt einiges an Konzeptionsarbeit mit sich bringt.
Die PI-Data hat inzwischen in einer Vielzahl von Projekten bei der Einführung und Anwendung der UML unterstützt.
Die UML bietet jeweils sieben verschiedene Diagrammtypen für den statischen Blickwinkel (Strukturdiagramme) und den dynamischen (Verhaltensdiagramme). In diese Vielfalt der Diagramme macht zu einem guten Teil die Mächtigkeit der UML aus. In vielen Projekten wird aber nur eines oder wenige Diagrammtypen genutzt.
Abstraktionsebenen
Ebenfalls wenig verstanden ist die Möglichkeiten, die Diagramme für unterschiedliche Abstraktionsebenen zu nutzen. Z.B. kann das Klassendiagramm nicht nur zur exakten Abbildung von Quelltext-Klassen genutzt werden, sondern genauso ganz zu Beginn eines Projekts zur Sammlung von Entitäten (Begriffen) und deren Beziehungen untereinader (Ontologie). Weiter verfeinert ergibt sich daraus das fachliche Datenmodell.
Ein typischer Ansatz für UML-Modelle mit mehreren Abstraktionsebenen beginnt mit UseCases, die dann in Form von Aktivitätsdiagrammen verfeinert werden. Parallel dazu wird eine Ontologie in einem Klassendiagramm gebaut und die groben Zustände des Systems in Form von Zustandsautomaten erfasst. Je nach Bedarf können auch in der höchsten Abstraktion bereits alle UML-Diagrammtypen zum Einsatz kommen. Nun braucht es je nach Umfang des Projekts eine oder mehrere weitere verfeinernde Abstraktionsstufen.
Mit Kompositionsstrukturdiagrammen oder SysML-Blockdiagrammen wird das Gesamtsystem in kleinere Bausteine heruntergebrochen und deren Schnittstellen grob erfasst.
Spätestes in der Implementierung dienen Sequenzdiagramme dazu das Verhalten einer Schnittstelle genau zu spezifizieren. Komponentendiagramm stellen dann dar, welche Komponenten es gibt und welche Schnittstellen diese anbieten bzw. nutzen.
Wenn Hardwareprotokolle ins Spiel kommen, wird das Zeitverlaufsdiagramm unverzichtbar.
Die direkte Abbildung des Quelltextes in der UML bringt vor allem bei kleineren Projekten wenig Mehrwert. Insbesondere beim Einsatz von modernen Entwicklungsumgebungen gibt es dort ausreichend andere Mittel, sich einen Überblick über den Quelltext zu verschaffen. Beim Einarbeiten neuer Mitarbeiter oder in fremde Quelltexte kann das Erzeugen von Diagrammen (v.a. Klassendiagramme) aus dem Quelltext aber durchaus ein gutes Hilfsmittel sein.
Codegenerierung
Aus vielen Diagrammen kann auch Quelltext (Code) generiert werden. Auf diesem Weg lässt sich sicherstellen, dass das Modell die Implementierung tatsächlich korrekt wieder gibt. Besonders beliebt ist die Generierung von Schnittstellen und deren Implementierungsrümpfen aus Klassendiagrammen. Zustandsdiagramme sind ebenfalls Paradebeispiele für Code-Generierung, auch wenn dies viel zu selten praktiziert wird.
Spezifikation und Modell
Aus unserer Sicht einer der größten Fehler in vielen großen Projekten ist der Glaube, dass ein Modell erst nach der Spezifikation quasi als Werkzeug zur Software-Architektur verwendet wird. Vor allem bei den ersten Schritten von einer Idee zu einer Spezifikation ist das UML-Modell mit seinen grafischen Möglichkeiten das ideale Werkzeug.
Wir sind der Meinung, dass das Modell fester Bestandteil einer guten Spezifikation sein muss und Hand in Hand mit einer textuellen Spezifikation (Lastenheft, Pflichtenheft, …) gehen sollte.
Nicht selten haben wir es erlebt, dass der Fachbereich viel lieber ein UML-Modell zur Spezifikation nutzen wollte. Wenn das Management trotzdem ein Lastenheft forderte, wurde dies aus dem UML-Modell generiert, z.B. mit unserem Synchronizer. Wie sehr daneben dieser Ansatz ist, merkt man spätestens dann, wenn der Lieferant als Erstes auf Basis des Lastenhefts ein UML-Modell erstellt.
UML statt PowerPoint
Unter dem Begriff “PowerPoint macht dumm” habe schon viele andere die Nutzung von Malwerkzeugen zu Spezifikation oder technischen Zusammenhängen kritisiert. Grund dafür ist, dass damit ganz schnell mal ein paar Kästchen, Linien und Pfeile gemalt sind und sich jeder Zuschauer ein anderes Bild macht, was diese bedeuten. Wir legen den Finger gerne in diese Wunde, indem wir die Frage stellen, was die einzelnen Kästchen, Linien und Pfeile bedeuten. Selbst wenn der Autor dann mit einer Erklärung kommt, stellt sich in der Regel heraus, dass er sich schon auf einer einzelnen Seite nicht konsequent an seine eigene Definition gehalten hat.
Wer die UML verwendet und sich brav an deren Spezifikation hält, umgeht dieses Problem der Unschärfe. Und wenn man sich dann schwertut, etwas mit der UML darzustellen ist dies in der Regel ein Zeichen dafür, dass man der darzustellenden Kontext selbst noch nicht richtig verstanden hat.
Die UML zwingt einen dazu präziser nachzudenken und hilft damit bereits in frühen Projektphasen grundlegende Konzeptfehler aufzudecken.
Ein schönes Beispiel aus unseren Projekten war die Modellierung der Zustände eines Kfz-Stop-Start-Systems. Das bereits implementierte System sollte dokumentiert werden und wir konnten nur mit viel Mühe die Kollegin davon überzeugen, einen UML Zustandsautomaten zu erstellen. Beim Durchsprechen des Automaten mit den Entwicklern entdeckten diese zwei nicht bedachte Zustandsübergänge. Wer weiß wann man diese Fehler ohne UML gefunden hätte - wenn es erst beim Kunden aufgefallen wäre, wäre das eine teure Rückrufaktion geworden.
UML-Historie bei PI-Data
Bei PI-Data wird die UML seit der ersten Version im Jahr 1997 eingesetzt und seit 2007 unterstützen wir unsere Kunden beim Einsatz der UML allgemein und den Tools EnterpriseArchitect und Rhapsody im Speziellen.
Bei Mercedes-Benz haben wir im Spezifikations-Projekt PPG UML als Notation eingeführt und dann gemeinsam mit dem Fachbereich genutzt.
Im Projekt EPDM bei Mercedes-Benz wurde mit einer Vielzahl von Spezifikateuren ein großes IT-System entwickelt. Wir waren hier mittreibende Kraft bei der Einführung des UML-Tools Enterprise Architect als Spezifikations-Werkzeug. Die Spezifikation wurde in Form des UML-Modells dem Lieferanten übergeben, der die Applikation implementierte. Somit war es möglich, dass nicht unerhebliche Teile der Anwendung vollautomatisch aus dem Modell heraus generiert wurden. Vor allem bei der Pflege von UI-Elementen und Dialogen führte dies zu einer erheblichen Kostenreduktion.
Ab 2009 durften wir dann in mehreren Projekten die UML einführen und traten dort sowohl als Methodenberater als auch als Tool-Entwickler auf. Aus den vielen für diese Projekte entwickelten Hilfswerkzeugen für Enterprise Architect entstand dann 2016 die SysLand-Toolbox.
Als 2018 erkennbar wurde, dass Mercedes-Benz IBM Rhapsody als offizielles UML-Werkzeug einführen wird, haben wir uns dazu entschlossen eine abstrahierende UML-Schicht in die SysLand-Toolbox einzubauen. Die in der SysLand-Toolbox vereinten Modellier-Helfer greifen nun auf eine aus dem UML-Metamodell generierte allgemeine UML-Schnittstelle zu. Diese Schnittstelle wird dann je UML-Tool auf dessen spezifische API abgebildet.
2018 begannen wir dann mit der Implementierung der UML-Schnittstelle für IBM Rhapsody. Von 2021 bis 2024 waren wir dann als Tool-Experten und Anwender-Coaches im Projekt MBSE bei Mercedes-Benz aktiv und konnten dort wesentlich zur Stabilität und konzeptionellen Weiterentwicklung beitragen.
Ein besonderes Highlight war die Einführung eines Metamodells und Entwicklung unseres Metamodell-Checkers. Damit wurde es erstmals möglich eine mit der Realität konsistente Beschreibung der Modellierungsregeln zu erstellen und darauf basierend zu prüfen, dass diese in den Modellen auch umgesetzt werden. Mit einer ersten großen Aufräumaktion konnten so eine große Zahl kleiner und auch größerer Fehler, die sich über die Jahre angesammelt hatten, im zentralen Modell entdeckt und behoben werden.