Image: Software-Architekturen langfristig sicher und stabil haltenFERCHAUFERCHAUWie gelingt es, die Performance von Software trotz kontinuierlicher Weiterentwicklung hoch zu halten? | akindo
TechnikEvolutionsforschung am KIT

Soft­ware-Archi­tek­turen lang­fristig sicher und stabil halten

Lesezeit ca.: 4 Minuten
Lisa Kräher

Lisa Kräher

freie Journalistin

Software muss im Laufe der Jahre viel aushalten. Erweiterungen durch Online-Shops oder mobile Dienste zum Beispiel, oder einen Umzug auf die Cloud-Plattform. Zunehmende Komplexität macht Software anfällig. Forscher des Karlsruher Instituts für Technologie (KIT) stellen sich dieser Herausfor­de­rung. Ein Gespräch mit Professor Dr. Ralf Reussner, Inhaber des Lehrstuhls Software und Qualität am KIT, und Dr. Robert Henrich, Leiter der Forschungs­gruppe Qualitäts­ge­trie­bene System-Evolution

19. März 2019

Herr Professor Reussner, Software­sys­teme haltbar machen – was bedeutet das und warum ist das notwendig?

Prof. Reussner:  Man denkt immer, weil der Begriff Software das Wort „soft“ beinhaltet, dass man sie leichter anpassen kann als technische Artefakte beispiels­weise. Das ist ein Trugschluss. In der Praxis ist es meist so, dass Programme mit der Zeit sehr groß werden. Eine einzelne Person kann das nicht mehr überblicken. Die schiere Masse macht sie unübersicht­lich. Viele Abhängig­keiten zwischen Stellen der Software sind nicht offensicht­lich. Stellen, die man ändern müsste, werden übersehen. Die Software wird inkonsis­tenter, schlechter zu warten, fehleran­fällig.

Herr Doktor Heinrich, was sind die Gründe dafür, dass Software anwächst und übersicht­lich wird?

Dr. Heinrich: Die Lebensdauer einer Software kann 30 oder auch 50 Jahre betragen. Zeiträume, in denen sich viel verändert. Beispiele sind Software­sys­teme in Industrie­an­lagen oder Warenhäu­sern. Als die meisten von ihnen eingeführt wurden, gab es noch kein Internet. Spätestens alle zehn Jahre ändert sich die Plattform. Viel häufiger kommt ein neues Feature hinzu, zum Beispiel eine mobile Anwendung, die ursprüng­lich einmal nicht vorgesehen war. Das macht die interne Struktur der Software bröselig. Wir sprechen hier wie die Geologen von „Erosion“.

Und diese beschädigten Stellen sind schwer zu erkennen?

Prof. Reussner: Der Programm­code, den wir uns als Software vorstellen, ist ja nur das Endergebnis des Gedanken­pro­zesses eines Software­ent­wick­lers. Es gibt Prozesse, die aus dem reinen Betrachten des Codes sehr schwierig zu erschließen sind. Vieles ist im Code nicht sichtbar. Das ist wie bei einem Haus: den Grundriss zu verstehen, indem man die Gänge abläuft und die Zimmer nachmisst, ist nicht das gleiche, wie wenn man den kompletten Bauplan vor sich liegen hat. Wenn all die Gedanken und Überlegungen zur Planung verloren gehen und nicht ordentlich dokumentiert werden, ist das bei der Wartung ein Problem. Beim Haus und bei der Software.

Was untersuchen Sie am KIT in diesem Zusammen­hang?

Dr. Heinrich: In unserem Forschungs­pro­gramm „Design for Future – Managed Software Evolution“ suchen wir nach Wegen, wie wir langlebige Software evolutions­artig fortentwi­ckeln können. Dafür haben wir ein Testumfeld geschaffen, ein fiktives Warenwirt­schafts­system, wie es zum Beispiel ein Supermarkt nutzt, mit typischen Funktionen wie Warenver­kauf oder Lagerver­wal­tung. Das System namens CoCoME („Common Component Modeling Example“) ermöglicht uns Evolutions­sze­na­rien wie zum Beispiel den Umzug auf eine Cloud-Plattform oder das Hinzufügen eines mobilen Clients zu erproben. Verschie­dene Forscher­gruppen wenden ihre Ansätze zur Unterstüt­zung von langlebiger Software an unserem Testsystem an. Dabei können sie auf Ergebnisse anderer Forscher­gruppen aufbauen. Das ermöglicht eine höhere Vergleich­bar­keit und Akzeptanz ihrer Ergebnisse, da anstatt wie bisher eigene Testumge­bungen aufzubauen das gleiche System gemeinsam untersucht wird. In Kooperation mit Prof. Dr. Birgit Vogel-Heuser vom Lehrstuhl für Automati­sie­rung und Informati­ons­sys­teme der TU München, die ein Testumfeld für Industrie­an­lagen betreibt, untersuchen wir, wie sich Änderungen über verschie­dene Systeme ausbreiten und entwickeln Ansätze zur Unterstüt­zung der Evolution dieser Systeme im Zeitalter der Industrie 4.0.

Wie kann verhindert werden, dass Veränderungen die Software schwächen?

Prof. Reussner: Diese Probleme kann man angehen, in dem man versucht, Entschei­dungen zu transpor­tieren. Die Herausfor­de­rung ist dabei, dass die Software dennoch „leichtge­wich­tig“ bleiben muss. Schreiben Sie als Entwickler mal alles auf, was sie vorher entschieden haben. Das ergibt viel mehr Dokumenta­tion als bisher, der Aufwand dafür wäre viel zu hoch. Im Laufe unseres Projekts sind verschie­dene Werkzeuge entstanden, mit denen sich verändernde Software automatisch mitdokumen­tieren lässt. Diese Werkzeuge unterstützen also eine Art Knowledge Carrying Software und sie sind in der Lage, Wissen, das bei der Entwicklung entsteht, mit dem Code zu bündeln. 

Im besten Fall dokumentiert man also von Anfang an. Aber was ist mit all der alten Software, die in Betrieb ist? Ist es überhaupt möglich, da reaktiv zu handeln?

Dr. Heinrich: Bei unserem Projekt haben wir in erster Linie den Aspekt behandelt, wie man neu entstehende Software haltbar macht. Es gibt aber auch Werkzeuge, die die Software­ar­chi­tektur im Nachhinein analysieren und sogenannte „Bad Smells“ im Code finden.

Prof. Reussner: Das Thema Software­sa­nie­rung hat eine lange Tradition am KIT und FZI (Forschungs­zen­trum für Informatik, Karlsruhe). Wir beraten in diesem Bereich viele Industrie­firmen. Im Prinzip ist es immer ein gutes Zeichen, wenn ein Unternehmen sagt, ich will in Software investieren. Das muss nicht immer heißen, dass man die alte leichtfertig wegwirft. Viele Entwicklungen sind ja gar nicht vorhersehbar. Vor einigen Jahren hatten Firmen noch alles auf eigenen Servern, heute nutzt man die Cloud. Was man aber auf alle Fälle sagen kann: Im Zeitalter der Industrie 4.0 haben nur noch die Firmen Wettbewerbs­vor­teile, die schnell neue Anforderungen in Software realisieren können. Und dazu müssen auch Firmen, die bisher nur geringe Software-Kompetenz hatten, sich eigentlich als Software-Haus neu erfinden.