ModulaTor logo, 7.8KB

The ModulaTor

Oberon-2 and Modula-2 Technical Publication

Ubaye's First Independent Modula-2 & Oberon-2 Journal! Nr. VV, Oct-1993


Konstruktive Maßnahmen zur Qualitätssicherung in der Softwareentwicklung

Günter Dotzel, A. Schuhmacher, 20. Oktober 1993

Motivation

Immer häufiger werden Stimmen laut, die nach mehr Qualität in der Softwareentwicklung rufen. Die Qualität des Ergebnisses hängt stark von den Eigenschaften der verwendeten Werkzeuge ab. Das Entwicklungsziel besteht aus einem möglichst flexiblen, sprich erweiterbaren Entwurf und einer effizienten, sicheren und portablen Implementierung. Wie erreicht man das Ziel? Welche Werkzeuge gibt es und wie sicher sind sie?

Das wichtigste Werkzeug der Softwareentwicklung ist die Programmiersprache. Eine Hochsprache soll es sein, auf möglichst vielen Plattformen verfügbar und portabel. Portabilität erreicht man durch Verwendung von Standards. Die Qualitätsunterschiede zwischen imperativen Programmiersprachen wie Fortran, C /15/ und Nachfolgersprachen von Pascal, wie Modula-2 /12/, /13/ und Oberon-2 /17/ sind beträchtlich.

Hochsprachen zeichnen sich durch einen Kompromiss zwischen Einfachheit und Eigenschaften aus. Nur mit einfachen Werkzeugen kann man komplexe Systeme beherrschen, sonst wird das Werkzeug zum Teil des Problems. Ob nun gewisse Eigenschaften, wie zum Beispiel komplexe Arithmetik nützlich sind oder nicht, ist nicht so wichtig. Die Hochsprache soll zwar anwendungsorientiert sein, jedoch nicht zu viele Konzepte oder gar versteckte Mechanismen enthalten.

Es hat fast 20 Jahre gedauert, um von der Forderung strukturiert mit strenger Typprüfung über modular und objektbasiert zu objekt-orientiert und erweiterbar zu kommen, aber nur wenige Sprachen sind dabei einfacher geworden. Da sich Komplexität gerne mit Ineffizienz paart, führt der Einsatz mächtiger Werkzeuge früher oder später zur Ohnmacht.

Obwohl ständig vor dem Einsatz der Sprachen C/C++ gewarnt wird /16/, steigt die Anzahl der Projekte, die in C/C++ programmiert werden ständig. Die Betriebssystemhersteller verstärken diesen Trend weiter, indem sie Ihre Schnittstellen oft ausschliesslich für den Aufruf aus C/C++ dokumentieren.

Ziel dieses Artikel soll sein, die Sensibilität bei der Auswahl einer geeigneten Programmiersprache zu erhöhen. Es wird gezeigt, welche qualitätssteigernde Auswirkungen der Einsatz von geeigneten Hochsprachen bei der Realisierung von sicherheitskritischen Anwendungen hat.

Software Life-Cycle

Der Entstehungsprozeß eines Software-Projektes vollzieht sich über mehrere Stufen. Nach dem klassischen Life-Cycle-Modell sind die Abschnitte eingeteilt in

	-  Anforderungsanalyse bzw. -definition 
	-  Software-Entwurf,
	-  Implementierung, 
	-  Test und Abnahme  und letzlich 
	-  Betrieb, Wartung, Pflege.

In diesem Modell kommt es in der Regel zu Iterationen, d.h. daß z.B. auftretende Fehler beim Test der Software eine geänderte Implementierung zur Folge haben. In die Entwicklung sind die drei Faktoren Zeit, Kosten und Produktqualität stark eingebunden. Softwareprojekte werden oft nicht termingerecht fertiggestellt. Terminprobleme können zum Abbruch oder Scheitern eines ganzen Projektes führen oder die Marktchancen für ein Produkt verschlechtern. In der Regel werden mehr als 70% der gesamten Softwarekosten durch die Wartung eines Produktes verursacht.

Die Kosten für die Wartung sind so hoch, weil Fehler erst sehr spät in der Betriebsphase beim Kunden gefunden werden und weil wegen Produktmängel für Fehleranalyse und -behebung hoher Aufwand betrieben wird /1/.

Die Wahl einer geeigneten Programmiersprache hat einen entscheidenen Einfluß auf den Gesamtablauf und somit auf die Gesamtkosten eines Softwareentwicklungsprozesses. Entwicklungsbegleitend ist die Qualitätssicherung ein Instrumentarium das alle Bereiche - von der Planung über den Entwurf, Implementierung bis hin zur Wartung - abdecken soll. Dabei unterscheidet man zwischen den konstruktiven Maßnahmen und analytischen Maßnahmen. Zu den konstruktiven Maßnahmen gehören u.a. die Auswahl von Methoden und Werkzeugen; in der Softwareentwicklung sind das die Compiler.

In den meisten Firmen und Instituten werden heute überwiegend veraltete und unsichere Programmiersprachen eingesetzt. Zu diesen veralteten Programmiersprachen zählen u.a. C (1972), FORTRAN (1962) und deren Derivate. Von den Compilern dieser Sprachen werden nur geringe bzw. keine Datentypprüfungen vorgenommen. Sie bieten weder ausreichende statische noch dynamische Feldgrenzenüberwachung (array index checks). Das Sprachkonzept von C macht sogar die Nachrüstung solcher Überprüfungen unmöglich. Auch lassen diese Sprachen ein ausgereiftes, durchgängiges Modulkonzept vermissen.

Viele Compilerhersteller versuchen die Mängel der veralteten Programmiersprachen durch implementierungsabhängige Erweiterungen zu verbessern, z.B. durch das nachträgliche Aufsetzen eines Modulkonzeptes. Die Schwierigkeiten, die man sich durch die Verwendung solcher Erweiterungen einhandelt, werden offensichtlich sobald eine Portierung auf eine andere Plattform notwendig wird. Der Compiler der neuen Hardware bzw. des neuen Betriebssystems bietet die benutzten Erweiterungen meist nicht an, so daß langwierige Adaptionsarbeit und manchmal auch ein Redesign der Software notwendig wird.

Weiter lassen die Standards bei der Sprachdefinition eine Vielzahl von wichtigen Punkte offen. Bei ANSI C (siehe Appendix F von /15/) ist die Liste der portabilitätsbeeinträchtigenden Implementierungsabhängigkeiten besonders lang. Eine solche unvollständige Sprachbeschreibung impliziert, daß gleiche Programmteile auf unterschiedlichen Plattformen unterschiedlich Semantik aufweisen können.

Durch den Einsatz von unzureichend spezifizierten Sprachen ist eine frühestmögliche Fehlererkennung nicht gewährleistet. Somit verliert der Softwareentwickler wertvolle Zeit -und eventuell Motivation-, um Programmierfehler aufzuspüren. Bedenkt man, daß es sich bei den Fehlern nicht nur um Typfehler handelt, sondern auch um Tippfehler, Pointerfehler, Semantikfehler und Fehler durch Redundanz, erkennt man, daß sich die Abwesenheit von Fehlern umgekehrt proportional zur Fehlererkennungsrate eines Compilers verhält.

Es wird viel vermeidbarer personeller, zeitlicher und materieller Aufwand für Analysewerkzeuge betrieben, um die Qualität der Software nachträglich zu sichern und zu erprüfen.

Wichtige qualitätssichernde Forderungen einer Programmiersprache sind

        1. Einfachheit
        2. Modularisierung
        3. Sicherheit
        4. Information Hiding
        5. Selbstdokumentation
        6. Wiederverwendbarkeit

Heute stehen moderne Programmiersprachen zur Verfügung, die den Stand der Technik im Software Engineering repräsentieren, und diesen Anforderungen durch ihre Eigenschaften gerecht werden, z.B. Modula-2 /12/, /13/ und ihr spartanischer Nachfolger Oberon-2 /17/, wenn's OOP sein soll. Im weiteren wird zwar nur noch Modula-2 angesprochen, weil dort bereits eine internationale Norm vorhanden ist, das meiste gilt jedoch auch für Oberon-2.
Auch bei Oberon-2 gibt es bereits erste Standardisierungsbestrebungen, die darauf hinauslaufen, alle Erweiterungen zu verbieten. Wer mehr über Oberon-2 wissen will, dem sei das Buch /17/ empfohlen.

1.Einfachheit

Die Sprache Modula-2 erfüllt die Forderung nach einer unmißverständlichen und vollständigen Sprachbeschreibung. Die Semantik der Sprachkonstrukte und Bibliotheksfunktionen sind in einer mathematisch exakten Beschreibung definiert (VDM-SL: Vienna Development Method-Semantik Language /14/) im ISO Modula-2 Standard 1992 /12/.

Das Sprachkonzept ist einfach, eindeutig, syntaktisch durchgängig und überschaubar, so daß die Sprache leicht zu lernen und Programme leicht lesbar sind. Dieser Punkt ist sehr wichtig, wenn man bedenkt, daß viele Programmierer nicht ausgebildete Informatiker sondern fachfremd sind. Andere, relativ moderne Programmiersprachen sind sehr komplex und schwerer lernbar (z.B. Ada oder C++). Für die Entwicklung korrekter und überschaubarer Programme ist ein einheitliches Sprachkonzept wichtige Prämisse.

2. Modularisierung

Modula-2, gleichzeitig Spezifikations- und Entwicklungssprache, unterstützt den Designprozeß und die Strukturierung von Programmen, da sie ein Modulkonzept besitzt, was eine Entwicklung von großen Projekten einfacher handhaben läßt. Während der Entwurfsphase können mit der Möglichkeit der Modulspezifikation Entwürfe großer Systeme dokumentiert werden. Entwurf und Implementierung entsprechen in Modula-2 der Trennung in Definitions-Modul (Schnittstellenbeschreibung) und Implementations-Modul.

Durch die Separierung der Software in Module wird die Wiederverwendbarkeit gefördert, da diese Module in einer Bibliothek zusammengefaßt werden können. Damit werden Kosten durch Codeerstellung gesenkt. Durch die Modulorientierung wird zusätzlich die Wartbarkeit der Software gesteigert. Modula-2 unterstüzt programmiertechnisch die gedankliche Zerlegung in unabhängige Module elegant und effektiv, ohne das der Programmierer einen Modulersatz außerhalb der Sprachmittel für das Zusammenwirken der Modulkomponenten konstruieren muß.

Durch die Gliederung der Aufgaben in Module wird mit Modula-2 die Top-Down-Entwicklung unterstützt. Bei der Wiederverwendung bestehender Modul-Einheiten wird die Bottom-up-Methode gefördert. Die Module können getrennt übersetzt werden, wobei während der Compile-Zeit durch den Compiler die Überprüfung von Abhängigkeiten und Schnittstellen über Modulgrenzen hinweg erfolgt. Dabei werden Anzahl und Typen aller benutzten Parameter überprüft.

Somit werden Entwurfs- und/oder Implementierungsfehler im frühestmöglichem Entwicklungsstadium entdeckt, die sonst erst bei der Integrationsphase auftreten und unter erheblichem Aufwand behoben werden müssen. Die Qualitätseigenschaft Modularisierung minimiert den Integrationsaufwand. Durch die vom Compiler überwachte Übersetzungsreihenfolge werden Versionskonflikte vermieden.

3. Sicherheit

Modula-2 besitzt eine strenges Typkonzept und detektiert somit zuverlässig Typfehler, Pointerfehler usw.. Sowohl bei der Übersetzung wie auch zur Laufzeit finden Typprüfungen statt. Während der Laufzeit werden Verletzungen von Feldgrenzen (Indexüberschreitung), numerische Fehler und Wertebereichsüberschreitungen von Typen detektiert.

Es finden konsequente Schnittstellenkontrollen statt, d.h. Typ und Anzahl der übergebenen Parameter zu externen Modulen werden während der Übersetzung vollständig geprüft. Dadurch wird ein fehlervermeidendes, sicheres Programmieren von großen Programmsystemen unterstützt. Durch das Auffinden von Fehlern während der Übersetzung werden Kosten in der Test- und Wartungsphase reduziert und die Zuverlässigkeit des Produktes gesteigert.

Auch eine Programmverifikation durch Umwandlung von Modula-2 Quellcode in VDM-SL /12/,/14/ und Vergleich mit der formalen Spezifikation des Algorithmus ist möglich. Die Anwendung dieser Methode wird in /9/ anhand eine Datenverschlüsselungs-Applikation illustriert.

4. Information Hiding

Durch das Modularisierungsprinzip kann ein komplexes Problem in Teilaufgaben d.h. Module zerlegt werden. Ein Modul übernimmt bestimmte Aufgaben, die unabhänging vom Gesamtsystem gelöst wird. Für die Benutzung des Moduls ist es unerheblich, wie die Lösung realisiert wurde. Im Inneren des Modul sind die Implementierungsdetails wie Daten und Algorithmen verborgen (Information Hiding) und sind für den Anwender nicht sichtbar.

5. Selbstdokumentation

Modula-2 ist selbstdokumentierend und somit auch für Personen außerhalb des Entwicklungskreises (Kunden, Gutachter, neue Mitarbeiter usw.) gut lesbar. Die Lesbarkeit von Programmtext wird von den Strukturelementen und den Datentypen der Sprache, sowie der optischen Anordnung der Texte geprägt. Es wird mehr lesbarer Programmtext geschaffen und Zeilenkommentare können reduziert werden.

Unter diesem Aspekt ergibt sich auch eine gute Wartungsfreundlichkeit der Programme, da bei späteren vorzunehmenden Änderungen der Programmcode schnell verstanden und modifiziert werden kann. Der Software-Lebenszyklus beläuft sich auf mehr als 15 Jahre. Oft sind die Autoren der Programme nach dieser Zeit nicht mehr verfügbar, um Änderungen vorzunehmen. Bei Modifikationen einer Software durch andere Entwickler, ist es notwendig daß die Programme leicht verständlich geschrieben sind. Mit Modula-2 sind diese Personenabhängigkeiten entschärft. Dieser Punkt darf nicht unterschätzt werden, wenn man bedenkt, daß die Wartung von Programmen den größten Kostenanteil ausmacht.

6. Wiederverwendbarkeit

Durch die Separierung in Definitions- und Implementations-Modul erhält man eine komplette Schnittstellenbeschreibung. Somit können die Module problemlos auch in anderen Softwareprojekten wiederverwendet werden. Auch kann bestehende Software in anderen Programmiersprachen angebunden werden, so daß bisherige Entwicklungsinvestitionen nicht verloren gehen.

Außer diesen relevanten qualitätsfördernden Punkten, hat die Programmiersprache Modula-2 gegenüber anderen Programmiersprachen weitere Eigenschaften:

Die IEC 65A ist ein internationaler Standard, der die Forderungen an ein sicherheitsbezogens Softwaresystem bereitstellt /5/. Dieser Standard empfiehlt den Einsatz der Programmiersprache Modula-2 für die Entwicklung von sicherheitskritischer Software. Was die Sicherheitskriterien angeht, wird C in der IEC 65A dagegen weitgehend abwertend und zum Teil sogar mit Assembler gleichgestellt.

Der Einsatz dieser Sprache sollte sich nicht nur auf die Entwicklung sicherheitsbezogener Projekte beschränken. Die guten Eigenschaften von Modula-2 kann auf alle Anwendungsbereiche der professionellen Softwareentwicklung einen positiven Einfluß haben. In zukünftigen Softwareprojekten sollte diese Sprache aus Qualitätsgründen, aber auch wegen Effizienzsteigerung und Kostenersparnis zum Einsatz kommen.

Mit Modula-2 steht eine inhärent sichere Programmiersprache zur Verfügung die den Qualitätsprozeß per se unterstützt, und durch Klarheit und Ästhetik besticht. Gerade in hochzuverlässigen und sicherheitstechnisch relevanten Bereichen und Anwendungen sollte die Softwareentwicklung nach modernen Gesichtspunkten vollzogen werden um das Vertrauen der Kunden, die Motivation der eigenen Mitarbeiter und das Ansehen der Firma zu gewinnen bzw. zu stärken.

Nach den einschlägigen Qualtitätsanforderungen ist jeder Mitarbeiter selbst für die Qualität seiner Arbeit verantwortlich. Diese Verantwortlichkeit gegenüber der eigenen Arbeit ist leichter und einfacher zu übernehmen, wenn die dazu geeigneten Mittel -sprich moderne Programmiersprachen- zur Verfügung stehen. Software kann nur so gut sein, wie die Technologie die sie generiert. Die Qualität eines Produktes ist jedoch nur so gut, wie das schwächste Glied in der Kette der Qualitätsmaßnahmen.

Literaturhinweise:

/1/ Ernest Wallmüller, Software-Qualitätssicherung in der Praxis, Carl Hanser Verlag München Wien 1990
/2/ Kurt Kurbel, Programmierstil in Pascal, Cobol, Fortran, Basic, PL/1, Springer Verlag Berlin, Heidelberg, New York, Tokyo 1985
/3/ Alan Feuer, Narain Gehani / Editors, Comparing & Assessing Programming Languages Ada C Pascal, Prentice Hall, Inc. 1984
/4/ M. Albinus, B. Kreutzer, R. Lenga, J. Müller, D. Neumann, H. Pietsch, Effektivitätsvergleich zwischen Modula-2 und C, Akademie der Wissenschaften der DDR, Institut für Informatik und Rechentechnik
/5/ Software for Computers in the Application of industrial safety-related Systems, IEC 65A(Secretariat)122 Version 1.0 vom 26. September 1991
/8/ Gisela Hoogen, GEI, Wartung von C-Programmen: Zwischen Neuentwicklung und Re-Engineering, Mini Micro Magazin 7-8, 1992
/9/ Richard Lampard, Making IT secure, BYTE (International Edition) Februar, 1992
/10/ Jochen Ludewig, Sprachen für die Programmierung, Eine Übersicht, B.I.-Hochschultaschenbücher Band 622 Mannheim, Wien, Zürich
/11/ DIN IEC 880
/12/ IEC/ISO 10154, ISO Modula-2, 2nd Committee Draft, de Beuth Verlag, Berlin, 1992
/13/ Niklaus Wirth, Programming in Modula-2, 3rd Edition, Springer Verlag, Berlin, 1985
/14/ Derek Andrews, How to read VDM-SL, Univerisity of Leicaster (UK), May 1991
/15/ C-American National Standard X3.159-1989, Appendixes F. Portability Issues p.199-209
/16/ Ian Joyner C++?? A C++ critique
/17/ Hanspeter Mössenböck, Objektorientiertes Programmieren in Oberon-2, Springer Verlag, 1992

Dieser Artikel ist in abgeänderter Form im Deckblatt, AWi-Verlag, D-85630 Grasbrunn erschienen.


[ Home | Site_index | Legal | OpenVMS_compiler | Alpha_Oberon_System | ModulaTor | Bibliography | Oberon[-2]_links | Modula-2_links | General interesting book recommendations ]
Books Music Video Enter keywords...


Amazon.com logo
Webdesign by www.otolo.com/webworx, 21-Nov-1998. © (1998) ModulaWare.com