Synthese komponentenbasierter Konfigurationen Alexander Stuckenholz Lehrgebiet Datenverarbeitungstechnik FernUniversit¨at in Hagen [email protected] Abstract: Der Aufwand und somit die Kosten f¨ur die Wartung komponentenbasierter Softwarearchitekturen werden traditionell untersch¨atzt. Inkompatibilit¨aten sind bei ungeplanter Softwareevolution an der Tagesordnung. Klassische Verfahren zur Untersuchung von Austauschbarkeit und Integrationstests stoßen jedoch schnell an ihre Grenzen. Es werden daher im Folgenden Verfahren vorgestellt, die in der Lage sind, Konfigurationsvorschl¨age automatisiert zu generieren und somit einen globalen Blick auf Systemkonfigurationen und ihre Evolution erlauben.

1 Motivation Software unterliegt einem Alterungsprozess. Dieser wird zwar nicht durch den Verfall ¨ von Bits und Bytes hervorgerufen, sondern durch die schnelle Anderung von Rahmenbedingungen (Plattformen und Kommunikationsstrukturen) und wechselnde Anforderungen an die Softwaresysteme. Software, die vor 25 Jahren eine Aufgabe perfekt l¨osen konnte, w¨urde dies zwar heute auch noch tun, allerdings ist die Wahrscheinlichkeit gering, die notwendige Systemumgebung (Compiler, Betriebssystem, Hardware) daf¨ur zur Verf¨ugung stellen zu k¨onnen [Par94]. Das Allheilmittel der Softwareindustrie gegen den Alterungsprozess von Softwaresystemen liegt darin, auch nach der Fertigstellung der Systeme Updates zu produzieren und ¨ so im Nachhinein Software an gegebene Anderungen anzupassen. Der Aufwand f¨ur die Wartung und die Kosten, die in der Wartungsphase eines Softwareentwicklungsprojektes anfallen, werden allerdings traditionell untersch¨atzt. Untersuchungen zeigen, dass bis zu zwei Dritteln der Gesamtkosten in der Wartungsphase eines Entwicklungsprojektes anfallen [Boe81, WPC00]. Zudem ergeben sich zum Teil g¨anzlich neue Anforderungen f¨ur die Wartung von komponentenbasierten Softwarearchitekturen, so dass bew¨ahrte Verfahren ¨ wie die Analyse der Auswirkungen von Anderungen (engl. impact analysis) und Integrationstests nur bedingt erfolgreich angewendet werden k¨onnen. Voas formuliert dies in [Voa98] sehr treffend: Although maintaining unfamiliar code is a common maintenance dilemma, maintaining systems filled with black boxes adds a new level of difficulty.

195

1.1 Never run a changing system! ¨ Die Probleme, die durch nachtr¨agliche Anderungen in Form von Komponentenupdates entstehen k¨onnen, sind vielf¨altig: H¨aufig f¨uhren sog. interface refactorings dazu, dass Schnittstellen nicht mehr zusammenpassen, Methodenaufufe ins Leere f¨uhren und ben¨otigte Dienste versagen [Dig05]. Aber auch auf h¨oheren Vertragsebenen f¨uhren ver¨anderte Vor- oder Nachbedingungen, neue Protokoll- und Synchronisationsbedingungen mitunter zu Inkompatibilit¨aten. Um Inkompatibilit¨at im Vorfeld auszuschließen, werden in der Regel Austauschbarkeitsuntersuchungen angestrengt, die mehr oder weniger viele Vertragsebenen in die Untersuchungen mit einbeziehen. Dabei ist es das Ziel, festzustellen, ob eine neue Version einer Komponente einen Subtyp zu einer im Betrieb befindlichen Komponente darstellt. Eine ¨ Ubersicht u¨ ber derartige Mechanismen gibt [Stu05]. Wie die Marktforschung in [Stu06] zeigt, handelt es sich allerdings bei gut einem Drittel der untersuchten Updates kommerzieller Softwarekomponenten um sog. Major-Releases, bei denen wahrscheinlich keine Abw¨artskompatibilit¨at zu einer Vorversion mehr gegeben ist. Aufgrund neuer Abh¨angigkeiten und fehlender oder ge¨anderter Schnittstellen muss also mit Schwierigkeiten bei der Integration solcher Komponenten in ein Softwaresystem gerechnet werden. Austauschbarkeitsuntersuchungen k¨onnen zwar den Quell der Inkompatibilit¨at feststellen, tragen aber ansonsten nicht zur L¨osung des Problems, der Konstruktion eines ausgewogen konfigurierten Systems, bei.

1.2

Automatische Systemsynthese

Eine L¨osung stellt die automatische Systemsynthese dar. Basierend auf der Annahme, dass u¨ ber die Zeit hinweg eine große Menge an Softwarekomponenten zur Verf¨ugung steht, kann ein automatisiertes Verfahren durch geschickte Kombination der Komponenten zu einer ausgewogenen, also fehlerfreien, Konfiguration gelangen. Dabei werden Abh¨angigkeiten aufgel¨ost, fehlende Komponenten nachinstalliert oder zumindest ein Konfigurationsvorschlag generiert, der das Ziel, die sonst inkompatiblen Komponenten zu integrieren, weitestgehend erreicht. Dar¨uber hinaus k¨onnen Nebenbedingungen formuliert werden, die die Anzahl der verwendeten Komponenten minimiert, das System auf dem aktuellsten Stand h¨alt oder die Verteilungsstruktur optimiert. Die Leistungsf¨ahigkeit eines solchen Ansatzes kann im Bereich der Linux-Betriebssysteme wie Debian oder Suse Linux begutachtet werden. Dort existieren seit Jahren entsprechende Paketverwaltungsverfahren, um Konfigurationen aktuell und valide zu halten [Bai97]. Da im Open-Source-Bereich die Evolutionsgeschwindigkeit der Softwaresysteme weit h¨oher ist als in den u¨ brigen Bereichen, spielen derartige Mechanismen dort eine besondere Rolle [BP03]. Trotz dieser Ans¨atze bleibt das Mittel der automatischen Systemsynthese weitestgehend unerforscht. Neben [DDL+ 06] existieren kaum wissenschaftliche Arbeiten in diesem Bereich, welche die M¨oglichkeiten dieser Methode analysieren oder auf neue Anwendungs-

196

felder u¨ bertragen.

2

Boolesche Systemsynthese

In [SO06] wird das Problem der Synthese komponentenbasierter Softwarekonfigurationen als boolesches Optimierungsproblem formuliert. F¨ur jede zur Verf¨ugung stehende Komponentenversion wird dabei eine Entscheidungsvariable vorgesehen, die am Ende eines Suchprozesses entweder den Wert 1 (Komponentenversion ist Teil der Konfiguration) oder den Wert 0 (die Komponentenversion ist nicht Teil der Konfiguration) annehmen kann. Außerdem werden Nebenbedingungen formuliert, die zu einem ausgewogenen, aktuellen und in der Anzahl verwendeter Komponenten minimalen System f¨uhren sollen. Beginnend mit einer kleinen Menge von zu integrierenden Komponentenversionen wird mit Hilfe der linearen Relaxation des Optimierungsproblems und des Branch-and-BoundAlgorithmus entsprechend der Nebenbedingungen eine Konfiguration erzeugt. Sofern eine L¨osung existiert, kann diese nach einer endlichen Anzahl von Iterationsschritten erzeugt werden. Wie [Sch90, S. 360-363] zeigt, garantiert das Verfahren zudem, die global optimale Konfiguration aufzufinden. Die boolesche Systemsynthese wurde in einem prototypischen Werkzeug namens Componentor zur Administration komponentenbasierter Softwaresysteme implementiert und in einer Fallstudie evaluiert. Trotz der guten Ergebnisse bez¨uglich der gefundenen Systemkonfigurationen zeigten sich im Alltag einige Nachteile dieses Ansatzes. Bevor die boolesche Suche mit der Konstruktion einer Systemkonfiguration beginnen kann, m¨ussen mit Hilfe von Signaturvergleichen alle Komponentenabh¨angigkeiten aufgel¨ost werden. Die errechneten Abh¨angigkeiten bilden dann die Wissensbasis der booleschen Suche. Dieser Prozess ist immer dann durchzuf¨uhren, wenn eine neue Komponentenversion im Repository ver¨offentlicht wird, also bei jedem Komponentenupdate. Diese Arbeit ist sehr zeitaufw¨andig, da jede exportierte Schnittstellensignatur mit jeder importierten Signatur abgeglichen werden muss. Die boolesche Systemsynthese selbst ist, wegen der Evaluierung des gesamten Suchraums, eher unperformant und skaliert, im Vergleich zur Anzahl ber¨ucksichtigter Abh¨angigkeiten und der Anzahl von Komponentenversionen, vergleichsweise schlecht [Stu07, S. 159-183]. Das Verfahren ist daher ungeeignet, in einem reaktiven System zur online-Konstruktion von Systemkonfigurationen eingesetzt zu werden, bietet aber eine wertvolle Vergleichsm¨oglichkeit bei der Konstruktion eines performanteren Verfahrens.

3 Heuristische Systemsynthese Die Erfahrungen und das dom¨anenspezifische Wissen, das in der praktischen Anwendung der booleschen Systemsynthese gewonnen werden konnte, wurde anschließend erfolgreich in der Konstruktion eines heuristischen Verfahrens angewandt.

197

Abbildung 1: Regelkreis der heuristischen Systemsynthese.

Das resultierende heuristische Verfahren besteht aus einem zweistufigen Regelkreis, aus einem konstruktiven und einem verbessernden Teil (siehe Abbildung 1). Die erste Stufe basiert auf einem Greedy-Algorithmus, welcher beginnend mit einer oder mehreren Komponentenversionen anhand von Signaturabgleichen versucht, eine Konfiguration zu erzeugen, in der zu jeder importierten Schnittstelle eine gleichnamige exportierte Schnittstelle vorhanden ist. Dabei werden m¨oglichst aktuelle Komponentenversionen herangezogen. Die zweite Stufe des Verfahrens basiert auf einer lokalen Suche. Nach einer Bewertung der aus der ersten Stufe resultierenden Konfiguration werden einzelne Komponentenversionen so lange gegen a¨ ltere Versionen getauscht, bis die Anzahl der Konfigurationsfehler minimiert ist. Sollten bei dieser Tauschung neue Abh¨angigkeiten hinzukommen, wird wieder die erste Stufe der Suche herangezogen. Abbildung 2 zeigt das Verhalten der booleschen und der heuristischen Systemsynthese im Vergleich. Dabei wird der Wert der Zielfunktion des Optimierungsproblems in jedem Iterationsschritt einer beispielhaften Suche der Fallstudie dargestellt. Es ist deutlich erkennbar, dass die heuristische Suche den Zielwert auf fast direktem Weg erreicht. Die boolesche Suche hingegen erzeugt durch das Verwerfen einzelner Suchpfade mit Hilfe des Branch-and-Bound-Algorithmus einen s¨agezahn¨anlichen Funktionsverlauf.

4 Fallstudie In einer Fallstudie konnten wichtige Erkenntnisse f¨ur die praktische Anwendbarkeit der Verfahren gesammelt werden. Hierzu wurde das Administrationswerkzeug Componentor, das beide Verfahren realisiert, in dem Open-Source-Projekt Calimero.CMS1 u¨ ber einen Zeitraum von u¨ ber einem Jahr eingesetzt. Hierf¨ur musste jedoch der PHP-Quellcode ¨ mit Hilfe spezieller Javadoc-Anweisunder dort eingesetzten PEAR-Komponenten [M05] gen mit Typinformationen angereichert werden, so dass ein automatisierter Schnittstellenabgleich erst erm¨oglicht wurde. Die damit verbundene Mehrarbeit der Entwickler wurde aber durch den Umstand kompensiert, dass durch die Bewertung einer Konfiguration mit Hilfe des Schnittstellenabgleiches Fehler aufgedeckt werden konnten, die sonst erst zur Laufzeit aufgetreten w¨aren. Bei der Anwendung der Syntheseverfahren im Falle von Komponentenupdates zeigte sich, 1 http://www.calimero-cms.de

198

Abbildung 2: Verhalten der beiden Syntheseverfahren w¨ahrend der Suche.

dass das heuristische Verfahren sowohl sehr viel performanter ist, und zudem bezogen auf den Wert der Zielfunktion nur geringf¨ugig schlechtere Ergebnisse als die boolesche Systemsynthese erzielen konnte. Das heuristische Verfahren eignet sich daher sehr viel eher f¨ur die Anwendung in einem Administrationswerkzeug. Die Extraktion der Schnittstellenspezifikationen wurde in der Fallstudie immer dann au¨ tomatisch angestoßen, wenn Anderungen am Quellcode einer Komponente im Versionierungssystem, in diesem Fall Subversion, ver¨offentlicht wurden. Dies erm¨oglichte die sanfte Integration der Verfahren in den Entwicklungsprozess. Zudem wurden f¨ur sog. NightlyBuilds die Konfigurationsvorschl¨age der Syntheseverfahren herangezogen. Durch den Einsatz der Systemsynthese konnten sonst langwierige und personalintensive Integrationstests reduziert oder ganz vermieden werden. Konnte die Systemsynthese keine ausgewogene Konfiguration erzeugen oder entsprach die erzeugte Konfiguration nicht den Erwartungen, so deutete dies auf einen Fehler in der Implementierung einer oder mehrerer Komponenten hin. Fehler konnten dadurch automatisch lokalisiert und anschließend behoben werden.

5 Fazit Die Systemsynthese stellt, quasi aus der Vogelperspektive, eine globale Sicht auf komponentenbasierte Softwaresysteme und ihre Evolution zur Verf¨ugung. Neben der Bewertung gegebener Konfigurationen ist vor allem die automatisierte Generierung von Konfigurati-

199

onsvorschl¨agen ein Argument f¨ur diesen Ansatz. Durch die Reduktion von Integrationstests, die fr¨uhe Entdeckung von Fehlerquellen und das Aufzeigen von Konfigurationsalternativen sinken die Wartungskosten drastisch. Die Systemsynthese kann somit einen wichtigen Beitrag zur sicheren Softwareevolution und der Qualit¨atssicherung in komponentenbasierten Softwareprojekten leisten.

Literatur [Bai97]

Edward C. Bailey. Maximum RPM. Sams, 1997.

[Boe81]

Barry Boehm. Software Engineering Economics. Prentice Hall, 1981.

[BP03]

Andreas Bauer und Markus Pizka. The Contribution of Free Software to Software Evolution. In Proceedings of the International Workshop on Principles of Software Evolution (IWPSE), Helsinki, Finland, 2003. IEEE Computer Society.

[DDL+ 06] Roberto Di Cosmo, Berke Durak, Xavier Leroy, Fabio Mancinelli und J´erˆome Vouillon. Maintaining large software distributions: new challenges from the FOSS era. In Proceedings of the FRCSS 2006 workshop, 2006. [Dig05]

Danny Dig. Using refactorings to automatically update component-based applications. In OOPSLA ’05: Companion to the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, Seiten 228–230, New York, NY, USA, 2005. ACM Press.

¨ [M05]

Carsten M¨ohrke. PHP PEAR - Anwendung und Entwicklung - PEAR und PECL zur PHP-Programmierung nutzen. Galileo Press, 2005.

[Par94]

David Lorge Parnas. Software aging. In ICSE ’94: Proceedings of the 16th international conference on Software engineering, Seiten 279–287, Los Alamitos, CA, USA, 1994. IEEE Computer Society Press.

[Sch90]

Alexandeer Schrijver. Theory of linear and integer programming. John Wiley & Sons, Inc., New York, NY, USA, 1990.

[SO06]

Alexander Stuckenholz und Andre Osterloh. Safe component updates. In GPCE, Seiten 39–48, 2006.

[Stu05]

Alexander Stuckenholz. Component Evolution and Versioning - State of the Art. SIGSOFT Softw. Eng. Notes, 30(1):7, January 2005.

[Stu06]

Alexander Stuckenholz. Softwarekomponenten und ihre Update-Zyklen: Eine Marktanalyse. Praxis der Information und Kommunikation, 29(2):92–99, 2006.

[Stu07]

Alexander Stuckenholz. Sichere Komponentenupdates. Dissertation, FernUniversit¨at in Hagen, 2007. Noch nicht ver¨offentlicht.

[Voa98]

Jeffrey Voas. Maintaining Component-Based Systems. IEEE Softw., 15(4):22–27, 1998.

[WPC00]

Ye Wu, Dai Pan und Mei-Hwa Chen. Techniques of Maintaining Evolving ComponentBased Software. International Conference on Software Maintenance (ICSM’00), 00:236, 2000.

200