Eingebettete Software-Systeme sind heute allgegenwärtig und müssen zukünftig auch in Hinblick auf eine stetig steigende Lebensdauer und Wartbarkeit entworfen werden. Entsprechend müssen diese Systeme zunehmend evolvierbar sein, d.h. sowohl Fähigkeiten zur situationsbedingten Adaption im Betrieb aufweisen, als auch flexibel an sich ändernde Anforderungen anpassbar sein. Um die Komplexität von Auswirkungen von Anpassungen an diesen Systemen beherrschbar zu halten und Erosionseffekte zu verhindern, sind abstrahierende Architektur-Modelle eine wesentliche Grundlage für die Planung und strukturierte Durchführung von Änderungen im gesamten Lebenszyklus. Gleichzeitig kann durch Evolutions-begleitende Architektur-Evaluationen die nachhaltige Erfüllung von Qualitätskriterien wie Echtzeiteigenschaften, Sicherheit und Verfügbarkeit sichergestellt werden. Wir beschreiben die Einbettung von Maßnahmen zur fortgesetzten Qualitätssicherung in einen koevolutionären Betriebs-und Wartungsprozess und die hierfür erforderliche Konsistenz der Architektur-Spezifikation mit dem laufenden System. Der Ansatz wird anhand einer Fallstudie, einer adaptiven Robotersteuerung mit harten Echtzeitanforderungen, illustriert.
1 Einf ührung 1.1 Architekturen evolvierender Systeme Die Software ist der zunehmend kritische Faktor für den Erfolg eingebetteter Systeme. Dabei entsteht ein steigender Anteil der Aufwände und Kosten für derartige Systeme durch Wartungs-, Anpassungs-und Weiterentwicklungstätigkeiten, also der Evolution der Software [EGG + 09, Mas07], die gerade bei eingebetteten Systemen von der Umgebung und dem Anwendungskontext geradezu erzwungen wird [Leh96,Par94].
Der Architektur einer Software kommt zukünftig eine entscheidende Rolle zu, damit ein Software-System evolvierbar ist und bleibt. Dies gilt sowohl für kleinere Anpassungen wie Refactorings [RH06] oder dem Austausch von Komponenten, als auch für " revolutionäre" Eingriffe, angefangen beim kompletten Reengineering von (Teil-) Systemen bis hin zur Migration ganzer Systeme auf neue Plattformen [Mas07]. Darüber hinaus müssen moderne Systeme zunehmend adaptiv sein, d.h. sich selbständig zur Laufzeit strategisch an neue Bedingungen anpassen können [SG07,SGM09]. Um die Komplexität der Evolution zukünftiger Systeme beherrschbar zu halten, muss bereits im Rahmen des Ent-wurfs und der Modellierung die Anpassbarkeit als Kriterium bzw. Eigenschaft explizit berücksichtigt werden. Dies kann nicht allein durch den Einsatz moderner Technologien und Paradigmen und der damit verbundenen "Verheißungen", wie z.B. dem Einsatz Service-orientierter Entwurfsprinzipien, erzielt werden. Vielmehr sind neben Domänenspezifischen Lösungsmustern vor allem übergeordnete Prinzipien einer modularen, konfigurierbaren Architektur-Konzeption wesentlich für eine flexible Anpassbarkeit [BCK03].
Gerade an eingebettete Systeme werden aber auch weitere Qualitätsanforderungen gestellt, wie z.B. Sicherheit, Verfügbarkeit und Echtzeitfähigkeit. Im Kontext kontinuierlicher Evolution besteht somit auch die Notwendigkeit, ein fortlaufendes Qualitätsmanagement begleitend zum gesamten Lebenszyklus zu definieren. Dennoch können nicht alle erdenklichen zukünftigen Richtungen möglicher Weiterentwicklungen und Anpassungen beim Entwurf von System-Architekturen antizipiert werden [EGG + 09]. Gerade für Systeme, die sich durch eine besonders hohe Langlebigkeit auszeichnen, können zukünftige, Lebenszyklus-übergreifende Entwicklungen nur schwer abgeschätzt werden, wie z.B. sich ändernde Anforderungen, Erosionen in der Umgebung oder der technischen Infrastruktur sowie die Portierung auf andere Plattformen. Methodiken zur planvollen Evolution von Software-Systemen, die auf strukturierten, Architektur-basierten Vorgehensweisen beruhen, müssen geeignete Dokumentationsansätze für die Nachverfolgbarkeit unternommener Anpassungen beinhalten. Dabei muss nicht nur die korrekte Funktionsfähigkeit des Systems gewährleistet bleiben, sondern gleichzeitig die Sicherung weiterer Qualitätseigenschaften im Betrieb möglich bleiben. Schädigung" (Erosion) der Architektur. Die so kontinuierlich anwachsende Entropie der Systeme führt dann unter anderem zu abnehmender Wartbarkeit und Performanz [Mas07]. Zudem werden durch diese "
Wucherungen" die Abgrenzungen des Systems zur Umgebung zunehmend unklar.
Der Architektur-Entwurf ist das Bindeglied zwischen der Anforderungsanalyse und dem technischen Design, auf dessen Grundlage neben der korrekten Implementierung der geforderten Funktionalität zugleich Maßnahmen zur Qualitätssicherung in den Entwurfsprozess integrieren werden können [FGB + 07, LMD + 09, LMS + 09].
Die Kenntnis der Architektur eines Systems ist Grundvoraussetzung für ein tiefer gehendes Verständnis der internen Systemstrukturen zur Analyse und Evolutionsplanung. Für langlebige Systeme mit hohen Anteilen an Legacy-Komponenten liegen allerdings häufig nur unvollständige bzw. inkonsistente Architektur-Modelle vor, in denen Änderungen am System häufig nicht adäquat dokumentiert wurden. Zudem beinhalten Spezifikationen oftmals nur für die Qualitätsbewertung unzureichende statische Aspekte der Systemstruktur. Es gibt eine Vielzahl von Ansätzen, um für ein bestehendes System Architektur-Eigenschaften zu rekonstruieren, über die nachfolgend ein kurzer Überblick gegeben werden soll. Rekonstruktion und Extraktion eignen sich vor allem zur Ermittlung statischer Aspekte und Strukturen. In Kombination mit Monitoring-Ansätzen können diese um dynamische Eigenschaften ergänzt werden. In erster Näherung ergeben die genannten Verfahren zunächst konkrete Architektur-Sichten, der Übergang zu einem konzeptionellen Modell bedarf anschließend weiterer Abstraktionsschritte.
Die Integration der beschriebenen Verfahren erfordert Vorgehensmodelle, die den gesamten Lebenszyklus eingebetteter Systeme vom initialen Entwurf, der Implementierung und Inbetriebnahme, bis zur Wartung und Anpassung im Betrieb, umfassen. Die Konsistenzsicherung zwischen Anforderungsspezifikation, Architektur-Modell und Systemimplementierung verlangt einen umfassenden Ansatz zur Koevolution, d.h. der fortgesetzten Synchronisation des laufenden Systems und der Spezifikation. Neben der Planung und Dokumentation möglicher Evolutionen kann so gleichzeitig die Sicherung der geforderten Qualitätseigenschaften auf Grundlage der aktuellen Architektur-Ausprägung erfolgen. Der prinzipielle Aufbau eines entsprechend zyklischen Vorgehensmodells ist in Abbildung 3 skizziert. Das dargestellte Roundtrip Engineering ist notwendig, um die beiderseitige Synchronisation zwischen Spezifikation und laufendem System sicherzustellen, da (1) Erosionen im laufenden System Anpassungen an der Architektur-Spezifikation erzwingen, und (2) Änderungen der Anforderungen Anpassungen am laufenden System erzwingen. In beiden Fällen bildet die Architektur-Spezifikation die "
Brücke" zwischen Anforderungen und Implementierung: (1) als Entwurf der initialen (konzeptionellen) Systemstruktur, (2) zur modellbasierten Repräsentation der wesentlichen Aspekte des (konkreten) Systemzustandes, und damit (3) als Grundlage für die Planung, Durchführung und Dokumentation von Anpassungen und Adaptionen. Sowohl beim ersten Entwurf, als auch bei der fortgesetzten Evolution der System-Architektur kann die Sicherstellung geforderter Qualitätseigenschaften durch wiederholte Architektur-Evaluation erfolgen.
Abbildung 3: Koevolution im gesamten Lebenszyklus Grundlage bzw. Auslöser von Anpassungen sind sich stetig ändernde Anforderungen an das System bezüglich: (1) der Funktionalität, (2) der (technischen) Plattform, wozu prinzipiell auch die Systemumgebung gezählt werden kann sowie (3) Qualitätsanforderungen. Die Planung dieser Anpassungen auf Grundlage evolvierender Architekturen kann sowohl anhand der konkreten, als auch der konzeptionellen Architektur erfolgen. Erstere kann insbesondere für " leichtgewichtige" Adaptionen, wie z.B. der Prozessmigration von Bedeutung sein, wohingegegen das konzeptionelle Architektur-Modell für die Planung von Umstrukturierungen größeren Umfangs, wie z.B. der Integration neuer Komponenten, dienen kann. In diesem Zusammenhang kann bereits im Vorfeld sowie Evolutions-begleitend durch das Qualitätskriterium "
Modifzierbarkeit" [BCK03] die Architektur auf potenzielle Anpassungsszenarien hin ausgelegt und bewertet werden. Neben der globalen Koevolution zwischen Anforderungen, Architektur-Modellen und der Implementierung, besteht auch die Notwendigkeit, die Konsistenz von konkreter und konzeptioneller Architektur sicherzustellen. Die konkrete Architektur ergibt sich als Snapshot aus Systemzustand und Laufzeitartefakten im betrachteten Betriebszeitpunkt und kann, wie in Abschnitt 2.2.3 beschriebenen, ermittelt werden. Ergibt sich für die so ermittelte konkrete Architektur zu einem bestimmten Zeitpunkt, dass sie z.B. durch eine Folge von Adaptionen strukturell zu weit von der konzeptionellen Architektur entfernt ist und nicht mehr als dessen Ausprägung gelten kann, ist auch eine Evolution, d.h. Rekonstruktion der konzeptionellen Architektur notwendig. Umgekehrt führt die Planung von Evolutionen auf Grundlage der konzeptionellen Architektur zu einer Diskrepanz mit der konkreten Architektur, die gerade die für diese Anpassungen notwendigen Änderungen im laufenden System impliziert. In beiden Fällen können die aktualisierten Architektur-Modelle zur erneuten Architektur-Evaluation und somit fortlaufenden Qualitätssicherung verwendet werden, bzw. als Entscheidungsgrundlage in den Planungsprozess von Anpassungen und Adaptionen einbezogen und durch Monitoring-Ansätze ergänzt werden. Die laufenden Anpassungen der Implementierung können je nach Grad der hieraus entstehenden Evolution zu unterschiedlich stark ausgeprägten Erosionen der konkreten, und schließlich auch der konzeptionellen Architektur führen. Diese "
Versionssprünge" stellen die wesentlichen Bezugspunkte bei der Dokumentation der Evolutionsgeschichte für das Änderungs-, Anforderungs-und Qualitätsmanagement langlebiger Systeme dar. Somit sind Architektur-Entscheidungen als Bestandteil der Versionsverwaltung und des Requirements Tracing mitsamt der Evaluationsstruktur für die Qualitätskriterien nachverfolgbar und können auch als Anhaltspunkte für spätere Anpassungen erneut herangezogen werden. Vor der Durchführung von Änderungen am System sind neben der Überprüfung von Qualitätskriterien auch entsprechende Techniken zum Erhalt der funktionalen Korrektheit einzusetzen, wie beispielsweise die Kombination kontinuierlicher Refactorings und Tests aus dem Bereich der agilen Methoden [RH06]. Für eine nähere Diskussion der in diesem Bereich bestehenden Probleme und Herausforderungen verweisen wir u.a. auf [RB02]. Literatur