Feature-Diagramme und Variabilität

Feature-Diagramme und Variabilität

Stefan Marr

Hasso-Plattner-Institut, Potsdam stefan.marr@hpi.uni-potsdam.de

Kurzfassung. Feature-Diagramme und ihre Mittel zur Darstellung von Variabi- lität in Produktfamilien werden vorgestellt. Einleitend wird das Paradigma des Generative Programming betrachtet, in welchem die Methodik des Domain En- gineerings verwendet wird. Diese Methodik wird kurz dargelegt, um über die Feature-oriented Domain Analyse zur Feature-Modellierung zu kommen, in welcher Feature-Diagramme zur Darstellung eingesetzt werden. Über die Nota- tion hinaus wird der Prozess der Feature-Modellierung und die Möglichkeit zur Implementierung von Features mit UML skizziert. Abschließend werden ver- fügbare Werkzeuge und die Verwendung von Feature-Modellierung in der Industrie untersucht, um mit einem Fazit für die Einsatzmöglichkeiten zu schließen.

1 Einleitung

Im Rahmen des Requirements Engineerings, z.B. bei der Aufnahme und Verwaltung der Anforderungen eines zu entwickelnden Systems kann es vorkommen, dass man an einen Punkt gelangt, an dem es offensichtlich wird, dass das geplante System in der Art, eventuell mit kleineren Abwandlungen einem System entspricht, dass auch in einem anderen Projekt entwickelt werden soll. Hier stellt sich nun die Frage, wie solche Zusammenhänge dargestellt und dokumentiert und welche Methodiken ver- wendet werden können, um die Entwicklung effizienter zu gestalten und Synergieeffekte zu nutzen.

Mit den Feature-Diagrammen soll hier eine Möglichkeit vorgestellt werden, wie man Gemeinsamkeiten und Unterschiede von Systemen darstellen kann. Dabei ist der Begriff der Produktlinie bzw. Produktfamilie von zentraler Bedeutung. In einigen Projekten ist von vornherein klar, dass nicht ein spezielles System entwickelt werden soll, sondern potenziell eine Menge von Systemen bzw. eine Produktlinie, aus der man durch Anpassung an die Bedürfnisse eines speziellen Kunden ein spezifisches System bzw. Produkt erhält. Mit Hilfe von Feature-Diagrammen ist es an dieser Stelle möglich, die variablen Anteile einer Produktlinie kenntlich zu machen, um darauf aufbauend eine kundenspezifische Konfiguration zu erstellen, welche die gewünsch- ten variablen und obligatorischen Teile enthält. Diese Konfiguration kann dann im Anschluss als Grundlage für die Implementierung dienen.

Im Folgenden soll zuerst das Paradigma der generativen Programmierung vorge- stellt werden, welches Feature-Diagramme als Grundlage für eine auf Generatoren gestützte Entwicklung einsetzt. In diesem Rahmen sollen auch die Ideen des Domain

Engineerings und der Feature-oriented Domain Analysis vorgestellt werden. Darauf aufbauend wird die eigentliche Feature-Modellierung mit Hilfe von Feature- Diagrammen eingeführt, für welche eine Notation in Baumform verwendet wird. Diese wird im Abschnitt 3 näher erläutert. Außerdem wird der Prozess der Feature- Modellierung beschrieben und ein Ausblick auf Möglichkeiten zur Abbildung auf eine Implementierung gegeben.

Im 4. Abschnitt werden die zur Modellierung verfügbaren Tools und ihre Möglich- keiten kurz vorgestellt und anhand von Beispielen aus der Industrie die Verwendungsmöglichkeiten von Feature-Diagrammen und den dazugehörigen Me- thodiken skizziert.

2 Generative Programming

2.1 Entwicklung wiederverwendbarer Software

Eine der großen Herausforderungen bei der Softwareentwicklung ist die Wiederver- wendung von Software und Softwarefragmenten. Die Objektorientierung hat in dieser Hinsicht einen bedeutenden Fortschritt gebracht. Doch trotz allem ist die Wiederver- wendung von einzelnen Artefakten oft schwierig und an spezielle Bedingungen geknüpft, die einem wirtschaftlichen Einsatz entgegensprechen und eine Neuentwick- lung effizienter erscheinen lassen. In [1] wird als eine Ursache dafür die Optimierung von objektorientierten Analyse- und Designmethoden auf die Entwicklung einzelner Systeme genannt. Gründe sind hier vor allem die fehlende Systematik bei der Ent- wicklung von Bibliotheken und Frameworks. Da sie zumeist ad hoc entwickelt werden, fehlt ihnen oft die nötige Flexibilität oder die Komplexität ist im Einsatz unpraktikabel hoch und wirkt sich negativ auf die Performance des Gesamtsystems aus.

Ein weiteres Problem bei der Wiederverwendung ist der Verlust von Designinfor- mationen beim Übergang von einem abstrakten Modell zu einer konkreten Implementierung. Dieser Verlust kann aber auch bereits beim Übergang von einem Systemmodell zum Verstehen der abstrakten Zusammenhänge z.B. in FMC-Notation zu einem konkreteren Modell z.B. zur Darstellung einer Klassenstruktur mit UML auftreten. Das allgemeine Problem ist, dass Entwurfsentscheidungen beim Übergang zwischen Ebenen mit verschiedenen Abstraktionsgraden gar nicht oder nur schlecht dokumentiert werden. Abhilfe schafft auf diesem Gebiet z.B. die Model Driven Architecture, indem die Entwurfsentscheidungen in Form von Transformationen dokumentiert werden. In dieser Ausarbeitung soll jedoch das Paradigma des Genera- tive Programming näher betrachtet werden.

Das zu deutsch generative Programmierung genannte Entwicklungsmodell setzt ebenfalls an diesem Punkt an. Dabei geht es nach [1] darum Softwaremodule zu ent- werfen und zu implementieren, die kombiniert werden können um spezialisierte und hochoptimierte Systeme zu generieren, die bestimmten Anforderungen genügen. Ziel ist es dabei auch, die konzeptionelle Lücke zwischen Programmcode und den Kon- zepten der Domäne zu verringern. Außerdem soll die Wiederverwendbarkeit und Anpassbarkeit von Softwaremodulen erhöht werden, wobei auch der Umgang mit

Variationen von Softwarekomponenten vereinfacht werden soll. Eine Effizienzver- besserung ist ebenfalls als Ziel angegeben, wobei sowohl der Platzbedarf alsauch die Ausführungszeit optimiert werden sollen.

In Kurzform wäre eine mögliche Definition nach [3] die Folgende:

Generative programming is a software engineering paradigm based on modelling software families such that, given a particular requirements specification, a highly customized and optimized intermediate or end- product can be automatically manufactured on demand from elementary, reusable implementation components by means of configuration knowledge.

Damit wird auch klar, dass als Ergebnis des Analyse- und Designprozesses eine Familie von Systemen entsteht, aus der durch eine spezielle Menge von Anforderun- gen über die Schritte der Konfiguration und Generierung ein spezielles System erzeugt wird. Als Grundlage dafür dienen Komponenten, die durch Konfiguration variiert und ausgewählt werden können. In der Praxis hat sich die komponentenba- sierte Entwicklung für direkte Wiederverwendung von Softwaremodulen bereits seit Langem als sinnvoll erwiesen, aber auch die Wiederverwendung von abstraktem Wissen in Form von Architektur und Design Patterns spielt eine große Rolle.

Das Generative Programming, in der hier vorgestellten Form, wurde von Krzysztof Czarnecki im Jahr 1998 in seiner Dissertation [1] zum ersten Mal umfas- send dargestellt und im Zusammenhang mit Domain Engineering als systematischer Ansatz zur Entwicklung von Softwarefamilien vorgeschlagen. Daher sollen im fol- genden Teil ein Überblick über die Konzepte und Herangehensweisen des Domain Engineerings gegeben werden.

2.2 Domain Engineering

Nicht nur Produktfamilien teilen viele Eigenschaften und Charakteristika, sondern ganz allgemein natürlich auch Systeme, die in einer gemeinsamen Problemdomäne arbeiten, da sie meist einen großen Teil an Anforderungen gemeinsam haben. Um aus dieser Tatsache nutzen ziehen zu können, wurde mit dem Domain Engineering ein Vorgehen entwickelt, was dazu dienen soll, wiederverwendbare Artefakte aus einer Domäne zu sammeln, zu organisieren und für die Entwicklung zukünftiger Systeme nutzbar zu machen. Dies ermöglicht es einem Unternehmen Wissen aus einer Domä- ne, welches in früheren Projekten gewonnen wurde in Projekte einfließen zu lassen, die in der selben Domäne liegen. Dies wiederum eröffnet die Möglichkeiten neue Produkte in kürzerer Zeit und damit mit geringeren Kosten zu entwickeln.

Das Domain Engineering als systematischer Ansatz zum Erreichen dieses Ziels, besteht aus drei Hauptphasen. In der ersten Phase der Domain Analysis wird eine Menge von wiederverwendbaren Anforderungen für Systeme in dieser Domäne auf- gestellt. Beim Domain Design ist es das Ziel eine Architektur bzw. Architekturen zu entwickeln, die für Systeme in dieser Domäne genutzt werden können. In der letzten Phase, der Domain Implementation sollen u.a. wiederverwendbare Komponenten, domänenspezifische Sprachen (DSL – domain-specific languages),Generatoren, also eine Infrastruktur zur Wiederverwendung geschaffen werden.

In Abb. 1 ist der Zusammenhang zwischen dem herkömmlichen Entwicklungspro- zess für einzelne Softwaresysteme und dem Domain Engineering veranschaulicht. Kurz gesagt, liefert das Domain Engineering wichtige Elemente für den Entwick- lungsprozess aus einer Domäne, die beliebig in Projekten der selben Domäne wiederverwendet werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1. Ein Softwareentwicklungsprozess unter Einbindung von Domain Engineering (aus [1])

An dieser Stelle soll die Phase der Domain Analysis noch von weiterem Interesse sein, da im folgenden Abschnitt auf die spezielle Methodik der Feature-oriented Domain Analysis eingegangen wird. Allgemein ist die Domänenanalyse ein systema- tischer Ansatz zum Abgrenzen der Problemdomäne, dem Erfassen von wesentlichen Merkmalen, sogenannten Features, und den Variationspunkten wiederverwendbarer Software. Sie basiert dabei auf der Analyse von bestehenden Anwendungen, den beteiligten Stakeholdern und anderen Quellen. Die Analyse erlaubt dabei nicht nur das Erkennen von unmittelbar, sondern auch potenziell relevanten Features. Das frühe Erkennen potenzieller Features macht es so möglich ein robustes und skalierbares Design zu entwickeln, welches als Grundlage für eine Produktfamilie dienen kann.

Nach [1] ist der wichtigste Beitrag des Domain Engineerings aus Sicht der objekto- rientierten Analyse- und Designmethoden die Technik der Feature-Modellierung, wobei diese zur Analyse und Erfassung von gemeinsamen und unterschiedlichen Merkmalen und ihrer Zusammenhänge in Systemen aus Produktfamilie genutzt wird.

2.3 Feature-Oriented Domain Analysis

Im Jahre 1990 entstand unter Leitung von Kyo-Chul Kang am Software Engineering Institute der Carnegie Mellon University die Feature-oriented Domain Analysis (FODA) als eine Methode zur Domänenanalyse, welche die Technik der Feature- Modellierung als zentralen Bestandteil beinhaltet.

Das Vorgehen gliedert sich bei dieser Methodik in zwei Phasen, in die der Kon- text-Analyse und die der Domänenmodellierung. Bei der Kontext-Analyse ist das Hauptziel die Eingrenzung der zu analysierenden Domäne. Dazu werden die Bezie- hungen zwischen der Problemdomäne und anderen Domänen bzw. den Domänenelementen nach dem Gesichtspunkt der Variabilität analysiert. Das Ergebnis dieser Analyse wir zusammen mit anderen Faktoren, wie z.B. der bereits gemachten Erfahrungen in dieser Problemdomäne und den Bedingungen des Projekts, zur Ein- grenzung der Problemdomäne genutzt. Nach [1] können die Resultate dieser Kontextanalyse in Form eines Kontextmodells dokumentiert werden. Solch ein Kon- textmodell kann sich dabei aus einem Strukturdiagramm zur Veranschaulichung des Aufbaus und einem Kontextdiagramm zur Darstellung von Informationsflüssen zu- sammensetzen.

Die Phase der Domänenmodellierung lässt sich selbst auch noch einmal in drei Schritte unterteilen. Im ersten Schritt, der Information Analysis wird das Domänen- wissen anhand von Entitäten erfasst und untereinander in Beziehung gebracht. Zu diesem Zweck lassen sich z.B. Modellierungstechniken wie E/R-Diagramme oder objektorientierte Klassendiagramme einsetzen. Der zweite Schritt, die Feature Analy- sis, ermittelt die Fähigkeiten einer Anwendung aus Anwendersicht. Es werden die Gemeinsamkeiten und Unterschiede verwandter Systeme einer Domäne in Form von Features erfasst. Der abschließende Schritt der Operational Analysis, soll die Bezie- hungen zwischen den erfassten Entitäten und Features herstellen, um die Arbeitsweise der Anwendung in der Domäne angeben zu können.

An dieser Stelle soll der Schwerpunkt auf die Feature-Modellierung gelegt werden, für die letztendlich die Notation in Form von Feature-Diagrammen relevant wird. Der wichtigste Begriff den es zunächst zu klären gibt, ist dabei der Begriff des Features. In [1] wird ein Feature als eine unterscheidbare Charakteristik eines Konzepts defi- niert, die relevant für einen Stakeholder des Konzepts ist. Ein Konzept ist dabei als eine Abstraktion von Basiselementen der Problemdomäne, z.B. ein System oder eine Komponente ,zu verstehen und wird durch seine Merkmale bzw. Features beschrie- ben. Mit diesen beiden Mitteln lässt sich nun die Struktur einer Domäne beschreiben. Es werden die gemeinsamen und variablen Features eines Konzepts dargestellt und zueinander in Beziehung gebracht.

Ein Feature-Modell besteht aber nicht nur aus einem Feature-Diagramm, sondern auch aus den projektrelevanten Zusatzinformationen. So ist eine Kurzbeschreibung der Features für das spätere Verständnis notwendig, aber es sollten u.a. auch Randbe- dingungen und Prioritäten dokumentiert werden, um z.B. das Interesse der Stakeholder bzw. Kunden an bestimmten Features auszudrücken.

Der Vorteil dieser Herangehensweise ist, dass alle relevanten Features und Variati- onspunkte von vornherein erfasst und somit in eine Produktfamilie aufgenommen werden können. Ein konkretes Produkt bzw. System aus dieser Familie wird jedoch nur die relevanten Features beinhalten. Damit wird der Aufwand und die Komplexität bei der Entwicklung und Anpassung reduziert, was die anvisierten Verbesserungen in Bezug auf die Effizienz mit sich bringt. Die FODA ist damit eine Schlüsseltechnik zum Identifizieren und Aufnehmen von Variabilität in Produktfamilien bzw.