Durchgängige Anforderungs-, System- und Testfallbeschreibung mit UML

Kurzfassung

Die Softwareentwicklung wird seit Jahren von dem Umstand geprägt, dass Leistungsfähigkeit der Hardware und Komplexität der Programme einem exponentiellen Wachstum unterliegen, während die Methoden der Softwareentwicklung nur langsam voranschreiten. Die Codeerzeugung geschieht in den meisten Fällen nach wie vor manuell und weit verbreitete Programmiersprachen wie C oder C++ blicken auf eine 35- bzw. knapp 25-jährige Tradition zurück. Vor allem in der eher konservativ geprägten Domäne der Eisenbahnleit- und -sicherungstechnik erweist sich die Einführung neuer Methoden oft als schwierig, was aus mehreren Gründen nachvollziehbar ist. Zum einen trägt die zu entwickelnde Software Sicherheitsverantwortung. Daher verbieten sich Techniken wie beispielsweise dynamische Speicherallokation / Objekterzeugung, Polymorphismus oder Multithreading, die in anderen Bereichen in den vergangenen Jahren weite Verbreitung fanden. Zum anderen sind die Produktlebenszyklen extrem lang (z. T. mehrere Jahrzehnte), so dass sich sofort die Frage der Altsystempflege (sog. Legacy Systems) stellt. Um ”methodischen Ballast“ zu vermeiden, werden nur wenige Neuerungen eingeführt, um die Zahl parallel verwendeter Entwicklungsverfahren überschaubar zu halten. Und schließlich sind die Stückzahlen der später gefertigten Systeme vergleichsweise gering. Daraus ergibt sich ein signifikater Anteil der Entwicklungskosten an den Produktkosten, was wiederum zu einer pessimistischen Bewertung von Risiken – wie beispielweise neuen Methoden – führt. Heutige Entwicklungsprozesse der Eisenbahnleit- und -sicherungstechnikdomäne weisen aber in vielen Punkten erhebliche Verbesserungspotentiale auf, so dass die Chancen-Risiken-Abwägung füur moderne Methoden neu überdacht werden muss: • Systemspezifikation, Systemarchitekturspezifikation und Schnittstellenbeschreibungen liegen informal als Klartextdokumente in Prosaform vor. • Testfälle werden manuell abgeleitet, spezifiziert und ausgeführt. Die Dokumentation des Testaufbaus ist häufig unzureichend. Tests sind insgesamt schwer reproduzierbar und wiederverwendbar. • Das Verhalten vieler Subsysteme und Module ließe sich gut auf (endliche) Zustandsmaschinen abbilden und würde so einer automatischen Codeerzeugung und formalen Verifikation zugänglich. Tatsächlich wird der Code aber manuell erstellt und getestet. Die Notwendigkeit zur Umsetzung neuer Entwicklungsnormen wie der DIN EN 61508 (Funktionale Sicherheit sicherheitsbezogener Systeme) und der DIN EN 50126 ff. (Zuverlässigkeit, Verfügbarkeit, Instandhaltbarkeit und Sicherheit von Bahnanwendungen) sowie dieWettbewerbsverschärfung 1C wurde 1972 entwickelt und C++ 1983. Eine Standardisierung von C++ als ISO/IEC 14882 erfolgte jedoch erst 1998 durch die Einführung eines europaweit einheitlichen Zugsicherungssystems (ETCS: European Train Control System) erhöht den Druck auf die Hersteller, neue Konzepte in ihre Entwicklungsprozesse zu integrieren, um konkurrenzfähig zu bleiben. Am Institut für Verkehrsführung und Fahrzeugsteuerung des DLR wurde daher unter Verwendung der Unified Modeling Language (UML) ein Vorgehen erarbeitet, mit dessen Hilfe sich eine vollständige Systementwicklung modellbasiert begleiten lässt. Die Kernaspekte sind ein integriertes Anforderungs-, System- und Testmodell auf Basis der kürzlich verabschiedeten UML-Profile SysML (Systems Modeling Language) und U2TP (UML 2 Testing Profile), die modellinterne Verfolgbarkeit von Anforderungen auf die Implementierungs- und Testebene und die Möglichkeit zur Erzeugung von Code aus dem Modell). Die Leistungsfähigkeit des Konzeptes wurde anhand einer Fallstudie nachgewiesen, in der die Entwicklung einer Komponente des DLR-Eisenbahnsimulationslabors RailSiTe® UML-basiert nachvollzogen wurde. Dieser ”Proof-of-Concept“ zeigte unter anderem, dass • Anforderungs- und Umsetzungsbeziehungen durch alle Modellteile aufgebaut und skriptbasiert ausgewertet werden können. • der aus dem UML-Modell erzeugte Code direkt auf einem eingebetteten System (Digitaler Signalprozessor) korrekt ausgeführt werden kann. • die Testfallbeschreibung effektiv und übersichtlich ist und eine optimale Grundlage für eine Testautomatisierung darstellt. Die Präsentation wird die Details des Konzeptes darstellen und auch einen Ausblick auf weiterführende Arbeiten geben. Das bezieht sich vor allem auf eine Testautomatisierung durch Überführung der UML-Testfallbeschreibungen in die Sprache TTCN-3 (Testing and Test Control Notation, Version 3) und eine formale Verifikation des Systemverhaltens durch Techniken wie Bounded Model Checking oder SAT-checker.