Software-Entwicklung Informationszentrale UML

Während der Software-Entwicklung gilt es, die Daten aus Anforderungen, Architektur, Design, Implementierung, Test und Dokumentation synchron zu halten. Die Unified Modeling Language (UML) kann dazu dienen, all diese Quellen in nur einer Datenbasis zu vereinen.

Kunden-, System-, Software-, Testanforderungen und andere Dokumente, die in irgendeiner Form mit dem (Software-) System verknüpft werden müssen, lassen sich regelbasiert in ein UML-Projekt importieren und synchronisieren. Die importierten Elemente können mit Hilfe der System Modeling Language (SysML), einer Erweiterung von UML, durch verschiedene Beziehungstypen miteinander verknüpft werden. Dies kann auf jeder beliebigen Abstraktionsebene geschehen. Aus diesen Informationen lassen sich Traceability-Matrizen für die Dokumentation erstellen. Über die Verknüpfungen kann festgestellt werden, ob bereits alle Anforderungen berücksichtigt wurden, oder welchen Einfluss eine Anforderungsänderung auf die Software oder das gesamte System hat.

Überblick behalten

Mit Hilfe von Architekturen werden komplexe (Software-) Systeme in logische, zusammengehörige Pakete unterteilt, um die Komplexität zu minimieren. Die Hierarchie ist beliebig. Typische Layer sind ein HAL (Hardware Abstraction Layer), ein Driver Layer, ein Service Layer oder ein Application Layer. Durch die Definition der verschiedenen Ebenen und durch weitere Unterteilung in einzelne Elemente werden vermeintlich komplexe Systeme in kleinere, verständlichere Einheiten aufgeteilt. Diese lassen sich leichter planen, wiederverwenden, instandhalten und testen. Die Einhaltung von Architekturregeln kann ebenfalls leichter überprüft werden. Über die Architektur können Diagramme erstellt werden, die einen Überblick über das gesamte (Software-) System bieten. Durch geschicktes Verknüpfen von Diagrammen lässt es sich von einer Gesamtübersicht bis in die einzelnen Elemente navigieren.

Architekturen und Designs benötigen zusätzlich einen beschreibenden Text. Dieser lässt sich für jedes Diagramm und jedes Element hinterlegen. Die Informationen können mit zusätzlichen Angaben, beispielsweise mit der Verwendung von Tags, verfeinert werden. Aus Diagrammen, Elementen und Beschreibungen lassen sich Dokumentationen generieren. Weil die Elemente und die beschreibenden Texte gemeinsam im Modell gespeichert werden, kann man sich sicher sein, dass beispielsweise der Name einer Funktion korrekt dokumentiert wird. Die gleichen Informationen können in unterschiedlichen Dokumenten wiederverwendet werden. So lässt sich für den Kunden ein Dokument mit reduziertem Informationsgehalt erstellen und ein ausführlicheres Dokument für interne Zwecke. Mit wenigen Änderungen können bei Bedarf aus der gleichen Vorlage unterschiedliche Ausgabeformate generiert werden. So kann es sinnvoll sein, eine Dokumentation in Word und in HTML zu erzeugen.

Architekturen und Designs sind nicht nur zur Übersicht gedacht. Wie bereits beschrieben geht es bis ins Detail auf Funktionsebene. Somit ist bereits die Struktur der Software vorhanden und es fehlt nur noch die Implementierung der einzelnen Funktionen. Weshalb sollte man also nicht auch noch die Implementierung einer Funktion im Modell speichern? Mit dem generierten Code wird nicht nur sichergestellt, dass Namen von Datentypen, Funktionen, Signaturen und weitere Elemente mit dem Modell und somit mit der Dokumentation übereinstimmen, man kann auch gleich den beschreibenden Text der Elemente als Kommentare in den Quellcode einfügen. So hat man abermals die Dokumentation wiederverwendet. Mit kleinen Änderungen in den Projekt-Einstellungen können Quellcode-Kommentare in einem anderen Format (z.B. Doxygen) oder mit zusätzlichen Informationen generiert werden. So können beispielsweise Verknüpfungen zu Anforderungen in den Kommentar eingefügt werden.

Test-Software, die keine Integration in die UML hat, kann wie normaler Quellcode modelliert und generiert werden. UML unterstützende Test-Tools bieten die Möglichkeit, die Tests gegen existierende Diagramme zu verifizieren. Auch hier können Tests mit den (Test-) Anforderungen und den getesteten Software-Teilen verknüpft werden. Dokumentation kann auf die gleiche Weise erfolgen wie für die Software.

Mit Hilfe von unterschiedlichen Komponenten-Definitionen lassen sich über die Festlegung des Geltungsbereiches unterschiedliche Varianten bilden. Dabei kann eine Variante beispielsweise durch Substitution definiert werden. Einige UML-Tools bieten noch deutlich cleverere Mechanismen.

Für das Generieren, Kompilieren und Linken des Quellcodes können unterschiedliche Konfigurationen definiert werden. Mit Hilfe dieser Konfigurationen kann sehr einfach zwischen unterschiedlichen Zielplattformen gewechselt werden. Manche Konzepte sehen vor, den Quellcode im IDE/EDE der Zielplattform zu generieren, um dort zu kompilieren und im Simulator zu debuggen. Geänderter Code kann über einen Roundtrip-Mechanismus wieder ins Modell zurück synchronisiert werden.

Modellgetriebene Entwicklung

Die UML ist so mächtig und vielseitig, dass viele gar nicht wissen, wie sie die Sprache am besten einsetzen sollen. Mit der UML ist es wie bei jeder anderen Programmiersprache: Um gut zu werden, sind jahrelanges Training und die kontinuierliche Verwendung der Sprache nötig. Im Folgenden wird ein Beispiel gegeben, wie man die UML einsetzen kann. In welchem Umfang die Sprache eingesetzt wird, muss jeder selbst entscheiden.

In der Automobilindustrie ist das V-Modell weit verbreitet. Allerdings wird es oft mit dem Wasserfall-Modell in Verbindung gebracht. Tatsächlich hat es damit nichts zu tun. Es werden lediglich die benötigten Prozess­schritte aufgezeigt. In welcher Reihenfolge diese bearbeitet werden oder ob man sie sequenziell oder parallel bearbeiten muss, wird damit nicht festgelegt. In Bild 1 ist ein V-Modell zu sehen, welches die erforderlichen Prozess­schritte zeigt. Zu beachten sind die Querverweise der linken und rechten Seite. Mit den kreisförmigen Pfeilen soll angedeutet werden, dass man mehrere Iterationen durchlaufen kann. Es lässt sich beliebig vor und zurück navigieren. Spätestens ab der Architektur bis zum Integrationstest kann der gesamte Entwicklungszyklus mit Hilfe der UML abgebildet werden.
Die kreisförmigen Pfeile mit den Angaben n, n+1 und n+2 repräsentieren einzelne Sprints (Entwicklungsintervalle) aus der Scrum-Methode. Die Architektur-Ergebnisse aus dem Sprint n werden im Sprint n+1 verfeinert und implementiert und im Sprint n+2 im Systemtest verifiziert.