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

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

English
190 Pages
Read
Download
Downloading requires you to have access to the YouScribe library
Learn all about the services we offer

Description

The Feature-Architecture Mapping Methodfor Feature-Oriented Development ofSoftware Product LinesDissertationsschriftzur Erlangung des akademischen GradesDoktoringenieur (Dr.-Ing.)˜ ˜VORGELEGT DER FAKULTAT FUR INFORMATIK UND AUTOMATISIERUNG˜DER TECHNISCHEN UNIVERSITAT ILMENAUvon MSc Periklis Sochosgeboren am 17. Dezember 1978 in Athen, Griechenlandvorgelegt am 20.9.2006wissenschaftliche Aussprache am 25.04.2007Gutachter:1. PD Dr.-Ing. habil. Matthias Riebisch2. Univ.-Prof. Dr.-Ing. habil. Wolfgang Fengler3. Prof. Dr. rer. nat. Ralf H. Reussnerurn:nbn:de:gbv:ilm1-2007000087The Feature-Architecture Mapping Methodfor Feature-Oriented Development ofSoftware Product LinesDissertationfor the attainment of the academic degree ofDoktoringenieur (Dr.-Ing.)SUBMITTED AT THE FACULTY OF INFORMATICS AND AUTOMATIONOF THE TECHNICAL UNIVERSITY OF ILMENAUby MSc Periklis Sochosborn on the 17th of December 1978 in Athens, Greecesubmitted on the 20.9.2006convocation on the 25.04.2007Examiners:1. PD Dr.-Ing. habil. Matthias Riebisch2. Univ.-Prof. Dr.-Ing. habil. Wolfgang Fengler3. Prof. Dr. rer. nat. Ralf H. Reussnerurn:nbn:de:gbv:ilm1-2007000087AbstractSoftware 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 andhigh exibility.

Subjects

Informations

Published by
Published 01 January 2007
Reads 11
Language English
Document size 3 MB
Report a problem

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 . . . . . . . . . . . . . . . . . . . . . . . . . . 156
5.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6 Conclusions 161
6.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
A NN-Trainer Feature Models 165
B NN-Trainer Features Speciflcation 168
C NN-Trainer Software Architecture 171List of Figures
2.1 A common development process of a PL . . . . . . . . . . . . . . . . 6
2.2 A basic FM of a mobile phone PL . . . . . . . . . . . . . . . . . . . 8
2.3 Historical evolution of PL methods . . . . . . . . . . . . . . . . . . . 9
2.4 An overview of the FeatuRSEB processes . . . . . . . . . . . . . . . 13
2.5 AtypicalFeatuRSEBlayeredarchitectureanditsrelationtotheFea-
tuRSEB processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Relations and internals of application and component systems . . . . 15
2.7 The dimensions and types of the FeatuRSEB analysis model. . . . . 16
2.8 TheWithdrawMoneyusecaseandthecorrespondingpartialanalysis
model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.9 Scattering and tangling of the Withdraw and Deposit features . . 19
2.10 An architecture based on the direct derivation from features . . . . . 20
2.11 Feature-architecture mapping in FeatuRSEB . . . . . . . . . . . . . 21
2.12 Binding times of PL product variants. . . . . . . . . . . . . . . . . . 22
2.13 UML diagram of the Strategy design pattern . . . . . . . . . . . . . 29
2.14 The Quality-oriented Software Architecture design (QASAR) method 32
2.15 Artifacts of the FAD method . . . . . . . . . . . . . . . . . . . . . . 33
2.16 Interfaces of the flre-alarm system . . . . . . . . . . . . . . . . . . . 34
2.17 Archetypes of the PL and their relations . . . . . . . . . . 36
2.18 FAD dimensions of decomposition with examples . . . . . . . . . . . 38
2.19 A partial view of the architectural components of the flre-alarm system 39
2.20 A partial view of the flre-alarm FM with the mapping between the
PL features (left) and FAD architectural components (right) . . . . . 41
2.21 A more direct mapping between the flre-alarm features (left) and the
architecture (right) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
viiviii LIST OF FIGURES
2.22 Product-speciflc extension model . . . . . . . . . . . . . . . . . . . . 46
2.23 Standard-speciflc model . . . . . . . . . . . . . . . . . . . 46
2.24 Fine-grained extension model . . . . . . . . . . . . . . . . . . . . . . 47
2.25 Generator-based model . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.26 A simple Software Engineering Environment architecture . . . . . . 52
2.27 AdecompositionoftheSEEarchitecturebasedonitsfeaturesthrough
hyperslices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.1 A simplifled view of a biological neuron . . . . . . . . . . . . . . . . 69
3.2 An artiflcial neuron and a layer of neurons . . . . . . . . . . . . . . . 70
3.3 An artiflcial Neural Network. . . . . . . . . . . . . . . . . . . . . . . 71
4.1 FArM phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2 Direct Elementary Transformation . . . . . . . . . . . . . . . . . . . 79
4.3 Merge Elementary T . . . . . . . . . . . . . . . . . . . 80
4.4 Create Elementary Transformation . . . . . . . . . . . . . . . . . . . 80
4.5 TheHardwarefeaturehierarchyiscomposedofPhysicalNARfeatures 83
4.6 The OS feature hierarchy as External NAR features . . . . . . . . . 85
4.7 The NN-Export feature hierarchy . . . . . . . . . . . . . . . . . . . 86
4.8 The Competitive Market Price feature . . . . . . . . . . . . . . . 86
4.9 The Recoverability quality feature . . . . . . . . . . . . . . . . . . 89
4.10 TheRecoverability qualityfeaturetransformationwithtraceability
links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.11 The E–ciency quality feature . . . . . . . . . . . . . . . . . . . . . 91
4.12 Partial view of the features involved in the resolution of the E–-
ciency quality feature . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.13 The License feature used for the resolution of the External License
Manager architectural requirement . . . . . . . . . . . . . . . . . . . 96
4.14 The Train-Mode feature hierarchy . . . . . . . . . . . . . . . . . . 98
4.15 NN-Trainer uses interacts relations . . . . . . . . . . . . . . . . . . . 103
4.16 NN-Trainer extends interacts relations . . . . . . . . . . . . . . . . . 104
4.17 Transformation of the extends interacts relations . . . . . . . . . . . 105
4.18 NN-Trainer runtime excludes interacts relation . . . . . . . . . . . . 105
4.19 Transformation of the runtime excludes interacts relation . . . . . . 106