=Paper=
{{Paper
|id=Vol-537/paper-12
|storemode=property
|title=Qualitätssichernde Koevolution von Architekturen eingebetteter Systeme
|pdfUrl=https://ceur-ws.org/Vol-537/D4F2009_Paper10.pdf
|volume=Vol-537
}}
==Qualitätssichernde Koevolution von Architekturen eingebetteter Systeme==
<pdf width="1500px">https://ceur-ws.org/Vol-537/D4F2009_Paper10.pdf</pdf>
<pre>
       Qualitätssichernde Koevolution von Architekturen
                      eingebetteter Systeme

                                 Malte Lochau und Ursula Goltz
                     Institut für Programmierung und Reaktive Systeme
                                        TU Braunschweig
                                 {lochau|goltz}@ips.cs.tu-bs.de

       Abstract: Eingebettete Software-Systeme sind heute allgegenwärtig und müssen zu-
       künftig auch in Hinblick auf eine stetig steigende Lebensdauer und Wartbarkeit ent-
       worfen 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 wesent-
       liche Grundlage für die Planung und strukturierte Durchführung von Änderungen im
       gesamten Lebenszyklus. Gleichzeitig kann durch Evolutions-begleitende Architektur-
       Evaluationen die nachhaltige Erfüllung von Qualitätskriterien wie Echtzeiteigenschaf-
       ten, Sicherheit und Verfügbarkeit sichergestellt werden. Wir beschreiben die Einbet-
       tung von Maßnahmen zur fortgesetzten Qualitätssicherung in einen koevolutionären
       Betriebs- und Wartungsprozess und die hierfür erforderliche Konsistenz der Architektur-
       Spezifikation mit dem laufenden System. Der Ansatz wird anhand einer Fallstudie,
       einer adaptiven Robotersteuerung mit harten Echtzeitanforderungen, illustriert.


1     Einführung

1.1   Architekturen evolvierender Systeme

Die Software ist der zunehmend kritische Faktor für den Erfolg eingebetteter Systeme. Da-
bei entsteht ein steigender Anteil der Aufwände und Kosten für derartige Systeme durch
Wartungs-, Anpassungs- und Weiterentwicklungstätigkeiten, also der Evolution der Soft-
ware [EGG+ 09, Mas07], die gerade bei eingebetteten Systemen von der Umgebung und
dem Anwendungskontext geradezu erzwungen wird [Leh96, Par94].
Der Architektur einer Software kommt zukünftig eine entscheidende Rolle zu, damit ein
Software-System evolvierbar ist und bleibt. Dies gilt sowohl fü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 Evo-
lution zukünftiger Systeme beherrschbar zu halten, muss bereits im Rahmen des Ent-
wurfs und der Modellierung die Anpassbarkeit als Kriterium bzw. Eigenschaft explizit
berücksichtigt werden. Dies kann nicht allein durch den Einsatz moderner Technologi-
en und Paradigmen und der damit verbundenen ”Verheißungen“, wie z.B. dem Einsatz
Service-orientierter Entwurfsprinzipien, erzielt werden. Vielmehr sind neben Domänen-
spezifischen Lösungsmustern vor allem übergeordnete Prinzipien einer modularen, konfi-
gurierbaren Architektur-Konzeption wesentlich fü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 Evo-
lution besteht somit auch die Notwendigkeit, ein fortlaufendes Qualitätsmanagement be-
gleitend zum gesamten Lebenszyklus zu definieren. Dennoch können nicht alle erdenk-
lichen 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, Lebens-
zyklus-übergreifende Entwicklungen nur schwer abgeschätzt werden, wie z.B. sich ändern-
de Anforderungen, Erosionen in der Umgebung oder der technischen Infrastruktur so-
wie die Portierung auf andere Plattformen. Methodiken zur planvollen Evolution von
Software-Systemen, die auf strukturierten, Architektur-basierten Vorgehensweisen beru-
hen, müssen geeignete Dokumentationsansätze für die Nachverfolgbarkeit unternomme-
ner Anpassungen beinhalten. Dabei muss nicht nur die korrekte Funktionsfähigkeit des
Systems gewährleistet bleiben, sondern gleichzeitig die Sicherung weiterer Qualitätseigen-
schaften im Betrieb möglich bleiben.
In diesem Beitrag beschreiben wir, inwieweit Architektur-Modelle nicht nur für den Ent-
wurf und Implementierung sowie die Planung von Evolutionen eingebetteter Systeme
von entscheidender Bedeutung sind, sondern auch die Grundlage für ein Lebenszyklus-
übergreifendes Anforderungs- und Qualitä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 er-
folgen. Die kontinuierliche Koevolution von Systemspezifikation und Systemimplemen-
tierung erfordert die Integration von Methodiken zur Ermittlung konkreter Architektur-
ausprä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 Abwägung aller relevanten Qualitätsziele etabliert werden. Zudem
können Anpassungen geeignet dokumentiert und nachverfolgt werden, um die Auswir-
kungen unternommener Evolutionsschritte in nachfolgende Entscheidungen einfließen zu
lassen.


1.2   Qualitätssicherung durch Architektur-Evaluation

Eine frühzeitige Bewertung der zu erwartenden Qualität eines Systems durch Architektur-
Evaluation [BCK03] ist ein unverzichtbarer Bestandteil des Entwurfsprozesses für ein-
gebettete Systeme. Wie in [FGB+ 07] für den Anwendungsbereich automotiver Systeme
beschrieben wurde, ermöglicht ein strukturierter Evaluationsansatz die Integration von Be-
wertungstechniken 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 Einzel-
kriterien durch geeignete Qualitätsattribute charakterisiert und bewertet. Für die konkrete
Bewertung dieser Kriterien hinsichtlich einer Architektur-Variante werden einheitliche Be-
wertungstechniken, wie z.B. Metriken oder Expertenbefragungen, definiert. Gerade Metri-
ken können automatisiert auswertbar als integraler Bestandteil einer Komponente zur An-
passungsplanung implementiert werden kö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 Ein-
zelkriterien eine Gesamtqualität zu ermitteln, werden Qualitä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 Realisier-
barkeit nicht zu gefährden. Die Integration zu einer Gesamtqualität erfolgt durch Hier-
archisierung in Unter- und Oberkriterien mit entsprechenden Gewichtungen gemäß 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 beglei-
tend zum Entwurf automotiver Steuergerätenetzwerke, also vor der Implementierung und
dem Betrieb des Systems, betrachtet. Für eingebettete Systeme mit evolutionsfähigen Ar-
chitekturen wird zunehmend auch die Notwendigkeit bestehen, den Erhalt von Qualitätsei-
genschaften nicht nur initial, sondern auch begleitend zu den fortlaufenden Änderungen
im Betrieb sicherzustellen.


1.3   Fallstudie: Architektur einer adaptiven Robotersteuerung

Für die nachfolgenden Überlegungen beziehen wir uns exemplarisch auf die Parallel
                                                                           ”
RObot Software Architecture - eXtended“ (PROSA-X) [SG07] als Beispiel für ein evo-
lutionsfähiges, verteiltes eingebettetes System mit hohen Qualitätsanforderungen. Abb.
2 zeigt die Prosa-X-Architektur zur Integration der Steuerungsmodule von Parallelro-
botern. 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 Kompo-
nentenstruktur 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     Qualitätssichernde Koevolution von Architekturen eingebetteter Sys-
      teme

2.1   Evolution von Software-Systemen

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 Ge-
samtarchitektur und dem Deployment. Ein sorgfältig strukturierter Architektur-Entwurf
mit stabilen Komponentenschnittstellen und Konfigurationsparametern kann zur Anpass-
barkeit 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 für Robotersteuerungen
Adaption: Die Fähigkeit des Systems, sich selbst zur Laufzeit durch geeignete Strate-
gien an bestimmte Bedingungen oder Kontexte anzupassen, wie z.B. zur Kompensation
ausfallender Systemressourcen hinsichtlich Verfügbarkeits-, Sicherheits- und Echtzeitan-
forderungen. Die Implementierung adaptiven Verhaltens kann z.B. durch parametrisierba-
re Architektur-Artefakte, also der Spezifikation des Änderungspotentials im Architektur-
Modell erfolgen. Im Betrieb kann nun entweder bei Bedarf zwischen zuvor festgelegten
Modi umgeschaltet, oder durch Online-Planung je nach Situation eine optimale Parame-
trisierung ermittelt werden.
Die in Abschnitt 1.3 beschriebene adaptive Architektur PROSA-X verfügt über eine spezi-
elle Komponente (Self-Manager), die je nach Betriebszustand durch Rekonfiguration von
Betriebsparametern Self*-Eigenschaften realisiert [SG07].
Für beide Ansätze sind Architektur-Modelle die Basis fü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 führen
gerade deshalb zur nachhaltigen Schädigung“ (Erosion) der Architektur. Die so konti-
                                   ”
nuierlich anwachsende Entropie der Systeme führt dann unter anderem zu abnehmender
Wartbarkeit und Performanz [Mas07]. Zudem werden durch diese Wucherungen“ die Ab-
                                                                   ”
grenzungen des Systems zur Umgebung zunehmend unklar.


2.2     Architektur-Modellierung und -Rekonstruktion

Der Architektur-Entwurf ist das Bindeglied zwischen der Anforderungsanalyse und dem
technischen Design, auf dessen Grundlage neben der korrekten Implementierung der ge-
forderten Funktionalität zugleich Maßnahmen zur Qualitätssicherung in den Entwurfspro-
zess integrieren werden können [FGB+ 07, LMD+ 09, LMS+ 09].


2.2.1    Architektur-Modelle eingebetteter Systeme

Für Abstraktionskonzepte von Architektur-Spezifikationen, insbesondere zur strukturel-
len 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-Arte-
fakte und den Abhängigkeiten zwischen diesen Elementen.
Eingebettete Systeme sind zunehmend Software-intensiv und realisieren Steuerungs- und
Regelungsaufgaben durch Kommunikations-orientierte Integration verschiedenster, hoch-
spezialisierter Komponenten auf häufig massiv verteilten und heterogen strukturierten Hard-
ware-Plattformen. Standardisierte Schichtenarchitekturen erlauben eine flexible Vertei-
lung von Software- und Hardware-Komponenten, sodass beliebige Architektur-Varianten
bezüglich (Wieder-) Verwendung, Anordnung, Verteilung und Verknüpfung dieser Kom-
ponenten 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̈ber-
                                                                     ”
gang 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 System-
teilen aufzeigen, sondern auch durch Modularisierung gezielt die Austauschbarkeit von
Teilkomponenten unterstützen.
Architektur-Entwürfe konzentrieren sich in der Regel auf die Spezifikation statischer Struk-
turen, jedoch ist dies für weitergehende Zwecke, wie z.B. für Systemanalysen zur Anpas-
sung bzw. Rekonfiguration, oft unzureichend, sodass deshalb eine Kombination mit Ver-
haltensmodellen notwendig ist [RB02]. Um zukünftig beim Entwurf von System-Architek-
turen potenzielle Evolutionen bereits während der Entwicklung zu berücksichtigen, muss
die geplante Variabilität des Systems explizit mitmodelliert werden. Derartige evoluti-
onsfä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 Produktlini-
en-Ansätze [CN07]. Durch vordefinierte Variationspunkte werden mögliche Freiheitsgra-
de für die Anpassbarkeit des Systems bereits als Teil des Architektur-Modells festgelegt.
Je nach Änderungsszenario kann die Evolution dann durch Anpassung betroffener Arte-
fakte erfolgen, und das in sämtlichen Phasen des Lebenszyklus. Hierfür sind Architektur-
Metamodelle notwendig, die neben der Zuordnung von Variabilitätspunkten auch die Inte-
gration von zusätzlichem Wissen über das System erlauben. Auf diese Weise kann sowohl
auf Änderungen funktionaler, als auch nicht-funktionaler Anforderungen zielgerichtet rea-
giert werden.


2.2.2   Architektur-Sichten eingebetteter Systeme

Die Definition von Architektur-Sichten trägt beim Entwurf von Architekturen eingebet-
teter Systeme maßgeblich zur Übersichtlichkeit und Komplexitätsbeherrschung bei. Aus-
gehend 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 Rechenein-
heiten 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 Einhei-
ten des Systems mitsamt ihren Abhängigkeiten. Je nach Modellierungsansatz können kon-
zeptionelle Architekturen unterschiedlichste Artefakte beinhalten. Beispielsweise kann die
Struktur des Softwaresystems auf Grundlage einer Component-Connector-Abstraktion be-
schrieben 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, operatio-
nellen Einheiten die aktuelle Architektur-Ausprägung. Dazu gehören Artefakte wie lau-
fende Prozesse (Tasks), deren Kommunikation untereinander sowie Werte von Konfigura-
tionsparametern. 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 unver-
meidbar. 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 können passende Architektur-Sichten definiert wer-
den, 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 Randbedin-
gungen 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   Architektur-Rekonstruktion

Die Kenntnis der Architektur eines Systems ist Grundvoraussetzung für ein tiefer gehen-
des Verständnis der internen Systemstrukturen zur Analyse und Evolutionsplanung. Für
langlebige Systeme mit hohen Anteilen an Legacy-Komponenten liegen allerdings hä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 oft-
mals nur für die Qualitätsbewertung unzureichende statische Aspekte der Systemstruk-
tur. Es gibt eine Vielzahl von Ansätzen, um für ein bestehendes System Architektur-
Eigenschaften zu rekonstruieren, über die nachfolgend ein kurzer Überblick gegeben wer-
den soll.
Rekonstruktion: Durch heuristisches“ Reverse Engineering wird versucht, höhere Ab-
                         ”
straktionsebenenen, wie z.B. Component-Connector-Strukturen und andere Pattern, aus
dem Quellcode eines bestehenden Software-Systems ohne adäquate Spezifikation zu er-
mitteln. Eine wesentliche Problematik besteht hier im mismatch“ zwischen abstrakten
                                                        ”
Architektur-Konzepten und den Artefakten von Programmiersprachen, also der Definiti-
on eines geeigneten correspondence model zwischen Code und Architektur-Modell. Bei
der Hardware-nahen Programmierung eingebetteter Systeme gestaltet sich die Identifika-
tion von High-Level-Komponenten als besonders schwierig. Ansätze zum Architektur-
Recovery sind in der Regel nur (semi-) automatisierbar, bedürfen also geführter Entschei-
dungen 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 möglich wird. Speziell objek-
torientierte Programmierparadigmen weisen eine enge konzeptionelle Verwandtschaft zu
Komponenten-orientierten Architektur-Modellen auf. Die Einbettung von Verhaltensmo-
dellen werden z.B.. [BSG09] und [SVB+ 03] beschrieben. Weiterhin können hier Program-
mierumgebungen mit Reflection-Funktionen angefü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 Aspek-
te und Strukturen. In Kombination mit Monitoring-Ansätzen können diese um dynami-
sche 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   Architektur-Koevolution unter Erhalt von Qualitätseigenschaften

Die Integration der beschriebenen Verfahren erfordert Vorgehensmodelle, die den gesam-
ten Lebenszyklus eingebetteter Systeme vom initialen Entwurf, der Implementierung und
Inbetriebnahme, bis zur Wartung und Anpassung im Betrieb, umfassen. Die Konsistenzsi-
cherung zwischen Anforderungsspezifikation, Architektur-Modell und Systemimplemen-
tierung verlangt einen umfassenden Ansatz zur Koevolution, d.h. der fortgesetzten Syn-
chronisation des laufenden Systems und der Spezifikation. Neben der Planung und Do-
kumentation möglicher Evolutionen kann so gleichzeitig die Sicherung der geforderten
Qualitätseigenschaften auf Grundlage der aktuellen Architektur-Ausprägung erfolgen. Der
prinzipielle Aufbau eines entsprechend zyklischen Vorgehensmodells ist in Abbildung 3
skizziert. Das dargestellte Roundtrip Engineering ist notwendig, um die beiderseitige Syn-
chronisation zwischen Spezifikation und laufendem System sicherzustellen, da (1) Ero-
sionen 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 Anforderun-
                                                          ”
gen und Implementierung: (1) als Entwurf der initialen (konzeptionellen) Systemstruktur,
(2) zur modellbasierten Repräsentation der wesentlichen Aspekte des (konkreten) System-
zustandes, und damit (3) als Grundlage für die Planung, Durchführung und Dokumen-
tation von Anpassungen und Adaptionen. Sowohl beim ersten Entwurf, als auch bei der
fortgesetzten Evolution der System-Architektur kann die Sicherstellung geforderter Qua-
litä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 prin-
zipiell 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 Be-
                   ”
deutung sein, wohingegegen das konzeptionelle Architektur-Modell für die Planung von
Umstrukturierungen größeren Umfangs, wie z.B. der Integration neuer Komponenten, die-
nen 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 Koevolu-
tion zwischen Anforderungen, Architektur-Modellen und der Implementierung, besteht
auch die Notwendigkeit, die Konsistenz von konkreter und konzeptioneller Architektur si-
cherzustellen. Die konkrete Architektur ergibt sich als Snapshot aus Systemzustand und
Laufzeitartefakten im betrachteten Betriebszeitpunkt und kann, wie in Abschnitt 2.2.3 be-
schriebenen, 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 Aus-
prä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 gera-
de die für diese Anpassungen notwendigen Änderungen im laufenden System impliziert.
In beiden Fällen können die aktualisierten Architektur-Modelle zur erneuten Architektur-
Evaluation und somit fortlaufenden Qualitätssicherung verwendet werden, bzw. als Ent-
scheidungsgrundlage in den Planungsprozess von Anpassungen und Adaptionen einbe-
zogen und durch Monitoring-Ansätze ergänzt werden. Die laufenden Anpassungen der
Implementierung können je nach Grad der hieraus entstehenden Evolution zu unterschied-
lich stark ausgeprägten Erosionen der konkreten, und schließlich auch der konzeptionel-
len 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 Eva-
luationsstruktur für die Qualitätskriterien nachverfolgbar und können auch als Anhalts-
punkte 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 entspre-
chende Techniken zum Erhalt der funktionalen Korrektheit einzusetzen, wie beispielswei-
se die Kombination kontinuierlicher Refactorings und Tests aus dem Bereich der agilen
Methoden [RH06]. Für eine nähere Diskussion der in diesem Bereich bestehenden Proble-
me 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 be-
darf es entsprechender Ansätze, die an dieser Stelle kurz skizziert werden sollen. Wie be-
reits in [EGG+ 09] diskutiert wurde, müssen potenzielle Evolutionen integraler Bestand-
teil der Systemspezifikation werden. Wissen über das System in Form von Konfigurati-
onsparametern für Anpassungen, Annotationen zur Metrikauswertung sowie Instrumen-
tierungen 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] propagier-
te 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 Transfor-
mationsvorschriften zwischen Artefakten des Architektur-Metamodells und entsprechen-
der Pattern in der Implementierung. Bei der Migration ganzer (Teil-) Systeme sind hin-
gegen vor allem Faktoren wie verwendete Schichten-Architekturen und Virtualisierungs-
Komponenten 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 verfügbar sind, bietet sich
auch hier die Verwendung von schwerpunktmäßig auf Architektur-Abstraktionen basie-
render 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 Qua-
litätsanforderungen definierten Evaluationsstruktur aus Abbildung 1 zur fortlaufenden Über-
prüfung der Qualität evolvierender Systeme ergeben sich folgende Fragestellungen:
1. Welche Qualitätskriterien sind im Betrieb im Vergleich zur Entwurfsphase relevant? Kri-
terien, 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 Zeit-
punkt 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 gemäß 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 Architektur-
Evaluation 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 Planungs-
                                    ”
parameter 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.
Fallstudie: Rekonfiguration unter Erhalt von Echtzeiteigenschaften
Durch das Einsatzgebiet von PROSA-
X werden hohe Anforderungen an die
Sicherheit, Verfügbarkeit, Performanz,
etc. gestellt. Um insbesondere die Er-
füllung harter Echtzeitanforderungen si-
cherzustellen, sind unter Umständen An-
passungen im laufenden Betrieb notwen-
dig, z.B. bei Änderungen an der Aus-
führungsplattform (Knotenausfall) oder
der Betriebslast (Prozessanzahl). In die-
sen 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 ermittel-
ten Kommunikationsgraphen der laufenden Prozesse. Durch eine Kombination verschie-
dener Heuristiken zur Graphpartitionierung wird eine möglichst ausgewogene Neuvertei-
lung 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 Prozess-
migration im laufenden System. Gleichzeitig kann das angepasste Architektur-Modell zur
Prüfung der übrigen Qualitätskriterien herangezogen werden, z.B. die Verletzung von Si-
cherheitsanforderungen, falls durch die Migration die notwendige Isolation zweier Prozes-
se mit unterschiedlichem Sicherheitslevel aufgehoben würde. Schließlich kann die resul-
tierende Evaluationsstruktur zur Dokumentation der vollzogenen Evolution als Bestandteil
des Qualitäts- und Versionsmanagements dienen.


Literatur

[BCK03]     L. Bass, P. Clements und R. Kazman. Software Architecture in Practice. Addison-
            Wesley Longman, Amsterdam, 2. Auflage, 2003.
[BSG09]     M. Balz, M. Striewe und M. Goedicke. Embedding Behavioral Models into Object-
            Oriented Source Code. In Software Engineering, Seiten 51–62, 2009.
[CN07]      P. Clements und L. M. Northrop. Software Product Lines: Practices and Patterns.
            Addison Wesley, 6. Auflage, 2007.
[EGG+ 09] G. Engels, M. Goedicke, U. Goltz, A. Rausch und R. Reussner. Design for Future -
          Legacy-Probleme von morgen vermeidbar? In Informatik Spektrum. Springer, 2009.
[FGB+ 07] B. Florentz, U. Goltz, J. Braam, R. Ernst und T. Saul. Architekturevaluation: Qua-
          litätssicherung in frühen Entwicklungsphasen. In 8. Symposium AAET 2007, Seiten
          238 – 248, 2007.
[Leh96]     M. Lehman. Laws of Software Evolution revisited. In Software Process Technology,
            Seiten 108–124. 1996.
[LMD+ 09] M. Lochau, T. Müller, S. Detering, U. Goltz und T. Form. Architektur-Evaluation von
          AUTOSAR-Systemen: Adaption und Integration. In Tagungsband des 1. Elektronik
          automotive congress, München, 2009.
[LMS+ 09] M. Lochau, T. Müller, J. Steiner, U. Goltz und T. Form. To appear: Optimierung von
          AUTOSAR-Systemen durch automatisierte Architektur-Evaluation. In VDI-Berichte,
          14. Internationale Konferenz Elektronik im Kraftfahrzeug, 2009.
[Mas07]     D. Masak. Legacysoftware: Das lange Leben der Altsysteme. Springer, 2007.
[Par94]     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.
[RB02]      A. Rausch und M. Broy. Evolutionary Development of Software Architectures. In
            Technology for Evolutionary Software Development, a Symposium organised by NA-
            TO’s Research & Technology Organization (RTO), 2002.
[RH06]      R. Reussner und W. Hasselbring. Handbuch der Software-Architektur. Dpunkt, 2006.
[SG07]      J. Steiner und U. Goltz. Engineering Self-Management into Legacy Systems. In Procee-
            ding 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.
[SGM09]     J. Steiner, U. Goltz und J. Maaß. Dynamische Verteilung von Steuerungskomponenten
            unter Erhalt von Echtzeiteigenschaften. In 6. Paderborner Workshop Entwurf mecha-
            tronischer Systeme, 2009.
[SVB+ 03] R. Sekar, V. Venkatakrishnan, S. Basu, S. Bhatkar und D. DuVarney. Model-carrying
          code: A practical approach for safe execution of untrusted applications, 2003.

</pre>