Abschlussarbeit. im Bachelor-Studiengang

Transkript

1 Fachhochschule Bonn-Rhein-Sieg University of Applied Sciences Abschlussarbeit im Bachelor-Studiengang Weiterentwicklung eines PC-gestützten Werkzeugs zur Bestimmung von Qualitätskriterien sicherheitsrelevanter C++ Software von Daniel Paurat Erstbetreuer: Prof. Dr. rer. nat. Dietmar Reinert Zweitbetreuer: Prof. Dr.-Ing. Norbert Jung Eingereicht am 10. September 2007

2 EIDESSTATTLICHE ERKLÄRUNG Hiermit erkläre ich an Eides statt, dass die vorliegende Arbeit selbstständig von dem hier Unterschreibenden angefertigt wurde. Aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche gekennzeichnet. Die Arbeit wurde bisher nicht veröffentlicht und auch keiner Prüfungsbehörde vorgelegt. Sankt Augustin, den 7. September 2007 Daniel Paurat

3 Although this may seem a paradox, all exact science is dominated by the idea of approximation. Bertrand Russell

4 ZUSAMMENFASSUNG Im Rahmen dieser Arbeit wird das Werkzeug jmetrika, welches zur statischen Analyse von Quelltexten konzipiert ist, um die Sprache C++ erweitert. Die Programmreihe jmetrika befasst sich mit der Analyse von Quelltexten in Hinblick auf sicherheitsrelevante Aspekte. Hierbei wird das Einhalten bestimmter Anforderungen an die Software überprüft. Diese so genannten Qualitätskriterien sind Anforderungen an den Sourcecode der Software, welche das Entwickeln sicherer Software erst ermöglichen. Die Analyse des Sourecodes geschieht mittels Metriken. Auf Basis dieser Analyse wird der Grad der Einhaltung der Qualitätskriterien bestimmt. Speziell für die Analyse von objektorientierter Software müssen passende objektorientierte Metriken gefunden und eingebunden werden. Im Rahmen der objektorientierten Betrachtung werden auch die Qualitätskriterien neu überdacht und an diesen Kontext angepasst.

5 Seite v Inhaltsverzeichnis Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis vii viii ix 1 Motivation, Rahmen und Aufbau der Arbeit Motivation Rahmen und Ziele dieser Arbeit Abgrenzung der Arbeit Stand der Technik Aufbau der Arbeit Qualitätssicherung von Software Sichere Software Sicherheit durch Qualitätssicherung Metriken Linguistische Metriken Programmlänge Operatoren und Operanden Kommentare Strukturelle Metriken Zyklomatische Zahl Verschachtelung Objektorientierte Metriken Vererbung Verwendung Zusammenhalt Hybride Metriken Andere Metriken Qualitätskriterien Qualitätsmerkmale von C++ Programmen Programmierparadigmen für C und C Sicherheitsrelevanter Nutzen der Objektorientierung Objektorientierte Metriken für C Response for a class Weighted methods per class Coupling between object classes Number of children Vererbungstiefe Lack of cohesion in methods Wiederverwertungsgrad

6 3.3.8 Spezialisierungsgrad Anzahl der Methoden Anzahl der Konstruktoren Verwendung der Klasse Anzahl der Superklassen Qualitätskriterien im objektorientierten Kontext Testbarkeit Einfachheit Lesbarkeit Selbstbeschreibung Implementierung in jmetrika jmetrika s Programmstruktur Generelle Struktur Workflow Programminterner Ablauf Erweiterungen Einbindung von C++ in jmetrika Java Compiler Compiler Beschreibung der C++ Grammatik Ausgabe des Parsers Implementierung des Parsers Besonderheiten der Sprache C Namespaces Direktiven Ergebnisse Verifikation der Berechnungen Beschreibung der Testdaten Reale Testdaten Konstruierte Testdaten Überprüfung der Berechnungen Ergebnisse der Validierung Zusammenfassung und Ausblick 66 A Anhang - Aufwandsanalyse 67 B Anhang - Tabellen der implementierten Metriken 70 Literaturverzeichnis 72

7 Seite vii Abkürzungsverzeichnis OO CBO WMC RFC NoC LCOM SK LoC jmetrika jmetrikac++ jmetrikajava objektorientiert Coupling between object classes Weightend methods per class Response for a class Number of children Lack of cohesion in methods Anzahl der Superklassen Lines of code Die Programmreihe jmetrika im allgemeinen Die spezifische jmetrika Version für die C++ Quelltext Analyse Die spezifische jmetrika Version für die Java Quelltext Analyse

8 Seite viii Abbildungsverzeichnis 2.1 Switch-statement mit Kontrollflussgraph Umgeschriebene Switch-Anweisung mit Kontrollflussgraph Kontrollflussgraph des verschachtelten Codes Response for a class Weighted methods per class Coupling between object classes Number of children Vererbungstiefe Verwendung der Klasse Anzahl der Superklassen Darstellung der Qualitätskriterien im Bericht jmetrikas Workflow Projekt anlegen Projektdaten hinzufügen Quellcode der Analyse hinzufügen Einstellung der Metrikgrenzen Analyse der Quelltexte Stark vereinfachte Parserausgabe Struktur in Token nachgebildet Parsingtree Falsch analysiertes Flussdiagramm Richtig analysiertes Flussdiagramm Verschachtelungen unterschiedlicher Kontrollflussanweisungen Analyse von Testdaten für Funktionsmetriken Analyse von Testdaten für Klassenmetriken Analyse von Testdaten für Qualitätskriterien

9 Seite ix Tabellenverzeichnis 2.1 Fehlerprognose für unterschiedliche Programmtypen Anzahl der Programmzeilen in Projekten Qualitätskriterium Testbarkeit für Klassen Qualitätskriterium Testbarkeit für Methoden Qualitätskriterium Einfachheit für Methoden Qualitätskriterium Einfachheit für Klassen Qualitätskriterium Lesbarkeit für Methoden Qualitätskriterium Lesbarkeit für Klassen Qualitätskriterium Selbstbeschreibung für Klassen Qualitätskriterium Selbstbeschreibung für Methoden B.1 Implementierte Linguistische Metriken B.2 Implementierte Strukturelle Metriken B.3 Implementierte Objektorientierte Metriken B.4 Implementierte Globale Metriken

10 Seite 1 1 MOTIVATION, RAHMEN UND AUFBAU DER ARBEIT In diesem Kapitel wird ein Überblick über Motivation, Rahmen und Aufbau der Arbeit gegeben. 1.1 MOTIVATION Computergesteuerte Technik hat sich vom Kraftwerk bis zur Waschmaschine bewährt und erhält zunehmend Einzug in nahezu alle Bereiche des Lebens. In vielen dieser Bereiche muss aufgrung einer Verletzungsgefahr erhöhte Sicherheit gewährleistet sein. So ist beispielsweise im Kraftfahrzeug- und Verkehrswesen die Notwendigkeit erhöhter Betriebssicherheit gegeben. Nach Erhebungen der Weltgesundheitsorganisation (WHO) starben im Jahr 2003 weltweit etwa 1,2 Millionen Menschen an den Folgen von Verkehrsunfällen und die Zahl der Verletzten wird auf jährlich etwa 40 Millionen geschätzt. Immer mehr Bedeutung für die Sicherheit von technischen Systemen erlangt somit die integrierte Software. Um Software für sicherheitskritische Systeme zu entwickeln, muss ein hoher Aufwand für die Sicherstellung der Fehlerarmut dieser Software betrieben werden. Im Allgemeinen müssen strenge Maßstäbe an den Softwareentwicklungsprozess eingehalten werden. Gerade sicherheitsrelevante Software muss auch nach Jahren der Wartung und Überarbeitung noch den hohen Ansprüchen genügen, welche an sie gestellt werden. Um dies zu unterstützen, muss mehr als nur das Kriterium der korrekten Funktionsweise erfüllt sein. Auch Wartbarkeit und Testbarkeit müssen bei sicherer Software beachtet werden.

11 1 Motivation, Rahmen und Aufbau der Arbeit Seite 2 Speziell für Gutachter und Entwickler, ist es daher wichtig, dass der Sourcecode strukturiert und verständlich ist. Um ihnen dabei zu helfen, einen schnellen Überblick über potentielle Schwachstellen in Struktur und Konzept der Software zu finden, wurde jmetrika entwickelt. 1.2 RAHMEN UND ZIELE DIESER ARBEIT Das fehlerfreie Funktionieren wird mit steigender Komplexität von Algorithmen und Hardware immer schwieriger zu garantieren. Um Software in Bezug auf Sicherheit einschätzen zu können, muss man sich die Frage stellen, wie die Sicherheit von Software gewährleistet werden kann. Eine Voraussetzung für Sicherheit ist die Fehlerfreiheit des Systems. Bei Software kann diese allerdings nur in den wenigsten Fällen garantiert werden. Viele Fehler können aber bereits während der Konzeption und Entwicklung vermieden werden. Fehler treten gehäuft in komplexen Teilen eines Programms auf, daher ist es sinnvoll, diesen potentiellen Schwachstellen im Programmcode besondere Aufmerksamkeit zu widmen. Gerade der objektorientierte Ansatz mit der Idee ein Problem nachzumodellieren, bietet gute Möglichkeiten der Strukturierung. So lassen sich komplexe Probleme in einfachere Teilprobleme aufteilen. Das gesamte Programm gewinnt an Struktur, Verständlichkeit und somit an Sicherheit. Solche Anforderungen lassen sich mit Hilfe von Metriken ermitteln. Hierbei werden vermessbare Eigenschaften des Sourcecodes genutzt, um seine Qualität zu bestimmen. Beispielsweise erhöhen kurze, nicht zu stark verschachtelte Methoden mit aussagekräftigen Bezeichnern die Lesbarkeit des Sourcecodes. Lange, verschachtelte Programmteile mit wenig aussagekräftige Variablennamen wie x und y hingegen sind nur schwer verständlich. Ziel dieser Arbeit ist es ein Programm zu erstellen, welches sich in die jmetrika Reihe eingliedert. Dieses Tool soll in der Lage sein, C++ Quellcode einzulesen und mittels Metrikanalyse auf die Einhaltung von Qualitätskriterien hin zu untersuchen. Dazu ist es notwendig, die Qualitätskriterien 1 an die Objektorientiertheit 1 Testbarkeit, Lesbarkeit, Selbstbeschreibung und Einfachheit

12 1 Motivation, Rahmen und Aufbau der Arbeit Seite 3 der Sprache C++ anzupassen. Das Ergebnis soll als strukturierte HTML-Seite präsentiert werden. 1.3 ABGRENZUNG DER ARBEIT Der Fokus der Arbeit liegt auf der Erweiterung des Programms jmetrika um die Programmiersprache C++ im Hinblick auf objektorientierte Metriken und Qualitätskriterien. Für eine sinnvolle Analyse dieser objektorientierten Qualitätskriterien muss die zu analysierende Software anhand objektorientierter Konzepte und Standards entwickelt worden sein. Automatische Quellcodeanalyse ist immer an die Syntax einer Programmiersprache gebunden. Deswegen ist auch die Analyse der objektorientierten Eigenschaften auf die Sprache C++ ausgerichtet. Hierbei wird im Folgenden davon ausgegangen, dass der ANSI C++ Standard eingehalten wird. Die Erkenntnisse von Breuer 2 und Ley 3 über prozedurale Softwaremetriken werden im Rahmen dieser Arbeit verwendet und für die Analyse von Funktionen genutzt. Die in dieser Arbeit entwickelte Software dient nicht dem Zweck, die formale Korrektheit eines in C++ geschriebenen Programms zu überprüfen. Vielmehr kann sie einem Gutachter oder Entwickler Hinweise auf sicherheitsrelevante Schwachstellen liefern, die auf die Verletzung der Qualitätskriterien Testbarkeit, Lesbarkeit, Selbstbeschreibung und Einfachheit zurück zu führen sind. Darüber hinaus existieren weitere Software-Qualitätskriterien. Diese sind eher im Umfeld des Projektmanagements und der Effizienz als der Sicherheit anzusiedeln. Daher bilden sie keine Kernkomponente dieser Arbeit. 1.4 STAND DER TECHNIK Das Analysieren von Software mittels Quellcode-Metriken geht auf die siebziger Jahre zurück. Anhand von linguistischen und strukturellen Metriken wurden Prognosen über Fehlerwahrscheinlichkeit und Arbeitsaufwand bei der Erstellung 2 Siehe hierzu Breuer (2006) 3 Siehe hierzu Ley (2005)

13 1 Motivation, Rahmen und Aufbau der Arbeit Seite 4 eines Programms gemacht. Aufgrund der stellenweise sehr stark unterschiedlichen Syntax und Struktur von Programmiersprachen müssen sinnvolle Grenzwerte für Metriken an die jeweilige Sprache angepasst werden. Im Rahmen von Abschlussarbeiten sind in Kooperation zwischen dem Bundesgenossenschaftlichen Institut für Arbeitsschutz (BGIA) und der Fachhochschule Bonn Rhein Sieg (Fh BRS) bereits Werkzeuge zur statischen Sourcecodeanalyse entwickelt worden. In den Arbeiten von Krell 4, Staron 5, Maurer 6, Ley 7 und Breuer 8 wurden Metriken für die Sprachen Assembler, C, Java, und AWL untersucht und die Programmreihe jmetrika für die automatisierten Analyse von Sourcecode entwickelt. Die Programme sind frei erhältlich 9 und befassen sich speziell mit der Programmanalyse im sicherheitsrelevanten Kontext. Diese Arbeit erweitert die jmetrika Reihe um die Sprache C++ und legt dabei den Fokus auf die objektorientierten Eigenschaften der Sprache. 1.5 AUFBAU DER ARBEIT Kapitel 1 Motivation, Rahmen und Aufbau der Arbeit geht auf die Motivation ein, sich mit dem Thema zu beschäftigen und verschafft dem Leser einen Einstieg und Überblick. Es wird auch die Abgrenzung zu den vorangegangenen Arbeiten von Krell, Staron, Maurer, Ley und Breuer aufgezeigt. In Kapitel 2 Qualitätssicherung von Software wird erklärt, warum Sicherheit durch Qualitätssicherung erhöht wird, was Metriken und Qualitätskriterien im Bereich von Software sind und wie diese zusammenhängen. Es werden die unterschiedlichen Metriktypen und Qualitätskriterien vorgestellt. In Kapitel 3 Qualitätsmerkmale von C++ Programmen wird das Konzept 4 Krell (2003) 5 Staron (2004) 6 Maurer (2005) 7 Ley (2005) 8 Breuer (2006) 9 zu erhalten unter der URL:

14 1 Motivation, Rahmen und Aufbau der Arbeit Seite 5 der Objektorientiertheit und dessen Vorteile in Bezug auf Sicherheit erläutert. Geeignete objektorientierte Metriken zur Analyse von C++ Quellcode werden vorgestellt und ihr Einfluss auf die Qualitätskriterien sowie deren Anpassung werden erläutert. Kapitel 4 Implementierung in jmetrika behandelt Aufbau, Funktionsweise und Entwicklung der Software. Es wird darauf eingegangen, welche Teile des ursprünglichen Programms abgeändert oder erweitert wurden. Ein besonderes Augenmerk erhält der Parser in diesem Kapitel. Weitere Teile beschäftigen sich mit einigen für den Parser relevanten Eigenschaften der Sprache C++ wie dem Präprozessor und Namespaces. In Kapitel 5 Ergebnisse werden die unterschiedlichen angewandten Testverfahren zur Überprüfung der Funktionalität des Tools jmetrika vorgestellt. Verschiedene Testprojekte sowie deren Aufbau und Besonderheiten werden behandelt. Das Kapitel schließt mit einer Diskussion über die Grenzen des Tools und seine Einsatzgebiete. Am Ende stehen Fazit und Ausblick dieser Arbeit.

15 Seite 6 2 QUALITÄTSSICHERUNG VON SOFTWARE Qualität ist immer in Abhängigkeit von gestellten Anforderung zu sehen. Es existiert eine Vielzahl von Anforderungen, die an Software gestellt werden kann, wie etwa Funktionalität, Robustheit, Zuverlässigkeit, Effizienz, Benutzbarkeit oder Produktionspreis. In dieser Arbeit wird speziell die Anforderung der Sicherheit betrachtet. Prominente Unfälle, die auf Softwarefehler zurückzuführen sind, gibt es viele. Einige Beispiele aus dem Buch Software-Qualität von Peter Liggesmeyer belegen dies. 10 Ein Programmierfehler in der Software des Bestrahlungsgeräts THERAC 25 kostete zwischen 1985 und 1987 drei Patienten das Leben und verletzte drei weitere schwer, der Jungfernflug der Ariane 5 am 4. Juni 1996 endete in einer Selbstsprengung aufgrund eines Variablenüberlaufs und eine frühe Version des Verkehrsflugzeugs B737 schaltete unregelmäßig bei 60 Knoten die Triebwerke ab, da dieser Zustand in der Steuerungssoftware nicht berücksichtigt wurde. Diese und andere Unfälle zeigen deutlich die Problematik vernachlässigter Qualitätssicherung im Softwarebereich auf. Tabelle 2.1 ist zu entnehmen, wie viele Fehler durchschnittlich in verschiedenen Softwarearten vorhanden sind. Nach Giese (2006) Programmtyp Fehler pro 1000 Zeilen Normale Software 25 Wichtige Software 2-3 Medizinische Software 0.2 Space Shuttle Software < 0.1 Tabelle 2.1: Fehlerprognose für unterschiedliche Programmtypen 10 Vgl. Liggesmeyer (2002) S.27

16 2 Qualitätssicherung von Software Seite 7 Bedenkt man hierbei noch die Länge aktueller größerer Programme, so summiert sich die Fehleranzahl schnell auf mehrere tausend. Tabelle 2.2 bietet einen Überblick, über die Länge einiger bekannter Programme. Nach Giese (2006) Software Programmzeilen Handy-Software Modernes Auto Linux Kernel 2.6 Windows 2000 Windows XP 2 Millionen 6 Millionen 27 Millionen 40 Millionen Tabelle 2.2: Anzahl der Programmzeilen in Projekten Hätte eine Robotersteuerung mit nur Zeilen Code die Qualität normaler Software, so würde sie etwa 250 Fehler enthalten und jeder dieser Fehler könnte zu einem Unfall führen. In einem Umfeld, in dem Menschen zu Schaden kommen können muss das Restrisiko eines solchen Störfalls unter die gesellschaftlich, bzw. gesetzlich akzeptierte Grenze gedrückt werden. 2.1 SICHERE SOFTWARE Software in sicherheitskritischen Bereichen muss besonderen Anforderungen genügen. Im Folgenden bezieht sich der Begriff der Sicherheit darauf, dass hier durch das Versagen eines Produktes Menschen gefährdet werden. 11. Sicherheit im Sinne der informationstechnischen Sicherheit wird an dieser Stelle nicht betrachtet. Um die Sicherheit in einem Programm gewährleisten zu können müssen vor allem zwei Anforderungen erfüllt werden. Zum Einen muss das Programm seinen Zweck erfüllen, zum Anderen darf es keine Programmierfehler enthalten. Diesen Anforderungen kann man auf verschiedene Art entgegen kommen. So 11 Vgl. Thaller (2000) S.13

17 2 Qualitätssicherung von Software Seite 8 existieren beispielsweise formale Methoden zur Verifikation der Korrektheit des Programms. Diese sind teuer und zeitaufwändig und werden daher nur in begrenztem Rahmen eingesetzt. In den meisten Fällen reicht es aus, das Restrisiko des Versagens einer Komponente auf ein akzeptables Niveau zu senken. Hier bietet das manuelle Sichten des Sourcecodes im Rahmen einer Codereview 12 oder eines Walkthrough 13 eine gute Möglichkeit, die Fehleranfälligkeit eines Programms zu senken. Um diese gängigen Methoden zu erleichtern und die Gutachter zu unterstützen, werden Analysetools verwendet, welche den Sourcecode der Programme untersuchen und potenzielle Schwachstellen in Design und Code ausfindig machen. Das Verbessern der Sicherheit eines Programms mittels Qualitätssicherung 14 hat sich in der Praxis als gutes Mittel bewährt. 2.2 SICHERHEIT DURCH QUALITÄTSSICHERUNG Die grobe Fehlerabschätzung der exemplarischen Robotersteuerung aus Kapitel 2 zeigt bereits die Notwendigkeit der Qualitätssicherung im sicherheitsrelevanten Kontext. Durch die Anforderung der Sicherheit läßt sich die Software mindestens in den Bereich der wichtigen Software heben, wodurch die angenommene Fehlerwahrscheinlichkeit von 250 auf Fehler sinkt bei noch strikterer Formulierung der Qualitätsansprüche sogar auf zwei. Anders ausgedrückt würden auf jeden Unfall, welchen die sichere Robotersteuerung verursacht statistisch 125 Störfälle der normalen Robotersteuerung kommen. Doch die hohen Qualitätsansprüche an die Sicherheit einer Software müssen nicht nur gestellt sondern auch eingehalten werden. Wie bereits in Kapitel 2.1 erwähnt, sind zwei der wichtigsten Ansprüche an sicherheitsrelevante Software funktionale Korrektheit und Zuverlässigkeit. Diese Punkte sind schwer zu garantieren und werden daher im Rahmen spezieller Analyse- und Testverfahren geprüft. In seiner Arbeit erklärt Breuer, welche einfacher zu gewährleistenden Ansprüche 12 Eine Codereview ist eine manuelle Inspektion des Sourcecodes durch einen Gutachter. 13 Ein Walkthrough ist ein gemeinsames Durcharbeiten des Sourcecodes von Gutachter und Entwickler mit dem Ziel, Fehler zu finden und allgemeine Verbesserungsvorschläge zu machen. 14 Qualitätssicherung in Bezug auf die Senkung der Fehlerwahrscheinlichkeit

18 2 Qualitätssicherung von Software Seite 9 die Stabilität der Korrektheit und Zuverlässigkeit fördern 15. Testbarkeit, sie wird speziell für die Testverfahren gefordert. Lesbarkeit, Selbstbeschreibung und Einfachheit gehen auf die Ansprüche der Analyseverfahren ein. Hierbei wird der Sourcecode unter anderem von Hand, von unabhängigen Gutachtern überprüft. Genau an diesem Punkt setzt jmetrika an. Indem es Sourcecode mittels Metriken untersucht und speziell auf die oben genannten Qualitätskriterien eingeht, kann ein Gutachter schneller Einblick in Struktur und kritische Stellen 16 des analysierten Programms gewinnen. Das alleinige Erfüllen der Qualitätskriterien garantiert jedoch nicht die Sicherheit eines Programms. Es indiziert lediglich, dass das Programm mit Sorgfalt geplant und entwickelt wurde. In der Praxis haben sich solche Programme als fehlerarm und wartbar erwiesen. Auch lassen sich aufgrund der klaren Struktur konzeptionelle und syntaktische Fehler im Programm besser finden. Doch auch der umgekehrte Fall ist denkbar. Ein Programm, welches keines der geforderten Qualitätskriterien erfüllt, kann trotzdem vollkommen korrekt und sicher funktionieren. Die Wahrscheinlichkeit hierfür ist nur viel geringer. Das Analysieren mittels Qualitätskriterien ist nicht die einzige Möglichkeit, die sicherheitsbezogene Qualität einer Software zu verbessern. Andere Methoden, die auch in der Praxis Anwendung finden sind beispielsweise: 17 das gemeinsame durchsehen des Sourcecodes durch den Entwickler und einen Gutachter in einem Codereview oder Walkthrough. das Entwickeln anhand des Test driven development Konzepts. Hierbei wird die Funktionalität des entwickelten Programms, in Bezug auf die Testcases, nach jeder Codeänderung anhand der Tests bestätigt. 15 Vgl Breuer (2006) S.26 ff 16 So genannte Hotspots 17 Siehe hierzu auch Trauboth (1996) S. 153ff

19 2 Qualitätssicherung von Software Seite 10 das Entwickeln gemäß dem Konzept Design by contract. Hier werden Vorund Nachbedingungen der Module festgesetzt. Es entsteht eine Art Vertrag, welcher das Modul daran bindet, die geforderten Nachbedingungen bei erfüllter Vorbedingung zu garantieren. Auf diese Weise nähert man sich der Korrektheit des gesamten Projekts durch die Erfüllung der Korrektheit aller Einzelteile an. das Verwenden von Design patterns. Für viele typische Problemstellungen in der Informatik existieren best practices, welche bei der Weiterentwicklung, Wartung, Lesbarkeit und Testbarkeit des Codes von Nutzen sind. das Entwickeln anhand des V-Modells. Hierbei werden top-down die Anforderungen und Systementwürfe der Komponenten spezifiziert. Bei der letzten Spezifikation 18 angekommen wird bottom-up integriert. In diesem Rahmen sei auf die Sicherheitsnorm DIN verwiesen, welche unter dem Namen IEC auch eine internationale Norm darstellt 19. Diese Norm spaltet sich in sieben Teile auf, von denen die dritte Anforderungen an sicherheitsrelevante Software, deren Entwurf, Entwicklung und Implementation beinhaltet. 20 Auch die Einstufung in die verschiedenen Safety integrity level (SIL) wird hier behandelt. Diese Sicherheitsnorm kann für alle sicherheitsbezogenen elektronischen, elektrischen und programmierbaren Systeme herangezogen werden. Eine weitere in diesem Kontext erwähnenswerte Norm ist DIN 66272, welche sich mit dem einheitlichen Bewerten von Software befasst. 21 In dieser Norm werden speziell die Qualitätsmerkmale Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit definiert und ein Leitfaden zu ihrer Verwendung gegeben. Auch verschiedene Sichtweisen auf die unterschiedlichen Qualitätsmerkmale werden behandelt. 18 In diesem Fall der Softwareentwurf 19 Siehe hierzu auch DIN (1998) 20 Der dritte Teil wird auch mit DIN bezeichnet. 21 Siehe hierzu auch DIN (1994)

20 2 Qualitätssicherung von Software Seite 11 Diese Arbeit befasst sich mit der Entwicklung einer Methode, welche die sicherheitsrelevanten Qualitäten der Lesbarkeit, Testbarkeit sowie der Selbstbeschreibung und Einfachheit mittels Metriken ermittelt. 2.3 METRIKEN Metriken sind Verfahren zur Bestimmung quantifizierbarer Kennzahlen eines Systems. Im Falle von Softwaremetriken werden bestimmte Eigenschaften des Sourcecodes gezählt, gemessen, gewichtet und in Relation zueinander gesetzt. Auf diese Weise wird ermittelt, ob der Sourcecode einer Software den erwarteten Anforderungen entspricht. Nicht alle Anforderungen können mittels Metriken überprüft werden. Eine Anforderung, die sicherlich immer an Software gestellt wird, ist die der korrekten Funktionsweise. Gerade diese kann nicht direkt mittels Metriken überprüft werden, jedoch steht sinnvoll strukturierter Sourcecode in starkem Zusammenhang mit der Vermeidung von Fehlern. Metriken helfen dabei, Fehlerprognosen zu erstellen und so potenzielle Schwachstellen in Konzeption und Programmierung aufzudecken. Softwaremetriken werden in dieser Arbeit im Wesentlichen in die folgenden Typen gegliedert: linguistische strukturelle objektorientierte andere Im Rahmen einer Softwarebewertung sollten Metriken als Indizien aufgefasst werden. Ihre Grenzen sind nicht starr gesetzt und müssen in Kombination mit anderen Metriken verstanden werden. Die Aussage, Ein Programm hat 1000 Zeilen ist allein nicht aussagekräftig. Ein Programm hat 1000 Zeilen, enthält keine Kommentare und der Code ist bis zu zehn Ebenen tief verschachtelt hingegen lässt die Qualität des Sourcecodes erahnen. Sicherlich kann ein Gutachter positiv überrascht werden vom Code dieses Programms, in den meisten Fällen wird er es jedoch nicht sein. Metriken können nur wahrscheinliche Schwachpunkte aufzeigen. Ein Gutachter hat jedoch die Möglichkeit mittels Metriken zu überprüfen, ob

21 2 Qualitätssicherung von Software Seite 12 geforderte Standards eingehalten wurden und erhält gleichzeitig einen Einblick in die Codestruktur, samt potenzieller Schwachstellen LINGUISTISCHE METRIKEN Die linguistischen Metriken beziehen sich speziell auf die syntaktischen Eigenschaften von Sourcecode. Hierbei wird nicht auf dessen Bedeutung sondern ausschließlich auf direkt abzählbare Eigenschaften eingegangen. Wichtige Merkmale sind Anzahl der Zeilen, Kommentarzeilen, Statements, Operatoren und Operanden. Besonders Maurice Howard Halstead hat sich intensiv mit diesem Themengebiet auseinander gesetzt und gilt als einer der Väter der linguistischen Metriken. Im Folgenden wird erklärt, aus welchen dieser abzählbaren Eigenschaften sich welche Metriken ableiten lassen PROGRAMMLÄNGE Die einfachste Art, die Komplexität eines Programms abzuschätzen, ist diese über die Anzahl der Codezeilen zu erfassen. Hierbei werden Kommentare und Leerzeilen nicht mitgezählt. Auf diese Weise können Fehleranzahl und Aufwand eines Programms approximiert werden. Die Programmlänge als Metrik zu benutzen, geht auf Sprachen wie FORTRAN und Assembler zurück, in denen das Zählen der Zeilen größeres Gewicht als heute hatte. Zur Verdeutlichung dienen die beiden folgenden Codefragmente. i n t array [ 1 0 ] ; for ( i n t i =0; i <10; ++i ) array [ i ] = i ; Der selbe Code anders aufgeschrieben ergibt einen vielfachen Wert der Metrik. i n t array [ 1 0 ] ; i n t i ; for ( i =0; i <10; ++i ) { array [ i ] = i ; } Bei einem gesamten Programm jedoch relativieren sich die Unterschiede, die durch den Programmierstil einfließen. Daher bietet diese Metrik trotz der Abhängigkeit von Programmierstil und Sprache eine treffsichere Vorhersage, über die

22 2 Qualitätssicherung von Software Seite 13 Anzahl der Fehler im Programm. Allgemeine Schätzungen schwanken zwischen unter 1% und 7% Fehlerwahrscheinlichkeit pro Zeile in Abhängigkeit von Programmiersprache, Stil und Programmgröße. Eine Möglichkeit die Schwankungen zu minimieren, besteht darin, die Anzahl der Operationsanweisung zu zählen. Auf diese Weise versucht man, den Sourcecode auf die Anzahl der relevanten Anweisungen zu reduzieren OPERATOREN UND OPERANDEN Der Sourcecode eines Programms läßt sich unterteilen in Operatoren und Operanden. 22 Die Idee dahinter ist, dass Operatoren auf die Operanden wirken. Operanden sind im Wesentlichen Variablen und Konstanten. Zu den Operatoren zählen alle Operationen, die Operanden verändern oder mit ihnen arbeiten. Beispiele hierfür sind: do, try, i f, +, <=, oder &. In jmetrika sind folgende auf Operatoren und Operanden basierende Metriken implementiert: die absolute Anzahl von Operatoren (N 1 ) und Operanden (N 2 ) die Anzahl der unterschiedlichen, im Programmcode verwendeten Operatoren (n 1 ) und Operanden (n 2 ) die Implementierungslänge N 1 + N 2 die Vokabulargröße n 1 + n 2 die Frequenz des Vokabulars N 1 + N 2 n 1 + n 2 das Halstead-Volumen (N 1 + N 2 ) log 2 (n 1 + n 2 ) die Halstead-Länge n 1 log 2 (n 1 ) n 2 log 2 (n 2 ) Das Halstead-Volumen bildet die Basis der Fehlerprognose aufgrund von Operatoren und Operanden. Es gilt: 22 Diese Unterteilung wurde zuerst von Halstead vorgenommen.

23 2 Qualitätssicherung von Software Seite 14 Anzahl der Fehler (N 1 + N 2 ) log 2 (n 1 + n 2 ) 3000 = log 2(Vokabulargröße Implementierungslänge ) 3000 Diese Gleichung geht direkt auf Halstead zurück und ist eine der ersten angewandten Metriken zur Fehlerprognose KOMMENTARE Eine wichtige Rolle bei der Bestimmung der Qualität von Software nehmen auch die Kommentare ein, da hierdurch die Verständlichkeit eines Programms enorm gesteigert werden kann. Die in jmetrika für C++ bewerteten Kommentarmetriken basieren auf den Beobachtungen von Vitali Maurer. In seiner Arbeit setzte er sich unter anderem mit kommentarbezogenen Metriken auseinander 23. Im Einzelnen sind dies: Das Verhältnis von Kommentar- zu Programmzeilen innerhalb einer Methode. Es indiziert, wie stark der Programmierer darauf bedacht war, seinen Sourcecode verständlich darzustellen. Das hier gemessene Verhältnis bezieht sich speziell auf Kommentare innerhalb von Methoden. Der Grundgedanke hinter dieser Metrik ist, dass Inlinekommentare den Algorithmus und Implementationsspezifisches beschreiben. Beispiel:... / / Das Schachfeld i s t 8x8 Felder gross i n t S p i e l f e l d [ 8 ] [ 8 ] ; / / S p i e l f e l d mit Null i n i t i a l i s i e r e n for ( i n t x =0; x <8; ++x ) { for ( i n t y=0; y<8; ++y ) { array [ x ] [ y ] = 0 ; } }... Die Anzahl der Kommentarzeilen, die vor einer Komponente stehen. Module, Klassen und Funktionen sollten eine vorangestellte Beschreibung besitzen. Hier wird die Komponente kurz beschrieben, was sie bewirkt und 23 siehe hierzu Maurer (2005) S. 67ff

24 2 Qualitätssicherung von Software Seite 15 welche Ein- und Ausgabeparameter sie besitzt. Beispiel: / i n i t S p i e l f e l d ( ) e r s t e l l t das S c h a c h s p i e l f e l d und s e t z t die Figuren auf i h r e S t a r t p o s i t i o n e n. Die Figuren werden durch Integerwerte r e p r a e s e n t i e r Name des S p i e l e r Das i n i t i a l i s i e r t e S p i e l f e l d wird a l s Doppelarray zurueck gegeben / Die durchschnittliche Anzahl der Zeichen pro Kommentarzeile. Die Länge der Kommentarzeilen zeigt, wie intensiv die Kommentare ausfallen. Diese Metrik läßt darauf schließen, ob der Programmierer seinen Code erklärt oder ob er ihn nur mit Stichworten versieht. Ein besonderes Problem tritt bei dem Verhältnis von Kommentar- zu Programmzeilen auf. Oftmals befindet sich in Methoden auskommentierter Sourcecode. Dieser dient nicht dem Verständnis sondern stammt noch aus Zeiten der Entwicklung. Solche Bereiche sind schwierig mit automatischen Mitteln zu erkennen und können über viele Zeilen hinweg reichen. Die Robustheit der Metrik wird hiervon stark beeinträchtigt STRUKTURELLE METRIKEN Anders als bei linguistischen wird bei den strukturellen Metriken auf die Bedeutung des Sourcecodes geachtet. Hierbei wird eine Analyse des Kontrollflussgraphen erstellt, bei der insbesondere auf die Anzahl der Verzweigungen geachtet wird. Das Ziel struktureller Metriken ist es, die Komplexität eines Moduls zu messen. Die wichtigsten dieser Metriken gehen auf Thomas Bayard McCabe zurück, welcher speziell die zyklomatische Zahl als Maß für Komplexität einführte ZYKLOMATISCHE ZAHL Die zyklomatischen Zahl ist ein Maß für die Komplexität einer Komponente. Mit steigender Komplexität wird die Komponente für den Menschen immer schwerer zu begreifen und zu beherrschen. Sie ist definiert als Anzahl der binären Verzweigungen innerhalb des Kontrollflussgraphen plus eins. Binäre Verzweigungen sind Stellen im Programm, an denen der Kontrollflussgraph

25 2 Qualitätssicherung von Software Seite 16 exakt zwei mögliche Wege hat. Um die zyklomatische Zahl zu berechnen, müssen alle Verzweigungen höherer Ordnung in solche binären Verzweigungen überführt werden. Zur Verdeutlichung dient eine switch Anweisung: switch ( auswahl ) { case a : startsometask ( ) ; break ; case b : startanothertask ( ) ; break ; default : savetheday ( ) ; break ; } Abbildung 2.1: Switch-statement mit Kontrollflussgraph In diesem Beispiel hat das Programm die Möglichkeit, einem von drei Pfaden zu folgen. Da der Kontrollfluss hier mehr als zwei Wege zur Wahl hat, muss dieser Programmteil in Code überführt werden, welcher äquivalent ist aber nur binäre Verzweigungen enthält. Das folgende Beispiel stellt eine solche äquivalente Form des ersten Beispiels dar. i f ( auswahl == a ) { startsometask ( ) ; } e lse i f ( auswahl == b ) { startanothertask ( ) ; } e lse { savetheday ( ) ; } Abbildung 2.2: Umgeschriebene Switch-Anweisung mit Kontrollflussgraph

26 2 Qualitätssicherung von Software Seite 17 In dieser Schreibweise enthält der neue Code genau zwei binäre Verzweigungen (zwei if-statements). Die zyklomatische Zahl dieses Fragments entspricht drei zwei binäre Verzweigungen plus eins. Die zyklomatische Zahl entspricht der Anzahl der möglichen Pfade, die durch das Programm führen. Zur Berechnung der zyklomatischen Zahl ist es also nicht zwingend nötig Substitutionen im Sourcecode vorzunehmen. Es ist möglich diese direkt aus dem Kontrollflussgraphen abzuleiten. Die größten Kritikpunkte an McCabes Metrik sind, dass die gesamte Komplexität auf nur eine Zahl reduziert wird und dass sämtliche Verzweigungen die gleiche Gewichtung erhalten. jmetrika umgeht diese Kritikpunkte, durch die Verwendung einer Vielzahl von unterschiedlichen Metriken zur Bestimmung der Softwarequalität und das Einführen einer erweiterten zyklomatischen Zahl (VG_NEU). Diese versieht die unterschiedlichen Verzweigungen mit verschiedenen Gewichtungen. So wird die Komplexität eines Switch-Statements wie eine einfache Verzweigung gewertet VERSCHACHTELUNG Eine weitere Methode zur Abschätzung der Komplexität bietet das Analysieren der Verschachtelungen. Von Interesse sind hierbei besonders zwei Metriken. Die Anzahl der Verschachtelungen und ihre maximale Tiefe. Hinter dem Begriff Verschachtelung steht im Wesentlichen ein Sprungbefehl. Daher werden nicht nur Verzweigungen sondern auch Schleifen zu den Verschachtelungen gezählt. Zusammen mit der zyklomatischen Zahl bilden diese beiden Metriken eine gute Grundlage, die Komplexität einer Funktion abschätzen zu können. Das folgende Beispiel verdeutlicht dies: / / das Array s e i b e r e i t s mit Werten g e f u e l l t. 10 neue / / Wuerfelergebnisse koennen aber im Array abgelegt werden i f ( r e f i l l == y ) { for ( i n t i =0; i <10; ++i ) { array [ i ] = random ( 1, 6 ) ; } } for ( i n t j =0; j <10; ++ j ) { cout << " Ergebnis Nr. " << j << " : " << array [ j ] << endl ; }

27 2 Qualitätssicherung von Software Seite 18 Abbildung 2.3: Kontrollflussgraph des verschachtelten Codes Die Anzahl der Verzweigungen insgesamt beträgt hier 3; maximale Verschachtelungstiefe und zyklomatische Zahl liegen bei 2. Sowohl die Metriken als auch der Kontrollflussgraph deuten hier zu Recht auf eine niedrige Komplexität des Codefragments hin OBJEKTORIENTIERTE METRIKEN Eine weitere Klasse von jmetrika behandelter Metriken ist die der objektorientierten. Diese beziehen sich ausschließlich auf objektorientierte Sprachen, welche dem Programmierer die Möglichkeit bieten den Kontext, in dem die Software eingesetzt wird, im Programmcode nachzumodellieren. Diese Art der Strukturierung lehnt sich stark an die menschliche Denkweise an und bietet somit dem Programmierer bereits während der Konzeption eine Möglichkeit logische Fehler zu erkennen. Die Programme werden anschaulicher und sind somit leichter zu verstehen. Die meisten Metriken der klassischen Software-Entwicklung lassen sich problemlos auf objektorientierte Sprachen übertragen. Es stellt sich jedoch die Frage, wie mit Vererbung umzugehen ist. Die Antwort hierauf lieferten Shyam Chidamber und Chris Kemerer 1994 in ihrer Veröffentlichung A Metrics Suite for Object Oriented Design 24. Die hier vorgestellten von jmetrika verwandten Metriken werden im Kapitel 3 noch eingehender besprochen. Die folgenden drei Merkmale bilden die Grundlage, anhand derer sich die objektorientierten Metriken ableiten lassen. 24 Siehe hierzu Chidamber S.R. (1994)

28 2 Qualitätssicherung von Software Seite VERERBUNG Eine Eigenschaft des objektorientierten Programmierkonzepts ist die Vererbung. Hierbei können bestimmte Programmstrukturen aus bereits bestehenden abgeleitet werden. Diese Klassen erben so die Eigenschaften und Manipulationsmethoden der zu Grunde liegenden Klassen und können diese noch erweitern. Im Rahmen der Übersicht ist es interessant solche Vererbungshierarchien zu untersuchen, da sie dem Sourcecode Struktur verleihen und ihn insgesamt verständlicher machen. Doch auch der gegenteilige Effekt kann eintreten und der Sourcecode wirkt verworren und überladen. Sinnvolle Metriken im Zusammenhang mit Vererbung sind: maximale Tiefe des Vererbungsbaums Sie entspricht der längsten Vererbungskette im gesamten Programm durchschnittliche Vererbungstiefe im gesamten Programmcode Anzahl der Klassen, die von der untersuchten Klasse erben Anzahl der Klassen, von denen die untersuchte Klasse erbt Vererbungstiefe der analysierten Klasse VERWENDUNG Bei einem objektorientierten Programmdesign spielt die Strukturierung und Unterteilung des Codes eine wichtige Rolle. Zum Einen sollte die Struktur des Programms der Struktur des zu lösenden Problems folgen. Zum Anderen sollten die Klassen so geschickt gestaltet sein, dass sie mehrfach verwendet werden können. Wiederverwendbarkeit und Spezialisierungsgrad einer Klasse sind demnach interessante Metriken in diesem Kontext. Sie sind wie folgt definiert: Wiederverwendbarkeit = Anzahl der Klassen, von denen abgeleitet wurde Anzahl aller Klassen Spezialisierungsgrad = Anzahl der hiervon abgeleiteten Klassen Anzahl aller Klassen

29 2 Qualitätssicherung von Software Seite 20 Auch die Metrik Coupling between object classes sagt etwas über die Verwendung der Klasse aus. Sie zählt, wie viele Klassen auf Instanzen der analysierten Klasse zugreifen; also mit wie vielen anderen Klassen die untersuchte in direktem Kontakt steht. Diese Metriken helfen, die Konsistenz des Programmdesigns abzuschätzen ZUSAMMENHALT Da die einzelnen Klassen die logischen Einheiten eines zu lösenden Problems repräsentieren, muss auch die Programmstruktur, welche das Problem beschreibt, zusammenhängend sein. Ist der logische Zusammenhalt der Klassen untereinander oder in den Klassen selbst nicht gegeben, deutet dies auf ein schlechtes Programmdesign hin. Die Metrik Lack of cohesion in methods sagt etwas über den inneren Zusammenhalt einer Klasse aus. Da eine Klasse einen logisch isolierten Teil des Problems beschreibt, werden für die Verarbeitung dieses Teilproblems nur begrenzt viele, unterschiedliche Datentypen benötigt. Bei einer in sich zusammenhängenden Klasse weisen die Methoden daher Überschneidungen in den verwendeten und bearbeiteten Datentypen auf. Die Definition dieser Metrik ist der Anzahl der Paare von Methoden einer Klasse ohne gemeinsame Instanzvariablen, minus die Anzahl der Paare mit gemeinsamen Instanzvariablen. Negative Werte werden hierbei als Null interpretiert. Auf diese Weise wird untersucht, wie zusammenhängend der Kontext der untersuchten Klasse ist. Zu hohe Komplexität innerhalb einer Klasse schränkt den Zusammenhalt ihres Kontexts ein. Die Metrik Weighted methods per class (WMPC) zählt die zyklomatischen Zahlen der einzelnen Methoden einer Klasse zusammen. Die Anzahl aller aufrufbaren Methoden einer Klasse werden durch die Metrik Response for a class (RFC) bestimmt. Hierbei werden nicht nur die klasseneigenen Methoden gezählt sondern auch mögliche Methodenaufrufe über Instanzen anderer Klassen innerhalb der analysierten Klasse.

30 2 Qualitätssicherung von Software Seite HYBRIDE METRIKEN Mischungen der Metriktypen sind möglich und finden in der Praxis Anwendung. Ein gutes Beispiel hybrider Metriken findet sich in Michael Krells Abschlussarbeit. Hier wird die Metrik VG_STMTS = VG N_STMTS definiert. 25 Diese Metrik ist eine Kombination aus McCabes zyklomatischer Zahl und Halsteads Anzahl der Statements. Die Metrik setzt die Länge eines Moduls in Abhängigkeit zu seiner Komplexität. Gerade im sicherheitsrelevanten Bereich ist Hardware, die sich selbst auf Funktionalität überprüft üblich. Die Testmodule, die diese Funktionstests durchführen, bestehen meist zu großen Teilen aus linearem Code von aufeinander folgenden Testroutinen und Aufrufen. Solche Module können von automatischen Analysetools schnell als zu lang bewertet werden, obwohl sie weder komplex, noch unsinnig lang sind. Die Metrik VG_STMTS geht auf diese Situation ein. Ihre Aussage ist, dass mit abnehmender Komplexität die Länge des Codes zunehmen darf ANDERE METRIKEN Linguistische, strukturelle und objektorientierte Metriken sind nicht die einzigen sinnvollen Softwaremetriken, die in der Praxis Anwendung finden. Es existiert eine große Anzahl weiterer Metriken, die jedoch im Rahmen des Analysetools jmetrika keine Anwendung finden. Um eine Vorstellung der Vielfalt anderer Metriken zu schaffen, hier einige Beispiele: Stilmetriken bewerten das Einhalten eines vorgegebenen Programmierstils. Solche Codeconventions befassen sich beispielsweise mit Namensgebung, Einrückung und Klammersetzung. Ressourcenmetriken ermitteln den Verbrauch bestimmter Ressourcen wie etwa Speicher oder Prozessoren. Laufzeitmetriken bewerten die geschätzte Laufzeit einzelner Codefragmente. Hierbei kann sowohl die zeitliche Entwicklung eines Algorithmus 26 als 25 Siehe hierzu auch Krell (2003) S.67 ff 26 Gemeint ist hier das zeitliche Verhalten im Sinne der Groß-O-Notation

31 2 Qualitätssicherung von Software Seite 22 auch die real verbrauchte Zeit bemessen werden. Datenflussmetriken vermessen die ausgetauschten Datenstrukturen zwischen Funktionen. Diese werden besonders dann interessant, wenn Daten mit hoher Nebenläufigkeit 27 parallel prozessiert werden. Letztendlich läßt sich alles, was quantitativ erfassbar und somit vergleichbar ist, als Metrik auffassen. Die in jmetrika verwandten Metriken wurden im Hinblick auf die Bewertung sicherheitsrelevanter Qualitätskriterien ausgewählt. Das Konzept dieser Qualitätskriterien wird im folgenden Abschnitt behandelt. 2.4 QUALITÄTSKRITERIEN Qualitätskriterien sind im Wesentlichen konkrete Ansprüche, welche an ein Programm gestellt werden wie etwa Wartbarkeit oder Echtzeitanforderungen. Die in jmetrika verwendeten Qualitätskriterien sind darauf ausgerichtet, dass die Software möglichst selbsterklärend und nachvollziehbar ist. In diesem Rahmen wird auf Testbarkeit, Einfachheit, Lesbarkeit und die Selbstbeschreibung des Sourcecodes geachtet. Wird eine Software im Hinblick auf diese Qualitätsmerkmale entwickelt, so gestaltet sich der Quellcode als verständlicher und der Entwickler behält einen besseren Überblick über das Programm. Auf diese Weise wird die Fehlerwahrscheinlichkeit deutlich gesenkt. Während der Entwicklung einer Erweiterung oder einem Codereview trägt die Verständlichkeit dazu bei, Fehler aufzudecken oder diese erst gar nicht zu begehen. Ob und wie stark auf diese Qualitätskriterien bei der Erstellung eines Programms geachtet wurde, ist anhand von Metriken festzustellen. In seiner Arbeit führt Thomas Breuer eine neue Bewertungsart der Qualitätskriterien anhand von Metriken ein 28. Der Grundgedanke hinter diesem Bewertungssystem ist es, das Einhalten der Grenzen von Metrikgruppen zu betrachten. Metrikgruppen sind Sammlungen von Metriken, welche gewisse Gemeinsamkeiten besitzen. 27 Nebenläufigkeit bezeichnet hier die kausale Unabhängigkeit von Prozessen. 28 Siehe hierzu auch Breuer (2006) S.45 ff

32 2 Qualitätssicherung von Software Seite 23 Die einzelnen Metriken stehen mit einigen Qualitätskriterien stärker in Verbindung als mit anderen. So stehen beispielsweise die Dokumentatonsmetriken 29 dem Kriterium der Lesbarkeit näher als dem der Testbarkeit. Um die Güte eines Qualitätskriteriums zu ermitteln, wird jedem der Kriterien eine Gruppe von Metriken zugeordnet, welche möglichst direkten Einfluss auf das Kriterium haben. Werden von allen Metriken, die einem Kriterium zugeordnet sind, die Grenzen eingehalten, so gilt das Kriterium als akzeptiert. 30 Ein großer Vorteil dieses Bewertungssystem ist es, dass bei der Bewertung der Qualitätskriterien differenzierte Aussagen getroffen und Verbesserungsvorschläge gemacht werden. Wird ein Qualitätskriterium als nicht erfüllt eingestuft, so wird direkt über die verursachende Metrik auf die Ursache verweisen. 29 Beispielsweise Anzahl der Kommentare oder Kommentarlänge 30 Die konkrete Gruppierung wird in Kapitel 3.4 eingehend erläutert.

33 Seite 24 3 QUALITÄTSMERKMALE VON C++ PROGRAMMEN In diesem Kapitel wird erklärt, welche unterschiedlichen Programmierparadigmen hinter den Sprachen C und C++ stehen. Es wird erörtert, welchen Nutzen objektorientierte Metriken im sicherheitsrelevanten Umfeld haben, die implementierten Metriken werden vorgestellt und ihr Einfluss auf das Gesamtdesign des Programms wird erläutert. Die Wahl der Metriken wird begründet und die Qualitätskriterien werden im Kontext der objektorientierten Metriken neu bestimmt. Aufgrund der vielen Ausnahmeregeln und Dialekte, wird der ANSI C++ Standard für die saubere Verarbeitung des Sourcecodes hier vorausgesetzt. Ebenso sollten Makros vor der Analyse mittels des Präprozessors ersetzt worden sein. 3.1 PROGRAMMIERPARADIGMEN FÜR C UND C++ Die Entwicklung der Sprache C++ hatte unter anderem das Ziel den Programmierern neue Datentypen und Programmierkonzepte zu bieten ohne das diese eine neue Sprache lernen mussten. Aus diesem Grund wurde C++ auf der Basis der Sprache C entworfen, was bis Heute zur Folge hat, dass jeder gültige C-Code auch gleichzeitig gültiger C++ Code ist. 31 In den meisten Betrachtungen werden die beiden Sprachen daher in einem Atemzug genannt, mit der Ergänzung, dass C++ objektorientiert ist. Im Rahmen dieser Arbeit wird C++ jedoch als eigenständige Sprache betrachtet, 31 Dies gilt zumindest für die Beziehung zwischen ANSI C99 und ANSI C++, wird aber meistens als allgemein gültig dargestellt.

34 3 Qualitätsmerkmale von C++ Programmen Seite 25 da die Analyse des objektorientierten Kontexts einen wichtigen Part in der Bestimmung der Qualitaetskriterien einnimmt. Ein wesentlicher Unterschied zwischen den beiden Sprachen ist, dass sie unterschiedliche Programmierparadigmen verfolgen. Programmierparadigmen sind Konzepte zur Gestaltung des Codes, welche es vereinfachen oder nahelegen Anforderungen an den Sourcecode, wie die Lesbarkeit, Redundanzfreiheit und Modularität, zu erwirken. Es existieren viele verschiedene Programmierparadigmen mit stellenweise fließenden Übergängen. Einige Beispiele sind imperatives, funktionales, datenstromorientiertes, prozedurales, objektorientiertes und logisches 32 Programmieren. Für die Betrachtungen in diesem Kapitel sind speziell die Paradigmen der prozeduralen und der objektorientierten Programmierung von Interesse. Prozedurales Programmieren ist stark vorgehensorientiert und unterteilt ein Programm in Teilaufgaben, welche als Prozeduren oder Funktionen bezeichnet werden. Eine Anweisung stellt hierbei die kleinste Unterteilung dar. Ein Programm läuft imperativ von Anweisung zu Anweisung, bis es zu einen Funktionsaufruf gelangt. Dieser stellt eine besondere Anweisung dar. Das Programm springt in den Programmkontext der Prozedur, durchläuft deren Anweisungen und springt nach ihrem Ablauf wieder in den alten Kontext zurück. 33 Durch die Kapselung in Prozeduren, oder Funktionen wird der Quellcode wiederverwendbar und strukturiert. 34 Objektorientiertes Programmieren basiert auf der Idee Daten anhand ihrer Eigenschaften und möglichen Operationen zu unterteilen. Hierbei werden die Daten und Funktionen, welche die Daten bearbeiten, in Objekten zusammenzufassen und so nach außen abgekapselt. Die Daten als Objekte mit Eigenschaften und Methoden zu sehen nähert die Struktur des Sourcecodes der menschlichen Sicht auf das zu bearbeitende Problem an und gestaltet den Sourcecode somit wiederverwendbar und strukturiert. 32 Natürlich unterliegen alle Programmiersprachen der Logik. Das Paradigma der logischen Programmierung bezieht sich vielmehr auf explizite Logiksprachen, wie etwa PROLOG. 33 Für das Verwalten der Rücksprungadressen, auch bei verschachtelten Aufrufen, ist der Stack zuständig. Hier werden auch die Parameter der Funktion bei ihrem Aufruf abgelegt. 34 Siehe hierzu auch Prinz P. (2005)