Eingebettete Software-Systeme sind heute allgegenw a¨rtig und mu¨ssen zuku¨nftig auch in Hinblick auf eine stetig steigende Lebensdauer und Wartbarkeit entworfen werden. Entsprechend mu¨ssen diese Systeme zunehmend evolvierbar sein, d.h. sowohl Fa¨higkeiten zur situationsbedingten Adaption im Betrieb aufweisen, als auch flexibel an sich a¨ndernde Anforderungen anpassbar sein. Um die Komplexita¨t von Auswirkungen von Anpassungen an diesen Systemen beherrschbar zu halten und Erosionseffekte zu verhindern, sind abstrahierende Architektur-Modelle eine wesentliche Grundlage fu¨r die Planung und strukturierte Durchfu¨hrung von A¨ nderungen im gesamten Lebenszyklus. Gleichzeitig kann durch Evolutions-begleitende ArchitekturEvaluationen die nachhaltige Erfu¨llung von Qualita¨tskriterien wie Echtzeiteigenschaften, Sicherheit und Verfu¨gbarkeit sichergestellt werden. Wir beschreiben die Einbettung von Maßnahmen zur fortgesetzten Qualita¨tssicherung in einen koevolutiona¨ren Betriebs- und Wartungsprozess und die hierf u¨r erforderliche Konsistenz der ArchitekturSpezifikation mit dem laufenden System. Der Ansatz wird anhand einer Fallstudie, einer adaptiven Robotersteuerung mit harten Echtzeitanforderungen, illustriert.
1.1
Der Architektur einer Software kommt zuku¨nftig eine entscheidende Rolle zu, damit ein Software-System evolvierbar ist und bleibt. Dies gilt sowohl f u¨r kleinere Anpassungen wie Refactorings [RH06] oder dem Austausch von Komponenten, als auch fu¨r revolu” tiona¨re“ Eingriffe, angefangen beim kompletten Reengineering von (Teil-) Systemen bis hin zur Migration ganzer Systeme auf neue Plattformen [Mas07]. Daru¨ber hinaus mu¨ssen moderne Systeme zunehmend adaptiv sein, d.h. sich selbsta¨ndig zur Laufzeit strategisch an neue Bedingungen anpassen ko¨nnen [SG07, SGM09]. Um die Komplexita¨t der Evolution zuku¨nftiger Systeme beherrschbar zu halten, muss bereits im Rahmen des Entwurfs und der Modellierung die Anpassbarkeit als Kriterium bzw. Eigenschaft explizit beru¨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 a¨nenspezifischen Lo¨sungsmustern vor allem u¨bergeordnete Prinzipien einer modularen, konfigurierbaren Architektur-Konzeption wesentlich f u¨r eine flexible Anpassbarkeit [BCK03]. Gerade an eingebettete Systeme werden aber auch weitere Qualita¨tsanforderungen gestellt, wie z.B. Sicherheit, Verfu¨gbarkeit und Echtzeitfa¨higkeit. Im Kontext kontinuierlicher Evolution besteht somit auch die Notwendigkeit, ein fortlaufendes Qualita¨tsmanagement begleitend zum gesamten Lebenszyklus zu definieren. Dennoch ko¨nnen nicht alle erdenklichen zuku¨nftigen Richtungen mo¨glicher Weiterentwicklungen und Anpassungen beim Entwurf von System-Architekturen antizipiert werden [EGG +09]. Gerade fu¨r Systeme, die sich durch eine besonders hohe Langlebigkeit auszeichnen, ko¨nnen zuku¨nftige, Lebenszyklus- u¨bergreifende Entwicklungen nur schwer abgescha¨tzt werden, wie z.B. sich a¨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, mu¨ssen geeignete Dokumentationsansa¨tze fu¨r die Nachverfolgbarkeit unternommener Anpassungen beinhalten. Dabei muss nicht nur die korrekte Funktionsfa¨higkeit des Systems gewa¨hrleistet bleiben, sondern gleichzeitig die Sicherung weiterer Qualita¨tseigenschaften im Betrieb mo¨glich bleiben.
In diesem Beitrag beschreiben wir, inwieweit Architektur-Modelle nicht nur f u¨r den Entwurf und Implementierung sowie die Planung von Evolutionen eingebetteter Systeme von entscheidender Bedeutung sind, sondern auch die Grundlage fu¨r ein Lebenszyklusu¨bergreifendes Anforderungs- und Qualit a¨tsmanagement bilden ko¨nnen. Begleitend zur stetigen Anpassung des Systems kann durch modellbasierte Architektur-Evaluation eine fortlaufende Bewertung und Sicherung zu erfu¨llender Qualita¨tskriterien im Betrieb erfolgen. Die kontinuierliche Koevolution von Systemspezifikation und Systemimplementierung erfordert die Integration von Methodiken zur Ermittlung konkreter Architekturauspra¨gungen des laufenden Systems in den Wartungsprozess. Somit ko¨nnen Verfahren sowohl fu¨r die proaktive als auch reaktive Planung von Architektur-Entscheidungen und -Evolutionen unter Abw a¨gung aller relevanten Qualita¨tsziele etabliert werden. Zudem ko¨nnen Anpassungen geeignet dokumentiert und nachverfolgt werden, um die Auswirkungen unternommener Evolutionsschritte in nachfolgende Entscheidungen einfließen zu lassen. 1.2
Eine fru¨hzeitige Bewertung der zu erwartenden Qualita¨t eines Systems durch ArchitekturEvaluation [BCK03] ist ein unverzichtbarer Bestandteil des Entwurfsprozesses fu¨r eingebettete Systeme. Wie in [FGB+07] fu¨r den Anwendungsbereich automotiver Systeme beschrieben wurde, ermo¨glicht ein strukturierter Evaluationsansatz die Integration von Bewertungstechniken fu¨r sa¨mtliche Qualita¨tskriterien des zu entwickelnden Systems. Der
Abbildung 1: Evaluationsstruktur zur Architektur-Bewertung prinzipielle Aufbau einer Evaluationsstruktur ist exemplarisch in Abbildung 1 dargestellt, fu¨ r eine detaillierte Diskussion des Ansatzes verweisen auf [LMD+09, LMS+09]. Um zu einer Aussage u¨ ber die zu erwartende Gesamtqualita¨t des Systems auf Grundlage der Architektur zu gelangen, werden zuna¨chst die je nach Projektzielen relevanten Einzelkriterien durch geeignete Qualit a¨tsattribute charakterisiert und bewertet. Fu¨ r die konkrete Bewertung dieser Kriterien hinsichtlich einer Architektur-Variante werden einheitliche Bewertungstechniken, wie z.B. Metriken oder Expertenbefragungen, definiert. Gerade Metriken ko¨ nnen automatisiert auswertbar als integraler Bestandteil einer Komponente zur Anpassungsplanung implementiert werden k o¨nnen. Von besonderem Interesse fu¨ r langlebige Systeme sind Bewertungstechniken zur Modifizierbarkeit der Architektur, bestehend aus a priori festzulegenden Anpassungsszenarien. Um aus den Bewertungsregebnissen der Einzelkriterien eine Gesamtqualita¨t zu ermitteln, werden Qualit a¨tsraten zur Normalisierung definiert. Diese ordnen Bewertungsergebnissen je nach Projektzielen und Constraints, z.B. Kostenbudgets oder QoS, eine Gu¨ te als Prozentzahl zu. K.O.-Kriterien in Form von harten Grenzwerten fu¨ r Qualita¨tskriterien du¨ rfen dabei nicht verletzt werden, um die Realisierbarkeit nicht zu gefa¨hrden. Die Integration zu einer Gesamtqualita¨t erfolgt durch Hierarchisierung in Unter- und Oberkriterien mit entsprechenden Gewichtungen gem a¨ß der Priorita¨t der Qualita¨tsziele. Die Evaluationsstruktur kann dann zur Analyse, Optimierung und Dokumentation von Architektur-Varianten und -Entscheidungen dienen. Bisher wurde dieser Ansatz zur Bewertung konzeptioneller Architektur-Varianten begleitend zum Entwurf automotiver Steuergera¨tenetzwerke, also vor der Implementierung und dem Betrieb des Systems, betrachtet. F u¨r eingebettete Systeme mit evolutionsfa¨higen Architekturen wird zunehmend auch die Notwendigkeit bestehen, den Erhalt von Qualita¨tseigenschaften nicht nur initial, sondern auch begleitend zu den fortlaufenden A¨ nderungen im Betrieb sicherzustellen. 1.3
Fu¨ r die nachfolgenden U¨ berlegungen beziehen wir uns exemplarisch auf die ”Parallel RObot Software Architecture - eXtended“ (PROSA-X) [SG07] als Beispiel f u¨ r ein evolutionsfa¨higes, verteiltes eingebettetes System mit hohen Qualita¨tsanforderungen. Abb. 2 zeigt die Prosa-X-Architektur zur Integration der Steuerungsmodule von Parallelrobotern. Die Steuerung der verwendeten Parallelkinematiken muss mit hoher Pra¨zision erfolgen sowie harte Anforderungen bezu¨glich Echtzeit, Zuverla¨ssigkeit und Sicherheit erfu¨llen. Daru¨ber hinaus muss der Architektur-Aufbau flexible Anpassungen der Komponentenstruktur ermo¨glichen. Daru¨ber hinaus wurde das System um eine Self-Manager Komponente (Analyse-PC) zur Realisierung von Self*-Eigenschaften erweitert [SG07, SGM09]. Das System ist so in der Lage, ohne Eingriffe von außen adaptiv im Betrieb auf unterschiedliche Situationen, wie z.B. Knotenausfa¨lle auf der Hardware-Plattform, wenn mo¨glich unter Erhalt der Echtzeiteigenschaften zu reagieren. 2
2.1
Die Identifikation und Durchfu¨hrung notwendiger A¨ nderungsmaßnahmen an im Betrieb befindlichen (eingebetteten) Software-Systemen kann auf zwei Arten erfolgen: Methodische Anpassungen: Eingriffe ”von Hand“ als Teil der Systemwartung. Aufwand und Auswirkungen der Anpassungen variieren dabei von einfachen Rekonfigurationen oder dem Austausch von Komponenten, bis zu komplexen Umstrukturierungen der Gesamtarchitektur und dem Deployment. Ein sorgfa¨ltig strukturierter Architektur-Entwurf mit stabilen Komponentenschnittstellen und Konfigurationsparametern kann zur Anpassbarkeit von Systemen beitragen. Allerdings erho¨ht jede Maßnahme zur Auslegung auf potentielle A¨ nderungen zumeist die Komplexita¨t der Architektur. Zudem mu¨ssen gerade eingebettete Systeme trotz durchzufu¨hrender Anpassungen durchga¨ngig verfu¨gbar sein, was durch eine strategische Abfolge systematischer Anpassungsschritte erreicht werden kann.
Abbildung 2: Architektur PROSA-X f u¨r Robotersteuerungen Adaption: Die Fa¨higkeit des Systems, sich selbst zur Laufzeit durch geeignete Strategien an bestimmte Bedingungen oder Kontexte anzupassen, wie z.B. zur Kompensation ausfallender Systemressourcen hinsichtlich Verfu¨gbarkeits-, Sicherheits- und Echtzeitanforderungen. Die Implementierung adaptiven Verhaltens kann z.B. durch parametrisierbare Architektur-Artefakte, also der Spezifikation des A¨ nderungspotentials im ArchitekturModell erfolgen. Im Betrieb kann nun entweder bei Bedarf zwischen zuvor festgelegten Modi umgeschaltet, oder durch Online-Planung je nach Situation eine optimale Parametrisierung ermittelt werden.
Die in Abschnitt 1.3 beschriebene adaptive Architektur PROSA-X verf u¨gt u¨ber eine spezielle Komponente (Self-Manager ), die je nach Betriebszustand durch Rekonfiguration von Betriebsparametern Self*E-igenschaften realisiert [SG07].
Fu¨r beide Ansa¨tze sind Architektur-Modelle die Basis f u¨r die Planung und Durchfu¨hrung der A¨ nderungen. Gerade weil die Architektur das stabilste Element eines Software-Systems u¨ber den gesamten Lebenszyklus darstellen sollte, gelten Anpassungen an der Architektur aber als schwierig und kostspielig. Deshalb erfolgen Modifikationen am System ha¨ufig in nicht-optimaler Form, d.h. ohne die notwendige Evolution der Architektur, und f u¨hren gerade deshalb zur nachhaltigen ”Scha¨digung“ (Erosion) der Architektur. Die so kontinuierlich anwachsende Entropie der Systeme fu¨hrt dann unter anderem zu abnehmender Wartbarkeit und Performanz [Mas07]. Zudem werden durch diese ”Wucherungen“ die Abgrenzungen des Systems zur Umgebung zunehmend unklar. 2.2
Der Architektur-Entwurf ist das Bindeglied zwischen der Anforderungsanalyse und dem technischen Design, auf dessen Grundlage neben der korrekten Implementierung der geforderten Funktionalita¨t zugleich Maßnahmen zur Qualita¨tssicherung in den Entwurfsprozess integrieren werden ko¨nnen [FGB+07, LMD+09, LMS+09]. 2.2.1
Fu¨r Abstraktionskonzepte von Architektur-Spezifikationen, insbesondere zur strukturellen Dekomposition, existieren eine Vielzahl unterschiedlichster Modellierungsansa¨tze und Formalismen [RH06]. Wir beziehen uns vor allem auf Component-Connector-Modelle [BCK03], also die explizite Darstellung grundlegender, ha¨ufig rein logischer System-Artefakte und den Abha¨ngigkeiten zwischen diesen Elementen.
Eingebettete Systeme sind zunehmend Software-intensiv und realisieren Steuerungs- und Regelungsaufgaben durch Kommunikations-orientierte Integration verschiedenster, hochspezialisierter Komponenten auf ha¨ufig massiv verteilten und heterogen strukturierten Hardware-Plattformen. Standardisierte Schichtenarchitekturen erlauben eine flexible Verteilung von Software- und Hardware-Komponenten, sodass beliebige Architektur-Varianten bezu¨glich (Wieder-) Verwendung, Anordnung, Verteilung und Verkn u¨pfung dieser Komponenten mo¨glich sind und so großen Spielraum fu¨r Optimierungen bieten. Ein Problem bei der Entwicklung dieser Systeme besteht u.a. im konzeptionellen ”Bruch“ beim U¨ bergang von der abstrakten Architektur hin zur mo¨glichst effizienten, d.h. Hardware-nahen Implementierung der Einzelfunktionen. Fu¨r die gezielte Planung und Durchfu¨hrung von Evolutionen langlebiger eingebetteter Systeme bilden Architektur-Modelle eine wichtige Entscheidungsgrundlage, da sie nicht nur Abha¨ngigkeiten zwischen betroffenen Systemteilen aufzeigen, sondern auch durch Modularisierung gezielt die Austauschbarkeit von Teilkomponenten unterstu¨tzen.
Architektur-Entw u¨rfe konzentrieren sich in der Regel auf die Spezifikation statischer Strukturen, jedoch ist dies fu¨r weitergehende Zwecke, wie z.B. fu¨r Systemanalysen zur Anpassung bzw. Rekonfiguration, oft unzureichend, sodass deshalb eine Kombination mit Verhaltensmodellen notwendig ist [RB02]. Um zuku¨nftig beim Entwurf von System-Architekturen potenzielle Evolutionen bereits wa¨hrend der Entwicklung zu beru¨cksichtigen, muss die geplante Variabilita¨t des Systems explizit mitmodelliert werden. Derartige evolutionsfa¨hige Architekturen ko¨nnen dann als Grundlage fu¨r die Planung und Durchfu¨hrung von Evolutionsschritten und fu¨r die Dokumentation der Evolutionsgeschichte dienen und ermo¨glichen ein Variabilita¨tsmanagement vergleichbar mit den Konzepten der Produktlinien-Ans a¨tze [CN07]. Durch vordefinierte Variationspunkte werden mo¨gliche Freiheitsgrade fu¨r die Anpassbarkeit des Systems bereits als Teil des Architektur-Modells festgelegt. Je nach A¨ nderungsszenario kann die Evolution dann durch Anpassung betroffener Artefakte erfolgen, und das in sa¨mtlichen Phasen des Lebenszyklus. Hierfu¨r sind ArchitekturMetamodelle notwendig, die neben der Zuordnung von Variabilita¨tspunkten auch die Integration von zusa¨tzlichem Wissen u¨ber das System erlauben. Auf diese Weise kann sowohl auf A¨nderungen funktionaler, als auch nicht-funktionaler Anforderungen zielgerichtet reagiert werden. 2.2.2
Die Definition von Architektur-Sichten tra¨gt beim Entwurf von Architekturen eingebetteter Systeme maßgeblich zur U¨ bersichtlichkeit und Komplexita¨tsbeherrschung bei. Ausgehend von der doma¨nenspezifischen Anforderungsspezifikation (inkl. Qualita¨tskriterien) in der Applikationssicht ko¨nnen sowohl die hochspezialisierte, modularisierte Software in der Funktionsarchitektur-Sicht, als auch die anwendungsspezifische Hardware-Plattform (technische Sicht) zuna¨chst getrennt betrachtet werden, und erst im letzten Schritt durch mo¨glichst gu¨nstige Verteilung der Software-Komponenten auf vorhandene Recheneinheiten unter Beachtung des resultierenden Kommunikationsaufkommens flexibel in einer System-Architektur integriert werden. Analog zu [RB02] unterscheiden wir im Folgenden zudem zwischen Architektur-Sichten zur Spezifikations- und Laufzeit: Konzeptionelle Architektur: Die Spezifikation beschreibt abstrakte strukturelle Einheiten des Systems mitsamt ihren Abha¨ngigkeiten. Je nach Modellierungsansatz ko¨nnen konzeptionelle Architekturen unterschiedlichste Artefakte beinhalten. Beispielsweise kann die Struktur des Softwaresystems auf Grundlage einer Component-Connector-Abstraktion beschrieben und durch Schnittstellen- und Prozess-Definitionen verfeinert werden. Beim Entwurf adaptiver Systeme ko¨nnen zudem im Vorfeld gezielt Konfigurationsparameter eingeplant werden.
Konkrete Architektur: Zur Laufzeit repra¨sentieren die im System agierenden, operationellen Einheiten die aktuelle Architektur-Auspr a¨gung. Dazu geho¨ren Artefakte wie laufende Prozesse (Tasks), deren Kommunikation untereinander sowie Werte von Konfigurationsparametern. Diese Instanzen der Elemente der konzeptionellen Architektur variieren je nach Zustand des Systems im betrachteten Zeitpunkt.
Eine Divergenz zwischen konzeptioneller und konkreter Architektur ist in der Regel unvermeidbar. Spa¨testens im Betrieb ergeben sich Erosions-bedingte Inkonsistenzen, z.B. durch unzureichend dokumentierte Evolutionen. Daru¨ber hinaus ist insbesondere fu¨r Altsysteme in der Regel keine oder eine nur unvollsta¨ndige Spezifikation der Architektur vorhanden. Fu¨r eine strukturierte Planung von Architektur-Evolutionen ist somit eine Rekonstruktion der konzeptionellen Architektur auf Grundlage der durch die aktuelle Systemauspra¨gung gegebenen konkreten Architektur notwendig.
Auch fu¨r die Architektur-Evaluation k o¨nnen passende ArchitekturS-ichten definiert werden, die fu¨r die jeweiligen Bewertungstechniken relevanten Artefakte enthalten. Fu¨r die Modellierung evolvierender Architekturen ko¨nnen zudem Sichten definiert werden, die eine explizite Spezifikation von Variabilita¨tsparametern unterstu¨tzen. Fu¨r die Bewertung von Echtzeiteigenschaften in PROSA-X ist z.B. die Verteilung und Kommunikation von Prozessen im System von entscheidender Bedeutung, wobei eine Reihe von Randbedingungen zu beachten sind. Eine Sicht zur Planung und Bewertung von Prozessmigrationen repra¨sentiert diese Verteilungs- und Kommunikationsstruktur durch eine entsprechende Graphendarstellung [SGM09]. 2.2.3
Die Kenntnis der Architektur eines Systems ist Grundvoraussetzung fu¨r ein tiefer gehendes Versta¨ndnis der internen Systemstrukturen zur Analyse und Evolutionsplanung. Fu¨r langlebige Systeme mit hohen Anteilen an Legacy-Komponenten liegen allerdings h a¨ufig nur unvollsta¨ndige bzw. inkonsistente Architektur-Modelle vor, in denen A¨ nderungen am System ha¨ufig nicht ada¨quat dokumentiert wurden. Zudem beinhalten Spezifikationen oftmals nur fu¨r die Qualita¨tsbewertung unzureichende statische Aspekte der Systemstruktur. Es gibt eine Vielzahl von Ansa¨tzen, um fu¨r ein bestehendes System ArchitekturEigenschaften zu rekonstruieren, u¨ber die nachfolgend ein kurzer U¨ berblick gegeben werden soll.
Rekonstruktion: Durch ”heuristisches“ Reverse Engineering wird versucht, ho¨here Abstraktionsebenenen, wie z.B. Component-Connector-Strukturen und andere Pattern, aus dem Quellcode eines bestehenden Software-Systems ohne ad a¨quate Spezifikation zu ermitteln. Eine wesentliche Problematik besteht hier im ”mismatch“ zwischen abstrakten Architektur-Konzepten und den Artefakten von Programmiersprachen, also der Definition eines geeigneten correspondence model zwischen Code und Architektur-Modell. Bei der Hardware-nahen Programmierung eingebetteter Systeme gestaltet sich die Identifikation von High-Level-Komponenten als besonders schwierig. Ans a¨tze zum ArchitekturRecovery sind in der Regel nur (semi-) automatisierbar, bed u¨rfen also gefu¨hrter Entscheidungen von Expertenseite.
Extraktion: Eine Erweiterung der Rekonstruktionsansa¨tze basiert auf der Einbettung von Architektur-Modellen als Metawissen in den Programmcode, wodurch eine pra¨zisere Identifikation und Zuordnung von Architektur-Artefakten m o¨glich wird. Speziell objektorientierte Programmierparadigmen weisen eine enge konzeptionelle Verwandtschaft zu Komponenten-orientierten Architektur-Modellen auf. Die Einbettung von Verhaltensmodellen werden z.B.. [BSG09] und [SVB+03] beschrieben. Weiterhin ko¨nnen hier Programmierumgebungen mit Reflection-Funktionen angef u¨hrt werden, von denen zur Laufzeit Informationen u¨ber die eigene Programmstruktur abgefragt werden ko¨nnen. Monitoring: Fu¨r eine beliebig detaillierte Ermittlung von dynamischen Informationen ko¨nnen schließlich eigene Observer-Komponenten innerhalb des Systems zum Tracking von Laufzeitinformationen, z.B. dem Erstellen von Last- und Kommunikationsprofilen, verwendet werden, was insbesondere ein wesentlicher Bestandteil adaptiver Systeme ist. Auf dieser Grundlage ko¨nnen auch entsprechend aussagekra¨ftige Metriken zur Validierung vorhergehender Qualita¨tsbewertungen definiert werden.
Rekonstruktion und Extraktion eignen sich vor allem zur Ermittlung statischer Aspekte und Strukturen. In Kombination mit Monitoring-Ans a¨tzen ko¨nnen diese um dynamische Eigenschaften erga¨nzt werden. In erster Na¨herung ergeben die genannten Verfahren zuna¨chst konkrete Architektur-Sichten, der U¨ bergang zu einem konzeptionellen Modell bedarf anschließend weiterer Abstraktionsschritte. 2.3
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 mo¨glicher Evolutionen kann so gleichzeitig die Sicherung der geforderten Qualita¨tseigenschaften auf Grundlage der aktuellen Architektur-Auspr a¨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) A¨ nderungen der Anforderungen Anpassungen am laufenden System erzwingen. In beiden Fa¨llen bildet die Architektur-Spezifikation die ”Bru¨cke“ zwischen Anforderungen und Implementierung: (1) als Entwurf der initialen (konzeptionellen) Systemstruktur, (2) zur modellbasierten Repra¨sentation der wesentlichen Aspekte des (konkreten) Systemzustandes, und damit (3) als Grundlage fu¨r die Planung, Durchfu¨hrung und Dokumentation von Anpassungen und Adaptionen. Sowohl beim ersten Entwurf, als auch bei der fortgesetzten Evolution der System-Architektur kann die Sicherstellung geforderter Qualita¨tseigenschaften durch wiederholte Architektur-Evaluation erfolgen.
Abbildung 3: Koevolution im gesamten Lebenszyklus Grundlage bzw. Auslo¨ser von Anpassungen sind sich stetig a¨ndernde Anforderungen an das System bezu¨glich: (1) der Funktionalita¨t, (2) der (technischen) Plattform, wozu prinzipiell auch die Systemumgebung geza¨hlt werden kann sowie (3) Qualita¨tsanforderungen. Die Planung dieser Anpassungen auf Grundlage evolvierender Architekturen kann sowohl anhand der konkreten, als auch der konzeptionellen Architektur erfolgen. Erstere kann insbesondere fu¨r ”leichtgewichtige“ Adaptionen, wie z.B. der Prozessmigration von Bedeutung sein, wohingegegen das konzeptionelle Architektur-Modell f u¨r die Planung von Umstrukturierungen gro¨ßeren Umfangs, wie z.B. der Integration neuer Komponenten, dienen kann. In diesem Zusammenhang kann bereits im Vorfeld sowie Evolutions-begleitend durch das Qualita¨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 fu¨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 Auspra¨gung gelten kann, ist auch eine Evolution, d.h. Rekonstruktion der konzeptionellen Architektur notwendig. Umgekehrt fu¨hrt die Planung von Evolutionen auf Grundlage der konzeptionellen Architektur zu einer Diskrepanz mit der konkreten Architektur, die gerade die fu¨r diese Anpassungen notwendigen A¨ nderungen im laufenden System impliziert. In beiden Fa¨llen ko¨nnen die aktualisierten Architektur-Modelle zur erneuten ArchitekturEvaluation und somit fortlaufenden Qualita¨tssicherung verwendet werden, bzw. als Entscheidungsgrundlage in den Planungsprozess von Anpassungen und Adaptionen einbezogen und durch Monitoring-Ans a¨tze erga¨nzt werden. Die laufenden Anpassungen der Implementierung ko¨nnen je nach Grad der hieraus entstehenden Evolution zu unterschiedlich stark ausgepra¨gten Erosionen der konkreten, und schließlich auch der konzeptionellen Architektur fu¨hren. Diese ”Versionsspru¨nge“ stellen die wesentlichen Bezugspunkte bei der Dokumentation der Evolutionsgeschichte fu¨r das A¨nderungs-, Anforderungs- und Qualita¨tsmanagement langlebiger Systeme dar. Somit sind Architektur-Entscheidungen als Bestandteil der Versionsverwaltung und des Requirements Tracing mitsamt der Evaluationsstruktur fu¨r die Qualita¨tskriterien nachverfolgbar und ko¨nnen auch als Anhaltspunkte fu¨r spa¨tere Anpassungen erneut herangezogen werden. Vor der Durchfu¨hrung von A¨nderungen am System sind neben der U¨ berpru¨fung von Qualita¨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]. Fu¨r eine na¨here Diskussion der in diesem Bereich bestehenden Probleme und Herausforderungen verweisen wir u.a. auf [RB02].
Evolutionsfa¨hige Architekturen: Fu¨r die Planung, Durchfu¨hrung und Dokumentation von Lebenszyklus-belgeitenden Evolutionen auf Grundlage von Architektur-Modellen bedarf es entsprechender Ansa¨tze, die an dieser Stelle kurz skizziert werden sollen. Wie bereits in [EGG+09] diskutiert wurde, mu¨ssen potenzielle Evolutionen integraler Bestandteil der Systemspezifikation werden. Wissen u¨ber das System in Form von Konfigurationsparametern fu¨r Anpassungen, Annotationen zur Metrikauswertung sowie Instrumentierungen fu¨r das Monitoring des Laufzeitverhaltens mu¨ssen hierfu¨r als fester Besatandteil des Metamodells vorgesehen werden. Je nach Art und Umfeld des Systems ko¨nnen so entsprechende Profile fu¨r Anpassungsklassen definiert werden. Das in [Par94] propagierte Design for Change basiert beispielsweise auf der Definition von A¨ nderungsklassen, fu¨r die je nach Eintrittswahrscheinlichkeit einer A¨ nderung eine Auswirkungsanalyse fu¨r betroffene Artefakte und deren Isolation ermo¨glicht wird. Die eigentliche ”technische“ Durchfu¨hrung von Anpassungen ist von vielerlei Aspekten abha¨ngig [RH06] und kann sowohl durch eine Abfolge kleiner Einzelschritte, als auch in einen ”Big Bang“ erfolgen. So basieren beispielsweise Architektur-Refactorings auf konsistenzerhaltenden Transformationsvorschriften zwischen Artefakten des Architektur-Metamodells und entsprechender Pattern in der Implementierung. Bei der Migration ganzer (Teil-) Systeme sind hingegen vor allem Faktoren wie verwendete Schichten-Architekturen und VirtualisierungsKomponenten von Bedeutung.
Qualita¨tssicherung von Evolutionen: Obwohl fu¨r die Qualita¨tsbewertung bestehender evolvierender Systeme im Gegensatz zur Entwurfs-begleitenden Architektur-Evaluation prinzipiell sa¨mtliche Implementierungs- und Laufzeitdetails verf u¨gbar sind, bietet sich auch hier die Verwendung von schwerpunktma¨ßig auf Architektur-Abstraktionen basierender Bewertungstechniken an, um die Komplexita¨t nicht zu groß werden zu lassen. Bei der Weiterverwendung einer wa¨hrend der Entwurfsphase des Systems fu¨r die Qualita¨tsanforderungen definierten Evaluationsstruktur aus Abbildung 1 zur fortlaufenden U¨berpru¨fung der Qualita¨t evolvierender Systeme ergeben sich folgende Fragestellungen: 1. Welche Qualita¨tskriterien sind im Betrieb im Vergleich zur Entwurfsphase relevant? Kriterien, die harte Randbedingungen fu¨r den korrekten Betrieb des Systems darstellen, wie z.B. Sicherheit und Echtzeit, sind im gesamten Lebenszyklus einzuhalten. Kriterien, die schwerpunktma¨ßig fu¨r Entscheidungen wa¨hrend des Entwurfs von Bedeutung sind, wie z.B. Kosten, sind bei der Bewertung von Architektur-Evolutionen hingegen zweitrangig. Ein Spezialfall bilden Kriterien wie Modifzierbarkeit, die nicht nur fortlaufend evaluiert werden sollten, sondern insbesondere durch neue Modifikationsszenarien, die zum Zeitpunkt des Entwurfs noch gar nicht bekannt waren, erweitert werden ko¨nnen. Somit werden auch die Bestandteile der Evaluationsstruktur selbst eine stetige Evolution erfahren. 2. Welche Anpassungen werden an den Bewertungstechniken vorgenommen? Neben der konzeptionellen Architektur ko¨nnen nun auch Artefakte der konkreten Architektur sowie weitere Anreicherungen um Laufzeitinformationen durch Monitoring fu¨r die Pra¨zisierung der vormals nur auf Grundlage des Architektur-Entwurfs definierten Bewertungstechniken herangezogen werden. Zudem ko¨nnen Erfahrungswerte aus der Evolutionsgeschichte in die Bewertung einfließen.
Die methodische Integration der Architektur-Evaluation gem a¨ß Abbildung 3 kann auf zwei Arten erfolgen: (1) reaktiv, d.h. schon beim Entwurf des Systems werden fu¨r bestimmte Betriebsmodi feste Anpassungspla¨ne definiert und vor der Anwendung durch ArchitekturEvaluation ”abgesichert“, um so K.O.-Kriterien auszuschließen, oder (2) proaktiv, d.h. die Planung von Anpassungen erfolgt ”online“ und die Qualita¨tsattribute gehen als Planungsparameter in die Entscheidung ein, um einen mo¨glichst guten Trade-off zu ermitteln. Diese Planungen ko¨nnen als Reaktion auf A¨nderungen von (funktionalen) Anforderungen oder Laufzeitbedingungen erfolgen sowie zur Optimierung der Qualita¨tseigenschaften selbst. Der enge Zusammenhang zwischen Evolution und Evaluation wird vor allem an Kriterien wie Modifzierbarkeit deutlich: Diese sind einerseits Gegenstand der Bewertungsszenarien und zugleich Ziel der Anpassungen.
Durch das Einsatzgebiet von PROSAX werden hohe Anforderungen an die Sicherheit, Verfu¨gbarkeit, Performanz, etc. gestellt. Um insbesondere die Erfu¨llung harter Echtzeitanforderungen sicherzustellen, sind unter Umsta¨nden Anpassungen im laufenden Betrieb notwendig, z.B. bei A¨ nderungen an der Ausfu¨hrungsplattform (Knotenausfall) oder der Betriebslast (Prozessanzahl). In diesen Fa¨llen kann der Self-Manager zur Laufzeit eine neue Konfiguration durch Umverteilung von Prozessen auf Netz- Abbildung 4: Prozess-Migration in PROSA-X werkknoten ermitteln, um den Erhalt der Echtzeiteigenschaften weiterhin zu gewa¨hrleisten. Ein exemplarisches Adaptionsszenario ist in Abbildung 4 dargestellt. Die Planung der Umverteilung erfolgt auf Grundlage einer extrahierten, konkreten Architektur-Sicht, bestehend aus einem durch Monitoring ermittelten Kommunikationsgraphen der laufenden Prozesse. Durch eine Kombination verschiedener Heuristiken zur Graphpartitionierung wird eine mo¨glichst ausgewogene Neuverteilung der Prozesse auf vorhandene Knoten geplant (im Beispiel drei Kontroll-PCs), d.h. (1) eine gleichma¨ßige Auslastung der einzelnen Prozessorknoten, und (2) eine mo¨glichst geringe Buslast angestrebt. Die Adaption der konkreten Architektur erfolgt durch Prozessmigration im laufenden System. Gleichzeitig kann das angepasste Architektur-Modell zur Pru¨fung der u¨brigen Qualita¨tskriterien herangezogen werden, z.B. die Verletzung von Sicherheitsanforderungen, falls durch die Migration die notwendige Isolation zweier Prozesse mit unterschiedlichem Sicherheitslevel aufgehoben wu¨rde. Schließlich kann die resultierende Evaluationsstruktur zur Dokumentation der vollzogenen Evolution als Bestandteil des Qualita¨ts- und Versionsmanagements dienen.
[BCK03] [BSG09] [CN07]
L. Bass, P. Clements und R. Kazman. Software Architecture in Practice. AddisonWesley Longman, Amsterdam, 2. Auflage, 2003.
M. Balz, M. Striewe und M. Goedicke. Embedding Behavioral Models into ObjectOriented Source Code. In Software Engineering, Seiten 51–62, 2009. P. Clements und L. M. Northrop. Software Product Lines: Practices and Patterns.
Addison Wesley, 6. Auflage, 2007. [Leh96] [Mas07] [Par94] [RB02] [RH06] [SG07] [SGM09]
D. Masak. Legacysoftware: Das lange Leben der Altsysteme. Springer, 2007. D. L. 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.
A. Rausch und M. Broy. Evolutionary Development of Software Architectures. In Technology for Evolutionary Software Development, a Symposium organised by NATO’s Research & Technology Organization (RTO), 2002.
R. Reussner und W. Hasselbring. Handbuch der Software-Architektur . Dpunkt, 2006. J. Steiner und U. Goltz. Engineering Self-Management into Legacy Systems. In Proceeding for 3rd International Conference on Self-Organization and Autonomous Systems in Computing and Communications (SOAS 2007), Jgg. 2 of System and Information Science Notes, Seiten 114–117, 2007.