Software-Entwicklung
Informationszentrale UML
Fortsetzung des Artikels von Teil 2
Implementierung: bis ins Detail
Die Ergebnisse der Architektur werden als Basis für das Design verwendet. Hierbei wird die gleiche Vorgehensweise wie bei der Architektur angewandt. Das Ganze geschieht nur eine Abstraktionsebene tiefer (Bild 3). Die Klasse VehicleMonitor ist die Schnittstelle für die anderen Module. Die grün eingefärbten Klassen (SyncOdometerService und PlausiChecker) sind Bestandteile des VehicleMonitor, die sich untereinander verwenden, aber niemals direkt von anderen Modulen verwendet werden. So entstehen die internen Elemente eines Moduls inklusive der benötigten Schnittstellen. Mit dem Wissen, wie die Schnittstelle eines Moduls aussieht, kann bereits mit den Modultests begonnen werden. Diese Tests sind auch bekannt als Blackbox-Tests.
Jobangebote+ passend zum Thema
Das Modul VehicleMonitor wird mit seinen zusätzlichen Klassen verfeinert. Auch hier können wieder Tests mit dem Sequenzdiagramm verknüpft werden, um die Testspezifikation zu definieren und die Nachverfolgbarkeit sicherzustellen. Anders als dargestellt könnte auf die anderen Module im Diagramm verzichtet werden, da für das Modul nur die Eingabe- und Ausgabeschnittstellen von Bedeutung sind, ungeachtet dessen, wer Sender oder Empfänger der Nachrichten ist. Hier werden die anderen Module zum besseren Verständnis beibehalten.
Mit der Architektur und dem Design existiert bereits die gesamte Struktur der Software. Selbst die einzelnen Klassen, Datentypen und Operationen sind definiert. Somit fehlt es nur noch an den Inhalten der einzelnen Operationen – nur noch ein kleiner Schritt zur vollständigen Code-Generierung. Auf Implementierungsebene werden Unit Tests entwickelt, um die Implementierung auf tieferer Abstraktionsebene zu verifizieren. Diese Tests sind auch bekannt als Whitebox-Tests.
Die Tests wurden in der Architektur, dem Design und der Implementierung bereits angesprochen. Hier sei aber noch erwähnt, dass man mit den oben beschriebenen Konzepten die Tests vor der Implementierung, gleichzeitig oder hinterher entwickeln kann. Es ist sogar möglich, die Sequenzdiagramme aus Architektur und Design automatisiert für Tests zu verwenden. Dazu wird die Software in einem Animationsmodus ausgeführt und mit Hilfe von instrumentiertem Code ein Sequenzdiagramm aufgezeichnet, das mit dem referenzierten Diagramm verglichen wird. Auf diese Weise wird direkt gegen die Anforderungen getestet, sofern man davon ausgehen kann, dass die Sequenzdiagramme den Anforderungen entsprechen.
Sämtliche Modellelemente werden in einem Textfeld und ggf. mit zusätzlichen Tags beschrieben. Bei klar definierter Struktur des Software-Modells lassen sich Templates zur Dokumentengenerierung erstellen und damit zu jeder Zeit eine aktuelle und gültige Dokumentation der Software erstellen. Implizit wird sichergestellt, dass vorgegebene Strukturen eingehalten werden.
- Informationszentrale UML
- Bild von außen: die Architektur
- Implementierung: bis ins Detail
- Code-Generierung: so gut wie handgeschrieben
- Zustandsautomaten: Ereignis- oder Nachrichten-getrieben
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Blick ins Zielsystem
UML-Modelle debuggen
Modellierung von E/E-Systemen
UML und AUTOSAR
Modellbasierte und textuelle Systemdokumentation
UML - mehr als nur Bilder
