Softwarewartung in der Forschung
Python-Edition JVM-Edition Blog … Bibliothek —> Softwarewartung in der Forschung von Konrad Hinsen, veröffentlicht am 26. Feb. 2014 Softwarewartung ist eine der Schwierigkeiten, mit denen Entwickler wissenschaftlicher Software regelmäßig konfrontiert sind.
Es handelt sich um eine wichtige Tätigkeit, die jedoch viel Zeit in Anspruch nimmt und nach den heutigen Bewertungsverfahren kaum belohnt wird. Wer ein großes Softwareprojekt leitet, hat zudem meist große Probleme, Fördermittel für die Wartung zu erhalten. Da Softwarewartung schwierig ist und kein intrinsisches wissenschaftliches Interesse weckt, sollten wir uns die Frage stellen, warum sie überhaupt notwendig ist und ob wir etwas tun können, um den Wartungsbedarf zu reduzieren.
Was ist zunächst einmal Softwarewartung? Merriam-Webster definiert das Verb „maintain” (warten) als den Zustand, (etwas) durch Reparaturen, Problembehebungen usw. in gutem Zustand zu halten. Das ergibt Sinn für technische Geräte, die im Laufe der Zeit durch mechanischen Verschleiß usw. verschleißen. Software unterliegt keinem solchen Verschleiß; daher muss „Wartung” im Kontext von Software etwas anderes bedeuten. Mir ist keine konsensfähige Definition bekannt, weshalb ich hier meine eigene anbiete: Softwarewartung besteht in der Modifikation von Software aus einem von zwei Gründen:
- Behebung von Fehlern (Bugs).
- Sicherstellung der Nutzbarkeit der Software in sich wandelnden Rechenumgebungen.
Manche würden dieser Liste noch funktionale Erweiterungen hinzufügen, doch diese sind eigentlich keine Wartung im eigentlichen Sinne, sondern Verbesserungen. Dies gilt insbesondere für wissenschaftliche Software, bei der neue Funktionalität oft neue Wissenschaft bedeutet.
Zunächst zu den Fehlern. Wie bei jeder Software wollen wir auch in wissenschaftlicher Software Fehler behoben wissen, um künftig bessere Ergebnisse zu erzielen.
Gleichzeitig möchten wir die fehlerhafte Version jedoch aufbewahren, falls sie in einer bereits veröffentlichten wissenschaftlichen Studie verwendet wurde. Dies ist schlichtweg eine Frage der Ehrlichkeit und der Bewahrung des wissenschaftlichen Records: Besteht die Möglichkeit, dass das Ergebnis einer Studie durch einen Softwarefehler beeinflusst wurde, müssen Personen, die diese Studie prüfen, dies feststellen können. Sie müssen Zugang zu exakt derselben Software haben, die ursprünglich verwendet wurde, und nicht nur zur heutigen, verbesserten Nachfolgeversion.
Verwandte: — Projektbasierte Data-Science-Pfade mit geführtem Terminal und realen Datensätzen.
Aus diesem Grund ist es tatsächlich wichtiger, den in einer Studie verwendeten Code zu bewahren, als Fehler zu beheben.
ActivePapers wurde mit genau diesem Ziel entworfen: Jedes berechnete Datenelement in einem ActivePaper ist mit der Software verknüpft, die es erzeugt hat. Darüber hinaus ist diese Verknüpfung nach der Veröffentlichung streng unveränderlich, da ActivePapers ebenso wie elektronische Kopien von Artikeln veröffentlicht und über DOIs referenziert werden.
Man kann vor der Veröffentlichung betrügen, indem man ein ActivePaper mit der spezifischen Absicht modifiziert, Betrug zu begehen. ActivePapers unterstützt solche Handlungen nicht, unternimmt aber auch keine Anstrengungen, Betrug aktiv zu verhindern. Solche Funktionen ließen sich durch den Schutz von Provenienzinformationen mittels Hashes implementieren, doch ich hoffe, dass dies nicht notwendig sein wird.
Einen Blick wert: — Ein Abonnement für von der Universität unterstützte Python- und Data-Science-Zertifikate.
Das zweite Problem, sich wandelnde Rechenumgebungen, ist subtiler. Es ist eine Tatsache, dass sich in der Computerwelt alles (Computer, Betriebssysteme, Compiler, Sprachdefinitionen, Bibliotheken, …) schnell verändert, mit der Folge, dass ein bestimmter Quellcode wahrscheinlich nicht mehr unverändert funktionieren wird, wenn einige Jahre vergangen sind.
Dies geschieht aus zwei Gründen: (1) Der technische Fortschritt ermöglicht immer bessere Computer und Software, was die Menschen auch wollen, und (2) niemand hat ein eigenes Interesse an der Stabilität von Rechenplattformen oder die Macht, diese herbeizuführen. Für Hardware-Hersteller und Anbieter kommerzieller Software ist schneller Wandel der beste Weg, um sicherzustellen, dass Kunden neue Maschinen kaufen und ihre Lizenzen regelmäßig aktualisieren.
Es gibt natürlich mindestens eine Gemeinschaft, die ein eigenes Interesse an der Stabilität von Rechenplattformen hat: die Gemeinschaft der computergestützten Wissenschaften. Wenn wir unsere Software auch noch nach 20 Jahren ohne Modifikation ausführen und dieselben Ergebnisse erhalten könnten, wären wir glücklich.
Wir wollen keine Softwarewartung betreiben, und die meisten von uns können die für ihre eigene Forschung entwickelte Software vernünftigerweise nicht über ihren unmittelbaren persönlichen Bedarf hinaus warten. Noch weniger vernünftig ist die Erwartung, dass jemand die Software eines anderen wartet, beispielsweise die Software, die ein Doktorand hinterlassen hat, der nun in der Industrie arbeitet. In der Praxis wird nur weit verbreitete Community-Software über ausreichend lange Zeiträume gewartet.
Doch selbst Forschungsprojekte, die weit verbreitete und gewartete Pakete nutzen, benötigen meist auch projektspezifische Software, zumindest ein paar Shell-Skripte. Und das ist einer der Gründe, warum die Reproduzierbarkeit computergestützter Studien so schlecht ist.
Könnte die wissenschaftliche Gemeinschaft etwas dagegen unternehmen? Ich glaube ja, bin aber nicht optimistisch, dass sie in naher Zukunft handeln wird. Es ist wahrscheinlich, dass Wissenschaftler weiterhin Standardhardware für wissenschaftliches Rechnen verwenden werden, was bedeutet, dass sie die Entwicklung der Hardware und der zugehörigen Systemsoftware akzeptieren müssen, die außerhalb ihrer Kontrolle liegt.
Sie können jedoch auf diesen sich ständig wandelnden Grundlagen eine stabile Plattform aufbauen, zumindest für den rein rechnerischen Teil ihrer Arbeit.
Auf fundamentaler Ebene sind alle Turing-vollständigen Notationen für Software äquivalent und können ineinander umgewandelt werden. In der Praxis setzen Leistungsanforderungen der Code-Konversion Grenzen, dennoch ist es möglich, Code-Repräsentationen zu definieren, die effizient auf alle Arten zugrunde liegender Hardware und Systemsoftware übersetzt werden können und somit stabil bleiben.
Zwei Beispiele aus der Praxis sind JVM-Bytecode und LLVMs Zwischenrepräsentation. JVM-Bytecode existiert seit 20 Jahren und hat sich als äußerst stabil erwiesen. LLVMs Zwischenrepräsentation ist nicht auf Stabilität ausgelegt, doch das liegt daran, dass die LLVM-Entwickler ihre zukünftigen Optionen nicht durch die Festlegung auf eine stabile Repräsentation einschränken wollen. Googles PNaCl-Projekt versucht, diese Warnung zu ignorieren und LLVM-Code so zu verwenden, dass es nur sinnvoll ist, wenn er stabil bleibt. Die Zeit wird zeigen, wie das ausgeht.
Die wissenschaftliche Gemeinschaft könnte ihre eigene Zwischen-Code-Repräsentation definieren, dabei auf Erfahrungen mit bestehenden Ansätzen aufbauen und ihre Plattform für wissenschaftliche Anwendungen optimieren. Doch wie oben erwähnt, bin ich nicht optimistisch, dass dies geschehen wird.
Zwei Voraussetzungen wären ein langfristiges Engagement mehrerer großer Forschungs- und Förderorganisationen, diese Plattform über viele Jahrzehnte zu warten. Ich bin überzeugt, dass dies wirtschaftlich vernünftig wäre, denn ich bin sicher, dass die Wartung einer einzigen Plattform günstiger ist als die Wartung vieler wissenschaftlicher Softwarepakete und das ständige Neuschreiben jener Pakete, die nicht gewartet wurden. Es würde jedoch ein Maß an Übereinstimmung und Verpflichtung erfordern, das in der Wissenschaft selten ist; dies geschah bisher nur bei wenigen riesigen Installationen wie dem CERN.
Der wichtige Vorteil, den eine stabile Plattform bietet, ist der Grund, warum die erste ActivePapers-Edition rund um die JVM konzipiert wurde. Leider ist die JVM im wissenschaftlichen Rechnen nicht sehr beliebt.
Dies wird oft mit mangelnder Leistung begründet, obwohl dieses Argument nicht mehr so stichhaltig ist wie früher. Es gibt auch einige Designprobleme, insbesondere bezüglich Gleitkommaoperationen, doch dasselbe lässt sich über populäre Sprachen wie C oder C++ sagen, was Wissenschaftler nicht davon abgehalten hat, sie zu nutzen.
Die praktisch nützlichere Python-Edition von ActivePapers basiert auf einer Plattform, die durch das Scientific-Python-Ökosystem definiert wird (insbesondere Python, NumPy und h5py). Diese Plattform hat sich in der Vergangenheit als mäßig stabil erwiesen, wobei der Übergang zu Python 3 das größte Ereignis der Instabilität darstellte. Der Zeitraum, über den wissenschaftliche
Weiterführende Literatur
- SciPy — Wikipedia
Lernen Sie Python, indem Sie in Ihrem Browser programmieren
Interaktive Python- und Data-Science-Kurse, bei denen Sie direkt im Browser programmieren