-
Es
ist bekannt, dass Fehler in der Software zu hohen Kosten oder Personenschäden
führen kann. Aus diesem Grund kommt der Verifikation, d.
h. Sicherstellung der Einhaltung von definierten Bedingungen, große
Bedeutung zu. Dazu ist es aber bisher erforderlich, den Quellcode
jedes Teils der Software zur Verfügung zu stellen. Dies
verhindert häufig den Einsatz von Verifikationsverfahren
und ermöglicht gleichzeitig nicht die Verifikation von
Software, die aus Bausteinen zusammengesetzt wurde, deren Bausteine
dynamisch (z. B. nach Bedarf) eingebunden werden oder in verschiedenen
Programmiersprachen entwickelt wurden.
-
Softwaresysteme
werden in zunehmendem Maße aus vorgefertigten bzw. extra
angefertigten, weitgehend abgeschlossenen Bausteinen erstellt. (Software-)Bausteine
zeichnen sich zumeist dadurch aus, dass sie eine abgeschlossene
Funktionalität über eine definierte Schnittstelle
zur Verfügung stellen. Es ist möglich, dass verschiedene
in einer Software benutzte Bausteine in verschiedenen Programmiersprachen
implementiert wurden.
-
Die
Kompatibilität dieser Bausteine wird nach aktuellem Stand
der Technik auf technischer Ebene nur auf Basis von Schnittstellen,
so genannten Signaturen, definiert. Probleme bereitet dabei die Kontrolle,
ob ein bzw. mehrere Bausteine entsprechend dem Gesamtkonzept funktionieren.
Schnittstellen sagen wenig über die dahinter verborgene
Semantik aus. Diese Semantik wird deshalb häufig als textuelle
Beschreibung (API-Dokumentation) zusätzlich zur technischen
Beschreibung der Schnittstelle angegeben. Dies hat den Nachteil,
dass eine Überprüfung nicht erfolgen kann.
-
Die
Erfassung bzw. Überprüfung der Semantik eines
Bausteins ist mittels Rückübersetzen (Decompilieren)
möglich, wenn der Quellcode nicht zur Verfügung
steht Diese Möglichkeit erweist sich nur in wenigen Fällen
als Praxis tauglich, da die Rückübersetzung von
Binärcodes zwar die Semantik erhält, im Allgemeinen
aber nicht wieder den ursprünglichen Quellcode, sondern
nur einen semantisch äquivalenten zumeist deutlich weniger
kompakten Quellcode erzeugt. Einfacher stellt sich dies dar, wenn
nur in eine Zwischensprache übersetzt wird und zur Ausführung
eine virtuelle Maschine oder ähnliches zum Einsatz kommt.
Unmöglich wird die Rückübersetzung, wenn
der eingebundene Baustein nicht lokal verfügbar ist, sondern
z. B. über das Internet eingebunden wird (z. B. als Webservice).
-
Testverfahren
können nur sehr eingeschränkt eingesetzt werden,
wenn Eigenschaften überprüft werden sollen, da
kein Nachweis möglich ist, dass der verwendete Baustein,
die gewünschten Eigenschaften aufweist. Besonders problematisch gestaltet
es sich, wenn nicht nur Ergebnisse, sondern auch das Verhalten der
eingebundenen Softwarebausteine überprüft werden
sollen.
-
Liegt
der Quellcode des Softwarebausteins vor, ist entweder der Einsatz
eines hoch qualifizierten Entwicklers erforderlich, der sowohl die
Programmiersprache versteht, als auch über fundierte Kenntnisse
von Verifikationsverfahren verfügt, um die Semantik des
Programmcodes in mathematische bzw. logische Formeln zu übersetzen
und diese soweit möglich auch unter zu Hilfenahme von Werkzeugen zu überprüfen.
-
Eine
weitere Möglichkeit besteht darin, bestimmte Eigenschaften
des Quellcodes (halb-)automatisch zu verifizieren. Dadurch kann
die Überprüfung verschiedener Kriterien mittels
dafür vorgesehener Logiken bzw. Werkzeuge erfolgen, nachdem
der Quellcode (halb-)automatisch in eine für das benutzte
Werkzeug verständliche Darstellung überführt
wurde. Eine solche Überprüfung kann aber sehr
zeitaufwändig sein, wenn der zu überprüfende
Programmcode groß ist oder die Problemstellung anspruchsvoll ist.
-
Bisher
bekannte Verfahren überprüfen häufig
logische Eigenschaften innerhalb eines Bausteins. Benötigt
wird häufig ein Verfahren, das das Zusammenspiel von verschiedenen
Komponenten überprüfen kann. Bereits in Nierstrasz /1/
wird eine statische Überprüfung von Objektlebenszyklen
vorgeschlagen. Dabei werden aber nur reguläre Sprachen
eingesetzt, um das dynamische Verhalten von Objekten zu beschreiben.
In Löwe et al. /2/ werden Objektlebenszyklen
benutzt, um Implementierungen austauschbar zu machen, wobei die
Konformität beibehalten werden soll. Es werden ebenfalls
reguläre Sprachen benutzt. In Tenzer und Stevens /3/
werden UML-Zustandsmaschinen verwendet, um die Objektlebenszyklen
darzustellen. Um auch die Rekursion erfassen zu können,
werden die regulären Sprachen um einen Mechanismus erweitert,
der die Rekursion ermöglichen soll. In Zimmermann
und Schaarschmidt /4/ werden kontextfreie Sprachen als
Abstraktion verwendet, welche es ermöglichen, die Rekursion
im vollen Umfang darzustellen. Des Weiteren wird ein Verfahren zum
Zusammensetzen von Abstraktionen vorgestellt, welches es ermöglicht,
Abstraktionen von Softwarebausteinen unabhängig zu erstellen
und erst anschließend im Sinne der gewünschten
Software zusammenzusetzen.
-
Die
genannten Verfahren betrachten nur sequenzielles Verhalten der Software.
Aus diesem Grund sind sie nur sehr eingeschränkt einsetzbar.
-
Es
ist alternativ möglich, Petri-Netze zur Darstellung des
Verhaltens von Bausteinen zu verwenden, s. Hinz et al. /5/.
Diese stellen ein paralleles Verhalten sehr gut dar, erfassen aber
keine sequenzielle Semantik.
-
Schmidt
et al. /6/ verwendeten neben endlichen Automaten (reguläre
Sprachen), um die Konformität zu überprüfen.
Diese können paralleles Verhalten abbilden, aber nicht
mit Rekursion im allgemeinen Fall umgehen.
-
Eine
Alternative ist, zur abstrakten Darstellung der Semantik einer Software
Prozess Algebren zu nutzen. Diese vereinigen Elemente parallelen
und sequenziellen Verhaltens, s. Allen und Garlen /7/. Verschiedene
technische Gegebenheiten beschränken jedoch die Möglichkeiten
der Verifikation auf reguläre Sprachen oder verifizieren
nicht die Interaktionen zwischen den Softwarebausteinen, s. Foster
et al. /8/.
-
In Chaki
et al. /9/ werden in der Programmiersprache C implementierte
Softwarebausteine betrachtet, welche unabhängig von einander
arbeiten. Es werden Kellerautomaten verwendet, so dass auch Rekursion
erfasst werden kann. Dabei werden aber nur synchrone Interaktionen
betrachtet.
-
Weitere
Ansätze z. B. Chamber /10/ oder Ramalingam /11/
nutzen eine dynamische Überprüfung der vorgegebenen
Eigenschaften. Dies ermöglicht aber nur eine statische Überprüfung,
wenn gleichzeitig ein vollständiger Test durchgeführt
wird, welcher praktisch nur selten durchführbar ist.
-
Es
stellt sich somit das Problem, bereits vor Einsatz eines Bausteins
zu verifizieren, ob dieser nach der Einbindung in ein Softwareprojekt
die vorgegebenen Bedingungen erfüllt bzw. erfüllen
wird. Diese Bedingungen umfassen die Interaktionsmöglichkeiten
zwischen verschiedenen Bausteinen. Diese Interaktionen können
sowohl asynchrones Verhalten (z. B. parallele Ausführung,
asynchrone Methodenaufrufe, etc.), als auch synchrones Verhalten
(z. B. Rekursion, synchrone Ausführung, etc.) enthalten.
-
Fehler,
d. h. Verletzungen der Bedingungen, sollen ausgeschlossen bzw. in
jedem Fall aufgefunden werden können. Darüber
hinaus soll es möglich sein nachzuweisen, dass eine korrekte
Abbildung des gewünschten Verhaltens existiert. Insbesondere soll
es nicht erforderlich sein, vor der Überprüfung über
ein vollständiges System zu verfügen und den Quellcode
der benutzten Bausteine den Entwicklern des zu verifizierenden Bausteins
zur Verfügung zu stellen.
-
Erfindungsgemäß wurde
ein Verfahren entwickelt, welches sich wie folgt darstellen lässt.
- 1. Erstellen bzw. Laden der Darstellung/Abstraktion
jedes gewünschten Softwarebausteins. Angabe bzw. Laden
der zu verifizierenden Bedingungen.
- 2. Zusammenführen der durch den Anwender ausgewählten
Softwarebausteine oder wahlweise aller für die Verifikation
benötigten und vorhandenen Softwarebausteine zu so genannten
Systemabstraktionen. Diese enthält alle Informationen der
beteiligten Bausteine. Sollte die Abstraktion eines oder mehrerer
Bausteine nicht verfügbar sein, so werden die dadurch nicht
zusammenführbaren Teile automatisch durch Attrappen ersetzt, die
die Funktionalität der Systemabstraktion sicherstellen.
Der Anwender wird gegebenenfalls auf eine Ungenauigkeit in den Ergebnissen
hingewiesen.
- 3. Zusammenführen der zu überprüfenden
Bedingungen bzw. Bedingungen mit komplementärer Bedeutung
(Nachweis einer Verletzung einer Bedingung) mit den erzeugten Systemabstraktionen zur
so genannten kombinierten Systemabstraktionen. Vor dem Zusammenführen
werden aus den Systemabstraktionen genau die Interaktionen entfernt,
die keine Bedeutung innerhalb der jeweils zu prüfenden
Bedingung haben.
- 4. Die kombinierten Systemabstraktionen werden jeweils überprüft.
Existiert ein Pfad zu einer zu akzeptierenden Situation, so kann
eine Aussage darüber getroffen werden, ob sich die beteiligten Softwarebausteine
entsprechend der unter 3. angegebenen Fragestellung verhalten oder
nicht. Soweit ein Pfad existiert, kann dieser dem Anwender zur Verfügung
gestellt werden (Verifikationsergebnis). Dieser Pfad kann alle Informationen
enthalten, die bei verfügbarem Quellcode direkt die beteiligten
Teile des Quellcode referenzieren. Darüber hinaus ist es
möglich, noch weitere Informationen über das Verhalten
der Softwarebausteine zu treffen (u. a. sog. Metriken).
-
Die
verwendete Darstellung/Abstraktion vereinigt die Eigenschaften von
parallelem und sequenziellem Verhalten. Sie erfasst ebenfalls die
Eigenschaften von Petri-Netzen und Kellerautomaten vollständig
und kann aus beliebigem Programmcode erzeugt werden oder manuell
erstellt werden. Die Darstellung/Abstraktion enthält alle
Informationen, die für die Ausführung des/der
Bausteine bzw. Software relevant sind bzw. diese verfeinern, soweit
es dem Ziel möglichst genauer Ergebnisse dient.
-
Die
zu überprüfenden Bedingungen werden als Sprache
angegeben, die u. a. eine Nacheinanderausführung, als auch
die Wiederholung von Interaktionen erlaubt. Darüber hinaus
ist es möglich Situationen festzulegen, die beim Beginn
einer Ausführung gelten sollen sowie Situationen, die als
korrekt erkannt werden sollen. Die Bedingungen können für
jeden Softwarebaustein einzeln festgelegt werden oder für
eine Menge von Softwarebausteinen bzw. die komplette Software. Es
ist möglich mehrere Bedingungen für einen Softwarebaustein
festzulegen. Diese Bedingungen können durch einen Anwender
festgelegt werden oder aus gegebenen technischen Beschreibungen
erzeugt werden. Es ist darüber hinaus möglich,
sie direkt in den Quellcode von Bausteinen einzubetten.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- - Nierstrasz [0008]
- - Löwe et al. [0008]
- - Tenzer und Stevens [0008]
- - Zimmermann und Schaarschmidt [0008]
- - Hinz et al. [0010]
- - Schmidt et al. [0011]
- - Allen und Garlen [0012]
- - Foster et al. [0012]
- - Chaki et al. [0013]
- - Chamber [0014]
- - Ramalingam [0014]