Verteilte Evolution von Softwareproduktlinien: Herausforderungen und ein Lösungsansatz KlausSchmid schmid@sse.uni-hildesheim.de Institut für Informatik Universität Hildesheim
Marienburger Platz 22 D-31141 Hildesheim
Verteilte Evolution von Softwareproduktlinien: Herausforderungen und ein Lösungsansatz 88D41B827D069A6236EF96F9DCBE0583 GROBID - A machine learning software for extracting information from scholarly documents

Die Evolution einzelner Systeme ist bereits relativ komplex, doch alle diese Probleme findet man potenziert in einer Produktlinienentwicklung. Zusätzlich zu den Einzelsystemproblemen treten weitere Schwierigkeiten hinzu. In diesem Beitrag gehen wir auf die Herausforderungen der Produktliniensituation ein und legen unser Augenmerk vor allem auf die Situation verteilter Evolution. Wir stellen einen möglichen Ansatz zur Lösung vor.
Einleitung

Im Laufe der letzten 10-15 Jahre ist die Entwicklung von Software in Form einer Produktlinie für die meisten Unternehmen zum Normalfall der Softwareentwicklung geworden. Das heißt, eine Menge von Systemen wird in integrierter Weise mit Hilfe gemeinsamer Komponenten entwickelt. Dies geschieht vor allem, um die Entwicklungszeit zu verkürzen und die Kosten zu verringern [LSR07,CN01]. Betrachtet man also das Problem der Softwareevolution und insbesondere der Legacy Systeme aus dem Blickwinkel der softwareentwickelnden Organisationen, so macht es Sinn das Problem im Zusammenhang mit der Evolution von Produktlinien insgesamt zu betrachten.

Das Problem der Produktlinienevolution ist aus den folgenden Gründen eine echte Obermenge der Evolution von Einzelsystemen:

• Es umfasst alle Problematiken der Evolution von Einzelsystemen, den jedes einzelne System kann jeweils zum Legacy-System werden.

• Änderungen, die sich die Kunden der einzelnen Systeme wünschen, können sich stark widersprechen, müssen aber in einer Produktlinie zusammengeführt werden. Dies führt zu einer wesentlichen Komplexitätserhöhung.

• Die Lebensdauer einer Produktlinie ist -da sie viele Produkte umfasst -meist deutlich länger als die eines einzelnen Produkts.

Auf Grund dieser Herausforderungen gibt es aktuell noch keine zufriedenstellenden Lösungen für die Produktlinienevolution.

Als eine weitere Schwierigkeit komm bei der Produktlinienentwicklung hinzu, dass einzelne Produkte häufig einen Plattformcharakter haben. Das heißt, Kunden der Produkte führen selbst Anpassungen durch, die dann wiederum zu einer besonderen Produktvariante führen. Dabei entsteht die Schwierigkeit, dass das produktlinienentwickelnde Unternehmen diese Produkte meist nicht kennt, die aufbauenden Produkte sollten aber auch bei einer Aktualisierung der zugrundliegenden Produktlinienelemente intakt bleiben.

Produktlinienevolution

In diesem Abschnitt führen wir die wesentlichen Begriffe der Produktlinienentwicklung ein und diskutieren die Herausforderungen der Produktlinienevolution genauer. • Zu den aufgeführten Änderungstypen kommen noch Spezialformen, wie beispielsweise die Veränderung der Auswahlmöglichkeiten, die Änderung von Abhängigkeiten, usw.

Produktlinienentwicklung
Evolution von ProduktlinienIm

Eine Übersicht gibt Abbildung 2. Eine detaillierte Diskussion ist in [SE07] gegeben. • Kunden möchten manche Erweiterungen und Veränderungen der Infrastruktur nicht mitmachen. Diese können bspw. durch Änderungen für andere Kunden oder durch allgemeine Evolutionsentscheidungen auftreten. Diese Trennung ist nicht möglich.

Ein Beispiel zur Produktlinienevolution
Als Grundlage zur Diskussion von

• Die Integration in die Infrastruktur ist komplexer als eine Einzelsystemänderung. Diese zusätzliche Zeit steht manchmal nicht zur Verfügung; eine Anpassung muss manchmal speziell für einen Kunden erfolgen.

• Kunden haben spezielle Anpassungen für ihr System erhalten, diese sollen natürlich auch bei aktualisierten Versionen noch unterstützt werden.

• Die Entwicklung findet verteilt statt (evtl. Firmenübergreifend). Dadurch gibt es keine einheitliche Sicht auf die Produktlinie.

• ..

Dies sind nur einige Beispiele für Herausforderungen im Bereich der Produktlinienevolution.

Lösungsansatz

In diesem Abschnitt wollen wir die Grundlagen für einen Evolutionsansatz, der die oben beschriebenen Probleme mindert oder sogar löst skizzieren. Wesentliche Charakteristika dabei sind:

• Eine Abbildung der Produktlinienevolution auf Produktlinienvariabilität wird vorgenommen. Das heißt, das Variabilitätsmodell deckt alle Varianten ab, auch die von früheren Plattformversionen. Variabilitäten können erst entfernt werden, wenn keine entsprechenden Produkte mehr im Feld sind.

• Um das Problem der Zeitverzögerung durch die Integration in die Infrastruktur zu lösen, kann zuerst lediglich das Variabilitätsmodell integriert werden, während die Realisierung als getrennte Version verbleibt. In weiteren Schritten kann dann eine tiefere Integration erfolgen.1

• Verschiedene Kunden (oder Entwicklungspartner) haben eventuell nur Zugriff auf einzelne Ausschnitte des Gesamtmodells (inklusive des Variabilitätsmodells). Trotzdem betrachten wir alle Bestandteile eines solchen verteilten Variabilitätsmodells als ein (virtuelles) Variabilitätsmodell.

• In der Aktualisierung von Systemen werden minimale Änderungen angestrebt (ein Kunde erhält ein Update, das nur die Änderungen enthält, die für den Kunden notwendig sind). Das heißt auf Artefaktebene sollen kleine (nicht notwendigerweise formal minimale) Change-Sets identifizierbar sein.

Charakteristika des Ansatzes

Eine solche Vorgehensweise erfordert es zu einer einzelnen Variation die notwendigen Artefakte zuzuordnen. Nur so können die einzelnen Auslieferungen auf die jeweils notwendigen Artefakte beschränkt werden. Wollen wir nun eine Modularisierung beschreiben, um zu ermöglichen, dass Kunden ihre eigenen Anpassungen durchführen (oder diese von Dienstleistern durchführen lassen), so ist es notwendig, dass Variabilitätsmodell und Artefaktmodelle (Anforderungen, .., Test) in gleicher Weise modularisiert werden. Wir definieren also:

Ein Featurebundle besteht aus:

• Einem Variabilitätsmodellfragment

• Allen dazugehörigen (also durch das Variabilitätsmodellfragment) beeinflussten Anforderungen

• Allen dazugehörigen Architekturelementen • Welche Arten der Zerlegung von Variabilitätsmodellen sollen unterstützt werden?

•

oAbbildung 1: Notation und Beispiel für einen Featurebaum
•Abbildung 4: Beziehung zwischen Variabilitätsmodell und Entwicklungsartefakten
Abbildung 5: Variabilitätsmodell mit Feature Bundles
Der weitere Beitrag ist wie folgt strukturiert. Der nächste Abschnitt führt kurz die Grundbegriffe für Produktlinienentwicklung ein und stellt das Problem der Evolution näher da. In Abschnitt 3 skizzieren wir unseren Lösungsansatz und stellen wesentliche Anforderungen dar, die er mit sich bringt. Eine abschließende Diskussion bietet Abschnitt 4.
Bestandteil eines Produkts sein, müssen es aber nicht), sowie die Repräsentation von Alternativen. Außerdem wird dabei die Abhängigkeit von Eigenschaften (requires) dargestellt. Abbildung 1 stellt beispielhaft eine Produktlinie dar, in der jedes Produkt die Eigenschaft A1 oder A2 (aber nicht beide) hat, Produkte die Eigenschaft B bzw. C haben können, aber nicht müssen. Die Eigenschaft D ist verpflichtend. Die Abhängigkeit zwischen A2 und C drückt aus, dass alle Produkte, die A2 enthalten auch C enthalten müssen. Weiterhin können zu Features Parameterwerte gehören. Diese werden aber in dieser Notation nicht graphisch dargestellt. Dies ist eine sehr einfache Variante der Featuremodellierung; auch wollen wir hier nicht auf semantische Formalisierungen (bspw. [SHT06]) eingehen, um die konzeptionelle Diskussion hier nicht unnötig kompliziert zu machen.
werden. DasVariabilitätsmodell nennt dabei die möglichen Ausprägungen von Eigenschaften unddefiniert insbesondere Abhängigkeiten zwischen diesen Eigenschaften. VerschiedeneArten von Variabilitätsmodellen sind gebräuchlich. Am häufigsten werden sogenannteFeaturemodelle [KC+90, RSP03, CHE05a] verwendet, aber auch Entscheidungsmodelle[SJ04] werden genutzt. Da die Darstellung von Featuremodellen -insbesondere in derForm von Featurebäumen -sich besonders gut zur Erläuterung eignet, nutzen wir dieseDarstellungsweise hier. Es gibt verschiedene Varianten auch dieser Notation. Hiernutzen wir eine Variante, die sich weitestgehend auf FODA [KC+90] stützt (vgl.Abbildung 1). Dieses Modell unterstützt die Dekomposition einer Produktlinie in ihreBestandteile, die Auszeichnung sogenannter optionaler Features (diese können
Die Grundidee einer Produktlinienentwicklung ist es eine Menge von Systemen gemeinsam aus einer Menge von Assets zu entwickeln, wobei eine möglichst hohe Wiederverwendung erreicht werden soll. Dies kann einerseits erreicht werden indem die Zusammensetzung der Komponenten für die einzelnen Systeme unterschiedlich ist. Zum anderen können die Komponenten selbst wieder parametrisierbar sein, und schließlich gibt es die Möglichkeit produktspezifischer Komponenten. Um diese Flexibilität zu ermöglichen spielt in einer Produktlinienentwicklung die Softwarearchitektur eine wesentliche Rolle. Sie beschreibt eine konfigurierbare Softwarearchitektur; die einzelnen Systeme instanziieren diese, um zur jeweiligen Produktarchitektur zu gelangen. Die Produktlinienarchitektur wird daher auch als Referenzarchitektur bezeichnet. Von besonderer Bedeutung ist in einer Produktlinienentwicklung das Variabilitätsmodell. Dieses Modell beschreibt, wie die verschiedenen Produkte variieren können, und damit welche Eigenschaften von der Produktlinie insgesamt unterstützt
Ansätzen zur Produktlinienevolution wollen wir hier ein einfaches Beispiel einführen. Das entsprechende Featuremodell findet sich in Abbildung 3. In Abbildung 3a ist ein einfaches Featuremodell für eine Produktlinie Zum Zeitpunkt t 3 wird schließlich B2 in B2´ überführt. Dies kann bspw. auf Grund von Fehlerkorrekturen oder auf Basis ergänzender Anforderungen notwendig werden. Da A3 abhängig ist von B2 kann dies natürlich Auswirkungen auf A3 haben. Vor allem wenn diese nutzerseitig sichtbar sind, kann dies dazu führen, dass dies nicht gewünscht wird. Schwieriger noch ist es für die Ergänzung B4, da das Unternehmen, welches für die Produktlinieninfrastruktur verantwortlich ist, nichts von B3 weiß, ist eine Überprüfung des Gesamtresultats nicht möglich. Trotzdem ist unter allen Umständen zu vermeiden, dass B3 nicht mehr funktionstüchtig ist.(a) Ausgangssituation(b) EndsituationNun gibt es weitere Änderungen:• Zum Zeitpunkt t 2 wird B1 aus einem gemeinsamen Feature in ein optionalesFeature überführt. Nach Aussage des Variabilitätsmodells sollte dies keinerleiAuswirkungen auf die anderen Features haben -und insbesondere auf diemöglichen Varianten. Da jedoch zum Zeitpunkt t 1 B1 noch als verpflichtendangenommen wurde, besteht eine gewisse Wahrscheinlichkeit, dass evtl.Abhängigkeiten nicht dokumentiert sind. Auch erfordert die Integration von
Abbildung 2: Übersicht über mögliche Evolutionsschritte für Produktlinien[SE07].dargestellt, die zu einem Zeitpunkt t 1 die Ausgangssituation darstellt. Nehmen wir jetzt folgende Änderungsanforderungen an: • Kunde 1 hätte gerne eine Erweiterung der Produktlinie um das Feature A2. Damit es nur diesem Kunden zur Verfügung gestellt werden kann, wird dieses als optionales Feature realisiert. (Wir behandeln hier zur Vereinfachung produktspezifische /kundenspezifische Funktionalität wie Variabilitäten.) • Kunde 2 ist selbst in der Lage Anpassungen durchzuführen. Dies kann beispielsweise der Fall sein, da ihm die Realisierung (soweit sie ihn betrifft) zur Verfügung steht. Er erweitert die Alternative B4, B5 um eine weitere Ausprägung B3. Diese erfordert jedoch die das Feature B2. Da diese Erweiterung vom Kunden selbst durchgeführt wird, wird sie (und die Abhängigkeit) dem Hersteller eventuell nie bekannt. Eine entsprechende Situation gibt es beispielsweise in der Entwicklung für Standardsoftware. Abbildung 3: Ein einfaches Evolutionsbeispiel: Anfangs-und Endsituation Variabilitätsmechanismen weitergehende Implementierungsänderungen, die ebenfalls andere Features beeinflussen können. • In der Praxis lassen sich angesichts dieser Schwierigkeiten nun verschiedene Ansätze zur Produktlinienevolution beobachten: • Der einfachste Weg ist: für jeden Kunden wird eine Kopie der Infrastruktur erzeugt. Dies vermeidet Abhängigkeiten zwischen Änderungen für unterschiedliche Kunden. Jedoch hat dies zur Folge, dass jede Infrastrukturänderung, die für alle Kunden relevant ist, mehrfach realisiert werden muss. Aus diesem Grund wird dieser Ansatz manchmal auch als nicht zum Produktlinienkonzept kompatibel aufgefasst. Im Fall von Kunde 2 wäre auch nach wie vor offen, ob seine eigenen Ergänzungen (B3) noch funktionstüchtig sind, wenn er eine Produktbasis erhält, die B2´ enthält. • Ein weiterer Ansatz ist der Versuch alle Evolution in der Produktlinie zu realisieren. Dies hat jedoch auch wesentliche Folgen. So können Ergänzungen wie die von Kunde 2 nicht mehr durchgeführt werden, ohne dass dies dem Hersteller bekannt ist. Dies heißt auch, dass sobald ein Kunde eine Fehlerkorrektur in einer Funktionalität übernehmen will, er in allen Features die aktuellste Version übernehmen muss. Dies sind nur Beispiele: insgesamt haben heutige Evolutionsänsätze eine Menge von Schwierigkeiten. Beispiele sind:
Eine solche Menge von ein Feature (bzw. eine Featureänderung realisierenden Artefakten) bezeichnen wir als Featurebundle. Dabei ist es notwendig die Verbindung zwischen den Variabilitäten und den jeweiligen Lebenszyklusmodellen zu beachten, bzw. zu etablieren. Dies wird in Abbildung 4 dargestellt: das Variabilitätsmodell tritt als Konfigurationsmodell auf und beschreibt die Anpassung der weiteren Modelle, um jeweils spezifische Produkte abzuleiten. So werden Instanzen in einheitlicher Weise beschrieben, bei denen Anforderungen, Architektur, Implementierung und Tests jeweils zu einer bestimmten Systeminstanz gehören.
Neben einem eigenen Namensbereich ist bei einer Modularisierung vor allem wichtig Import-und Exportschnittstellen zu definieren. Eine Import-Schnittstelle definiert welche Teile des Basismodells bzw. darunterliegender Featurebundels genutzt werden sollten, eine Exportschnittstelle definiert die möglichen Variabilitäten, sowie die Punkte an denen zusätzliche Erweiterungen möglich sind (wie dies bspw. Eclipse mittels Extensionpoints tut). Dies erlaubt eine beliebige Kombination mehrerer Teilfeaturemodell, wobei die Konsistenz überprüfbar bleibt.
Wie lässt sich eine Modularisierung (im Sinne einer Kapselung) derVariabilitätsmodelle herstellen?Die Kapselung und Zerlegung von Teilkonfigurationsmodellen ist heute in der Praxisbereits bei Installations-und Updatewerkzeugen gebräuchlich. Jedoch wurde dies bishernur beschränkt theoretisch behandelt [SK09]. Da einzelne Systembestandteile von unter-schiedlichen Entwicklungsorganisationen geliefert werden, wird dies oft nicht alsProduktlinienentwicklung wahrgenommen, jedoch kann ein solches Konfigurations-problem weitestgehend einer verteilten Produktlinienentwicklung gleich gesetzt werden.
Dies kann dann als Integration über das Versionsmanagement gesehen werden, ein Ansatz der von Produktlinienwerkzeugen wie GEARS [GEARS] gar als einzigem Ansatz unterstützt wird. Jedoch wird dort die spätere Integration nicht explizit unterstützt.
Der Autor Möchte Hr Dr Hübner Hr. Keunecke und Hr. Brummermann für anregende Diskussion und die Darlegung der grundsätzlichen Evolutionsproblematik danken Formalizing cardinality-based feature models and their specialization KCzarnecki SHelsen UEisenecker Software Process: Improvement and Practice 10 1 2005 Staged configuration through specialization and multi-level configuration of feature models KCzarnecki SHelsen UEisenecker Software Process Improvement and Practice 10 2 2005 Software Product Lines: Practices and Patterns PClements LNorthrop 2001 Addison-Wesley Supporting the Evolution of Product Line Architectures with Variability Model Fragments DDhungana TNeumayer PGruenbacher RRabiser Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008. 2008 Feature-Oriented Domain Analysis (FODA) Feasibility Study KKang SCohen JHess WNovak APeterson CMU/SEI-90-TR-21 1990 Software Engineering Institute Technical Report Product Lines in Action FVan Der Linden KSchmid ERommes 2007 Springer Verlag Modeling variability for object-oriented product lines MRiebisch DStreitferdt IPashov ECOOP Workshops Springer 2003 3013 A Requirements-Based Taxonomy of Software Product Line Evolution KSchmid HEichelberger Proceedings of the Third International ERCIM Symposium on Software Evolution (Software Evolution the Third International ERCIM Symposium on Software Evolution (Software Evolution 2007. Oktober 2007 Model-Based Implementation of Meta-Variability Constructs: A Case Study using Aspects, Second International Workshop on Variability Modeling of Soft-ware-Intensive Systems KSchmid HEichelberger ICB-Research Report No 1860- 2770 22 2008 A Customizable Approach to Full Lifecycle Variability Management KSchmid IJohn Science of Computer Programming 53 3 2004 An Analysis of Existing Software Configuration Systems KSchmid CKröher Third International Workshop on Dynamic Software Product Lines (DSPL 2009) at the Software Product Line Conference 2009 Feature Diagrams: A Survey and a Formal Semantics PSchobbens PHeymans JTrigaux 14th Requirements Engineering Conference (RE'06) 2006