The feature architecture mapping method for feature oriented development of software product lines [Elektronische Ressource] / von Periklis Sochos

Sujets

• Informatik

Informations

• Publié par: technische_universitat_ilmenau
• Publié le: 01 janvier 2007
• Nombre de lectures: 8
• Langue: English
• Poids de l'ouvrage: 3 Mo

Extrait

The Feature-Architecture Mapping Method
for Feature-Oriented Development of
Software Product Lines
Dissertationsschrift
zur Erlangung des akademischen Grades
Doktoringenieur (Dr.-Ing.)
˜ ˜VORGELEGT DER FAKULTAT FUR INFORMATIK UND AUTOMATISIERUNG
˜DER TECHNISCHEN UNIVERSITAT ILMENAU
von MSc Periklis Sochos
geboren am 17. Dezember 1978 in Athen, Griechenland
vorgelegt am 20.9.2006
wissenschaftliche Aussprache am 25.04.2007
Gutachter:
1. PD Dr.-Ing. habil. Matthias Riebisch
2. Univ.-Prof. Dr.-Ing. habil. Wolfgang Fengler
3. Prof. Dr. rer. nat. Ralf H. Reussner
urn:nbn:de:gbv:ilm1-2007000087The Feature-Architecture Mapping Method
for Feature-Oriented Development of
Software Product Lines
Dissertation
for the attainment of the academic degree of
Doktoringenieur (Dr.-Ing.)
SUBMITTED AT THE FACULTY OF INFORMATICS AND AUTOMATION
OF THE TECHNICAL UNIVERSITY OF ILMENAU
by MSc Periklis Sochos
born on the 17th of December 1978 in Athens, Greece
submitted on the 20.9.2006
convocation on the 25.04.2007
Examiners:
1. PD Dr.-Ing. habil. Matthias Riebisch
2. Univ.-Prof. Dr.-Ing. habil. Wolfgang Fengler
3. Prof. Dr. rer. nat. Ralf H. Reussner
urn:nbn:de:gbv:ilm1-2007000087Abstract
Software product lines are the answer of software engineering to the increas-
ing complexity and shorter time-to-market of contemporary software systems.
Nonetheless, software product lines demand for advanced maintainability and
high exibility. The latter can be achieved through the proper separation of
concerns. Features pose the main concerns in the context of software product
lines. Consequently, one feature should ideally be implemented into exactly one
architectural component. In practice, this is not always feasible. Therefore,
at least a strong mapping between features and the architecture must exist.
The state of the art product line development methodologies introduce signifl-
cant scattering and tangling of features. In this work, the Feature-Architecture
Mapping (FArM) method is developed, to provide a stronger mapping between
features and the product line architecture. FArM receives as input an initial
feature model created by a domain analysis method. The initial feature model
undergoes a series of transformations. The transformations strive to achieve a
balance between the customer and architectural perspectives. Feature interac-
tion is explicitly optimized during the feature model transformations. For each
featureofthetransformedfeaturemodel,onearchitecturalcomponentisderived.
The architectural components implement the application logic of the respective
features. The component communication re ects the feature interaction. This
approach, compared to the state of the art product line methodologies, allows
a stronger feature-architecture mapping and for higher variability on the fea-
ture level. These attributes provide higher maintainability and an improved
generative approach to product instantiation, which in turn enhances product
line exibility. FArM has been evaluated through its application in a number
of domains, e.g in the mobile phone domain and the Integrated Development
Environment (IDE) domain. This work will present FArM on the basis of a case
study in the domain of artiflcial Neural Networks.
iiKurzfassung
Software Produktlinien sind die Antwort von Software Engineering auf die zu-
nehmende Komplexit˜at und kurzeren˜ Produkteinfuhrungszeiten˜ von heutigen
Softwaresystemen. Nichtsdestotrotz erfordern Software Produktlinien eine fort-
geschritteneWartbarkeitundhoheFlexibilit˜at. Daskanndurchdieangemessene
Trennung der Belange erreicht werden. Merkmale stellen die Hauptbelange
im Kontext von Software Produktlinien dar. Demzufolge sollte ein Merkmal
idealerweise in genau einer Architekturkomponente implementiert werden. In
der Praxis ist das jedoch nicht immer machbar. Deshalb sollte zumindest ein
starkes Mapping zwischen Merkmalen und der Architektur bestehen. Die Meth-
oden zur Entwicklung von Software Produktlinien, die dem Stand der Tech-
nik entsprechen, fuhren˜ zu bedeutender Verstreutheit und Vermischung von
Merkmalen. In dieser Arbeit wird die Feature-Architecture Mapping (FArM)
Methode entwickelt, um ein st˜arkeres Mapping zwischen Merkmalen und der
Produktlinien-Architektur zu erzielen. Der Input fur˜ FArM besteht in einem
initialen Merkmalmodell, das anhand einer Methode zur Dom˜anenanalyse er-
stellt wurde. Dieses initiale Merkmalmodell wird einer Serie von Transforma-
tionen unterzogen. Die Transformationen streben danach, ein Gleichgewicht
zwischen der Sichtweise von Kunden und Softwarearchitekten einzustellen. Die
Merkmalinteraktionen werden w˜ahrend der Transformationen ausdruc˜ klich op-
timiert. Von jedem Merkmal des transformierten Merkmalmodells wird eine Ar-
chitekturkomponente abgeleitet. Die Architekturkomponenten implementieren
die Applikationslogik der entsprechenden Merkmale. Die Kommunikation zwis-
chen den Komponenten spiegelt die Interaktion zwischen den Merkmalen wider.
Dieser Ansatz fuhrt˜ im Vergleich zu den Produktlinien-Entwicklungsmethoden
des Stands der Technik zu einem st˜arkeren Mapping zwischen Merkmalen und
der Architektur und zu einer h˜oheren Variabilit˜at auf Merkmalebene. Diese
Eigenschaften haben eine bessere Wartbarkeit und eine vereinfachte generative
Produktinstanzierung zur Folge, was wiederum die Flexibilit˜at der Produktlin-
ien steigert. FArM wurde durch ihre Anwendung in einigen Dom˜anen evaluiert,
z.B. in den Dom˜anen von Mobiltelefonen und Integrierten Entwicklungsumge-
bungen(IDEs). DieseArbeitwirdFArManhandeinerFallstudieinderDom˜ane
von Kunstlic˜ hen Neuronalen Netzwerken pr˜asentieren.
iiiAcknowledgements
IwouldliketothankmysupervisorsProf. Dr.-Ing. habil. IlkaPhilippowandPriv.-Doz. Dr.-
Ing. habil. Matthias Riebisch for their guidance throughout this work, as well as the federal
state of Thuringen˜ for the flnancial support through the granting of the Landesgraduierten
scholarship. A big thank goes also to my professor and supervisor during my studies in
Greece Prof. Dr.-Ing. Basilios Spiropoulos.
Last but not least, I want to thank my family for their loving support that made this work
possible.
ivContents
1 Introduction 1
2 State of the Art 4
2.1 Software Product Lines . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Product Lines Methods . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Featured Reuse-Driven Software Engineering Business . . . . . . . . 12
2.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Component Sources & Mapping. . . . . . . . . . . . . . . . . 14
2.3.3 Feature-Level Variability. . . . . . . . . . . . . . . . . . . . . 22
2.3.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4 Functionality-based Architectural Design. . . . . . . . . . . . . . . . 31
2.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.2 Fire-Alarm PL Case Study . . . . . . . . . . . . . . . . . . . 32
2.4.3 FAD Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.4 Evaluation of Component Development . . . . . . . . . . . . 39
2.4.5 Object-Oriented Frameworks . . . . . . . . . . . . . . . . . . 43
2.4.6 Evaluation of Framework Component Models . . . . . . . . . 47
2.4.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.5 Generative Programming Techniques . . . . . . . . . . . . . . . . . . 50
2.5.1 The Hyperspace Approach. . . . . . . . . . . . . . . . . . . . 51
2.5.2 Evaluation of the Hyperspace Approach . . . . . . . . . . . . 59
2.5.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.6 Motivation and Objectives . . . . . . . . . . . . . . . . . . . . . . . . 63
2.7 Used Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
vvi CONTENTS
3 Case Study 68
3.1 Neural Network Theory . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.2 NN-Trainer PL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4 The Feature-Architecture Mapping Method 74
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2 Elementary Transformations . . . . . . . . . . . . . . . . . . . . . . . 78
4.3 NAR & Quality Features . . . . . . . . . . . . . . . . . . . . . . . . 81
4.3.1 Non-Architecture-Related (NAR) Features. . . . . . . . . . . 81
4.3.2 Quality Features . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.4 Architectural Requirements . . . . . . . . . . . . . . . . . . . . . . . 93
4.5 Feature Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.5.1 Identiflcation . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.5.2 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.5.3 Interface Derivation . . . . . . . . . . . . . . . . . . . . . . . 123
4.6 Architecture Development . . . . . . . . . . . . . . . . . . . . . . . . 129
4.7 Tool Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5 Evaluation 139
5.1 Method Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
5.2 Feature-Architecture Mapping . . . . . . . . . . . . . . . . . . . . . . 142
5.3 Feature-Level Variability . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.4 Product Instantiation . . . .