Nützlichkeit von Zusicherungen als Hilfsmittel beim Programmieren
Ein kontrolliertes Experiment
- Art: Diplomarbeit
- Autor: Rainer Typke
- Abgabedatum: April 1999
- Umfang: 105 Seiten
- Dateigröße: 1,5 MB
- Institution / Hochschule: Universität Fridericiana Karlsruhe (TH) Deutschland
- ISBN (eBook): 978-3-8324-2395-7
-
ISBN (Paperback) :
978-3-8324-2395-7 P - ISBN (CD) :978-3-8324-2395-7 CD
- Sprache: Deutsch
- Prämierung:
- Arbeit zitieren: Typke, Rainer April 1999: Nützlichkeit von Zusicherungen als Hilfsmittel beim Programmieren, Hamburg: Diplomica Verlag
- Schlagworte: Entwicklung, Korrektheit, Software Engineering, Design by Contract, Zusicherungen
In den Warenkorb
38,00 €
Diplomarbeit von Rainer Typke
Einleitung:
Die meisten Artikel zum Thema Zusicherungen, darunter auch fast alle hier angesprochenen, heben die Vorzüge von Zusicherungen als Hilfsmittel beim Programmieren hervor, ohne aber ihre Kernaussage - mit Zusicherungen kann man besser programmieren als ohne - empirisch zu untermauern. Einige Autoren, wie z. B. Rosenblum und McKim, haben selbst viel mit Zusicherungen programmiert, so daß ihre Aussagen durch eigene Erfahrungen gestützt werden. Trotzdem steht ein Experiment, das die Nützlichkeit von Zusicherungen für die Neuentwicklung oder Wartung von Software empirisch mit mehreren Programmierern, die an denselben Problemen und mit denselben Werkzeugen arbeiten, untersucht, noch aus. Das ist der Anlaß für diese Diplomarbeit.
Gang der Untersuchung:
Kapitel 2 beschreibt die beiden Zusicherungswerkzeuge, die in diesem Experiment eingesetzt werden. In Kapitel 3 werden die Hypothesen, der Aufbau des Experiments, die Versuchspersonen und die Aufgaben beschrieben, die ihnen gestellt wurden.
Die Ergebnisse, die aus den protokollierten Daten gewonnen wurden, werden in Kapitel 4 dargestellt, und Kapitel 5 beschließt die Ausarbeitung mit Zusammenfassung und Ausblick.
Im Anhang sind die Aufgabenblätter und komplette Beispiele für interaktive Syntaxkurs-Sitzungen enthalten. Außerdem finden sich dort einige Tabellen mit Daten, die im Experiment gewonnen wurden und Detailinformationen liefern, die im Kapitel 4 nicht erwähnt werden.
Die Programme, die in diesem Experiment von den Versuchspersonen erweitert wurden, die Rohdaten, die dabei gewonnen wurden, und die Perl-Programme für die Auswertung der Daten und zum Training der Versuchspersonen sind nicht in dieser Ausarbeitung enthalten. Sie sind unter http://wwwipd.ira.uka.de/EIR verfügbar.
Inhaltsverzeichnis:
| 1. | Einleitung | |
| 1.1 | Zusicherungen | 6 |
| 1.2 | Grundidee des Experiments | 8 |
| 1.3 | Verwandte Arbeiten | 8 |
| 1.3.1 | Störk: jContract | 8 |
| 1.3.2 | Leveson, Cha et al.: empirische Studie | 9 |
| 1.3.3 | Schneider: Concurrent Programming | 9 |
| 1.3.4 | Luckham et al.: Two-dimensional Pinpointing | 10 |
| 1.3.5 | McKim: Designing for correctness | 10 |
| 1.4 | Nützlichkeit eines Experiments | 10 |
| 1.5 | Gliederung der Ausarbeitung, Rohdaten | 10 |
| 2. | Die verwendeten Zusicherungswerkzeuge | 12 |
| 2.1 | APP | 12 |
| 2.2 | jContract | 16 |
| 3. | Beschreibung des Experiments | 19 |
| 3.1 | Fragestellung und Hypothesen | 19 |
| 3.2 | Aufbau des Experiments | 20 |
| 3.2.1 | Versuchspersonen | 21 |
| 3.2.2 | Klassifizierung und Vorsortierung der Versuchspersonen | 21 |
| 3.2.3 | Auswahl der Aufgaben | 23 |
| 3.2.4 | Teilaufgabe mit Neuentwicklungscharakter | 26 |
| 3.2.5 | Teilaufgabe mit Wartungscharakter | 26 |
| 3.2.6 | Reihenfolge der Aufgaben, Ablauf des Experiments | 27 |
| 3.2.7 | Unterschiede in den C- und Java-Aufgaben | 28 |
| 3.2.8 | Training der Teilnehmer vor dem Experiment | 28 |
| 3.3 | Bedrohungen der internen Gültigkeit | 29 |
| 3.4 | Bedrohungen der externen Gültigkeit | 32 |
| 3.5 | Technischer Versuchsaufbau | 32 |
| 3.5.1 | Kooperationsmöglichkeiten | 32 |
| 3.5.2 | Syntaxkurs und Skripte zum Übersetzen und Testen | 33 |
| 3.5.3 | Erfaßte Daten | 35 |
| 4. | Ergebnisse | 37 |
| 4.1 | Signifikanztest und Diagramme | 37 |
| 4.1.1 | Signifikanztest | 37 |
| 4.1.2 | Der Boxplot | 37 |
| 4.1.3 | Trendgeraden | 38 |
| 4.2 | Schwächen von jContract | 38 |
| 4.3 | Bereitschaft zur Verwendung von Zusicherungen | 39 |
| 4.4 | Zeitbedarf | 40 |
| 4.4.1 | Zur Ermittlung der Zeitdaten | 40 |
| 4.4.2 | Zeitbedarf mit und ohne Zusicherungen | 42 |
| 4.4.3 | Rückschlüsse aus dem Zeitbedarf | 48 |
| 4.4.4 | Zusammenhang zwischen Anzahl der Zusicherungen und Zeitbedarf | 48 |
| 4.5 | Wiederverwendung von Funktionen | 51 |
| 5. | Zusammenfassung und Ausblick | 55 |
| Anhang | 57 | |
| Literaturverzeichnis | 104 |
wurde. Sobald eine Versuchsperson fertig war, wurde ihre Losung kopiert und im Ar¨ beitsverzeichnis der Versuchspersonen geloscht, so daß sie fur andere Teilnehmer nicht ¨ ¨ mehr lesbar war. Daruber hinaus wurden Teilaufgaben, sobald sie vom weiter unten ¨ beschriebenen Testskript als korrekt erkannt wurden, in ein Verzeichnis kopiert, dessen Name mit einem Punkt beginnt12 , so daß sie nicht mehr offensichtlich waren. Wenn also ein Paar von Versuchspersonen die Teilaufgaben in umgekehrter Reihenfolge bearbeitete und ungef¨ hr zur selben Zeit mit der ersten Teilaufgabe fertig wurde, vera schwanden die Losungen, die nun jeweils fur die andere Versuchsperson interessant ¨ ¨ wurden, automatisch in den versteckten Verzeichnissen. ¨ 3.5.2 Syntaxkurs und Skripte zum Ubersetzen und Testen Der interaktive Syntaxkurs, dessen Zweck in Abschnitt 3.2.8 beschrieben und fur den ¨ in Anhang Beispielsitzungen wiedergegeben sind, wurde in Perl als CGI-Skript implementiert, so daß er mit einem beliebigen Browser durchlaufen werden kann13 . Im Experiment wurde Netscape, Version 4.06 eingesetzt. Die Entscheidung, das Skript in Perl zu implementieren, wurde vor allem durch die Moglichkeiten beeinflußt, die re¨ gul¨ re Ausdrucke fur die Analyse der Benutzereingaben bieten. Mit regul¨ ren Ausa ¨ a drucken l¨ ßt sich gut uberprufen, ob die Benutzereingabe syntaktisch und semantisch a ¨ ¨ korrekt ist, ohne den Benutzer auf wenige Moglichkeiten einzuengen. Selbst solche ¨ Ausdrucke, wie sie bei Quantoren in APP und jContract auftreten, lassen sich gut ¨ analysieren. Die Besonderheit dabei ist, daß der Benutzer einen beliebigen Bezeichner w¨ hlen und in seine Zusicherung einbauen kann. Das Syntaxkurs-Programm stellt, a falls mehr als die H¨ lfte der Eingaben als korrekt erkannt wurden, im Arbeitsverzeicha ¨ ¨ nis der Versuchsperson die Dateien bereit14 , die fur die entsprechende Aufgabe notig sind. Die Information, welche Dateien fur eine bestimmte Versuchsperson notig waren, ¨ ¨ erh¨ lt das Syntaxkurs-Programm durch die Eingabe einer eindeutigen Personennuma mer. ¨ Es wurden jeweils ein Skript zum Ubersetzen der Quelltexte, zum versuchsweisen Ablaufenlassen des Programms und zum Testen der Korrektheit bereitgestellt, außerdem die fur die entsprechende Aufgabe benotigten Quelltexte, je nach Gruppenzugehorig¨ ¨ ¨ keit des Teilnehmers mit oder ohne Zusicherungen. ¨ Das Skript zur Ubersetzung des Programms verbirgt vor dem Benutzer die zus¨ tzliche a Komplexit¨ t, die die Verwendung eines Zusicherungswerkzeuges mit sich bringt. Die a APP-Variante sorgt dafur, daß bei den Aufgabenvarianten mit Zusicherungen der APP¨ Pr¨ prozessor anstelle des normalen CPP-Pr¨ prozessors verwendet wird, und daß am a a [...]
3.5.1 Kooperationsmoglichkeiten ¨ Die meisten Teilnehmer des Experiments stammten aus einem Praktikum (siehe hierzu 3.2.1) und mußten am Experiment teilnehmen, um den Praktikumsschein zu erhalten. Daher kann zumindest bei einigen Personen unterstellt werden, daß sie vor allem das Ziel verfolgten, mit minimalem Arbeitsaufwand die Voraussetzungen fur den Schein ¨ zu erfullen und nicht in erster Linie am Ausprobieren von Zusicherungswerkzeugen ¨ interessiert waren. Es liegt also die Frage nach der Gelegenheit zu unerwunschten In¨ teraktionen der Teilnehmer nahe. Die Versuchspersonen verwendeten Sun-SPARCclassic-Maschinen, auf denen sie unter einer gemeinsamen Benutzerkennung, aber in verschiedenen Verzeichnissen arbeiteten11 . Es waren meist nur zwei oder drei Rechner gleichzeitig verfugbar, so daß das ¨ Problem moglicher Kooperation oder des Kopierens der Losungen anderer Versuchs¨ ¨ personen stark abgemildert wurde — meistens arbeiteten nur zwei Versuchspersonen gleichzeitig, die außerdem immer unterschiedlichen Gruppen angehorten, also ent¨ weder die Aufgaben in unterschiedlicher Reihenfolge bearbeiteten oder sogar unterschiedliche Programmiersprachen benutzten. Normalerweise saßen sie auch nicht allein im Raum, so daß mundliche Kooperation ebenfalls auf ein Minimum beschr¨ nkt ¨ a [...]
Die Ergebnisse des Experimentes sollten idealerweise auf alle Softwareentwickler anwendbar sein. Fur das Experiment standen aber, abgesehen von den beiden wis¨ senschaftlichen Mitarbeitern, nur Karlsruher Informatikstudenten zur Verfugung, die ¨ am PSP-Praktikum teilgenommen hatten. Unter ihnen sind zwar wahrscheinlich viele zukunftige professionelle Softwareentwickler; trotzdem kann nicht ausgeschlossen ¨ werden, daß die Experimentergebnisse mit einer zuf¨ llig ausgew¨ hlten Stichprobe aus a a der Menge aller Softwareentwickler anders ausgefallen w¨ ren. a Allerdings setzt dieses Experiment nur allgemeine F¨ higkeiten wie das Schreiben eina facher Funktionen in C oder Java und das Verstehen bereits existierenden Quelltextes voraus. Spezialkenntnisse in außerhalb der Informatik liegenden Fachgebieten oder vertiefte Kenntnisse in einem bestimmten Gebiet der Informatik, wie sie typischerweise eher bei erfahrenen Softwareentwicklern als bei Studenten auftreten, waren fur die ¨ Bearbeitung der Aufgaben nicht erforderlich. [...]
In den Warenkorb
38,00 €
Link zur Arbeit:
http://www.diplom.de/ean/9783832423957
Arbeit zitieren:
Typke, Rainer April 1999: Nützlichkeit von Zusicherungen als Hilfsmittel beim Programmieren, Hamburg: Diplomica Verlag
Schlagworte:
Entwicklung, Korrektheit, Software Engineering, Design by Contract, Zusicherungen



