ST2 - Featuremodelle - Praktische Informatikpi.informatik.uni-siegen.de/lehre/2016s/2016s_st2_ueb/2016s_st2... · Practices and Patterns, 2006. Weiterführende ... Produktkonfiguration

Lehrstuhl Praktische Informatik

Softwaretechnik 2

Feature Modellierung

M. Sc. Dennis Reuling

[email protected]

Basierend auf der Vorlesung

„Software-Produktlinien – Konzepte und Implementierung“

Seit 2007 an der Universität Magdeburg (Prof. Saake)

Seit 2007 an der Universität Passau (Prof. Apel)

Seit 2013 an der TU Braunschweig (Dr. Schulze)

Seit 2014 an der TU Darmstadt (Dr. Lochau)

Sommersemester 2016 ST2 - Feature Modellierung 2

SPL Themenbereich

Apel et al.:Feature-Oriented Software Product Lines,

2013.

Hauptliteratur zu SPLE

Exemplar in der UB verfügbar

ISBN 978-3-642-37521-7


Literatur

Pohl et al.: Software Product Line Engineering, 2005.

Frei im Uni-Netz verfügbar(Springer Link)

ISBN 978-3-540-28901-2


Literatur

P. Clements, L. M. Northup:

Software Product Lines:

Practices and Patterns, 2006.

Weiterführende Literatur

ISBN: 0-201-70332-7


Literatur

Software-Produktlinienentwicklung

Entwicklungsprozess von Software-Produktlinien

Variabilitätsmodellierung und

Produktkonfiguration im Problemraum

Formalismus und Analyse von Feature-Modellen

Variabilitätsmodellierung im Lösungsraum

Modellbasierte Produktlinien

Delta-basierte Variabilitätsmodellierung


Einordnung

• Feature-Modelle und deren Semantik im

Detail kennen

• Übersetzung von Feature-Diagrammen in

aussagenlogische Formeln

• Analysen von Feature-Modellen

durchführen können

(Anomalien/Vergleich)

• Konfigurationsprozesse verstehen


Lernziele


SPL ENGINEERING

(WIEDERHOLUNG)


A software product line is an explicit specification

of commonality and variability between

[product] variants in a family of similar [software]

products by means of features.

(Pohl et al., 2005)

Produktlinien als Methode


SPLE

● Ziel: Entwicklung einer Produktfamilie als Produktlinie

statt als einzelne Produkte

● Produktlinie deckt Anforderungen (Features) der ganzen

Domäne ab

● Abweichung vom klassischen Entwicklungsprozess und

Lebenszyklus, Unterscheidung in

– Domain Engineering

– Application Engineering


# Produkte

Aufwand/Kosten

Konventionelle

Entwicklung

Produktlinien-

entwicklung

1 2 3 4 …

Development Effort



ÜbersichtD

om

ain

En

g.

Ap

plic

ati

on

En

g.

Feature-Auswahl

Feature-Modell Wiederverwendbare

Implementierungs-

artefakte

Generator Fertiges Program

[...] is the activity of collecting, organizing, and

storing past experience in building systems [...] in a

particular domain in the form of reusable assets

[...], as well as providing an adequate means for

reusing these assets (i.e., retrieval, qualification,

dissemination, adaptation, assembly, and so on)

when building new systems.

(K. Czarnecki and U. Eisenecker)

Domain Engineering


[…] has the goal of developing a specific product for the needs of a particular customer.It corresponds to the process of single application development in traditional software engineering, but reuses artifacts from domain engineering where possible.

[…] is repeated for every product of the product line that is to be derived.


(Apel et al.)

Application Engineering

Idee: Feature als ganzheitliches Abstraktionskonzept

• Feature als Domänen-Abstraktion im Problemraum der

Anwendungsdomäne

=> Spezifikation von Produktkonfigurationen

(Feature-Auswahl als Eingabe für die Produktkonfiguration)

• Feature als Implementierungskonzept im

Lösungsraum der Produktlinie

=> Spezifikation von Produktvarianten

(Feature-Auswahl als Eingabe für die Programmgenerierung)

Feature-Oriented SPLE (FOSD)



FEATURE-MODELLE



EinordnungD

om

ain

En

g.

Ap

plic

ati

on

En

g.

Feature-Auswahl


Implementierungs-

artefakte


Feature-Modelle spezifizieren den

Konfigurationsraum einer Produktlinie:

Menge der konfigurierbaren

Produktparameter:

relevante Domain Features im Problemraum

der Produktlinie

Einschränkung der Kombinierbarkeit von

Features in validen Produktkonfigurationen

durch Abhängigkeiten zwischen Features


Übersicht (1)

Darstellungsformen

Explizite Auflistung aller validen Konfigurationen: Konfigurationstabellen

Graphisch: Entscheidungsbäume, FODA Feature-Diagramme, Orthogonal Variability Model (OVM), …

Mathematisch: Aussagenlogische Terme (SAT), Constraint Satisfiability Problems (CSP), Binary Decision Diagrams (BDD), …


Übersicht (2)


PPU KonfigurationstabelleFeatures Valide Konfigurationen

FODA Feasibility Study[Kang et al., 1990]



PPU Feature-Diagramm

FeatureGruppe

(Cross-Tree)Constraint

Die Feature-Hierarchie bildet einen Wurzelbaum auf der Menge der Features

Das Wurzel-Feature ist per Konvention obligatorisch (engl.mandatory) und bezeichnet den Namen der Produktlinie (Konzept-Feature)

Jedes einzelne Kind-Feature ist entweder obligatorisch oder optional

=> Abhängigkeiten zwischen Nachbar-Features durch Feature-Gruppen

Feature-Hierarchie


Unter einem Eltern-Feature können mehrere Gruppen und Einzel-Features hängen

Zwei Arten von Gruppen: Alternativ (XOR) und Oder (OR)

Einzel-Features und Feature-Gruppen dürfen sich nicht überlappen

Häufig auch: Mandatory-Gruppen und Optional-Gruppen

Abhängigkeiten zwischen hierarchisch unkorreliertenFeatures durch Cross-Tree-Constraints

Feature-Gruppen


Cross-Tree Constraints

Cross-Tree Kanten können beliebig „quer“ zur Feature-Hierarchie verlaufen

Verallgemeinerung auf beliebige Cross-Tree Constraints in Form von aussagenlogischen Termen über Features


Mögliche Erweiterungen Gruppenkardinalitäten

Nicht-Boole‘sche Features

Abstrakte Features(nicht in Konfig. sichtbar undohne Mapping)

Feature-Kardinalitäten(Mehrfachinstanziierung)

ElternFeature

Feature 1 Feature n…

[k..l]

Feature

a : intb : { low, med, high }

Feature

Feature

[3..*]


Erstellung von Feature-Diagrammen in FODA-ähnlicher Notation

Semantische Analysen: Anzahl Produktkonfiguration, Anomalien, …

Mapping in den Lösungsraum (CPP, FOP, AOP, …)


Feature-Modell Editor: FeatureIDE

=> Übung(en)

[Leich et al., 2005]


FEATURE-MODELL ANALYSEN


Feature-Modell Semantik

Konfigurationsraum und Analysen

Generierung von Produkten



Feature-Model Analysis Survey [Benavides et al., 2009]


Analyse von FMs (1)

f1

<<exclude>>

f0

f2

f1

<<require>>

f0

f2

f1

<<exclude>>

f0

f2

[Schobbens et al, 2006, Benavides et al., 2010]


Mandatory vs Core Features

Ein mandatory Feature ist nicht zwangsläufig ein core Feature:

Ein core Feature ist nicht zwangsläufig ein mandatory Feature:

=> f3 ist ein false optional feature(entsprechendes gilt für dead features)

f2

f1

f0

f3

<<require>>

f0

f2


Problem: „Versteckte“ Anomalien

f0

f4 f5 f1

f3 f2

<<require>> <<exclude>>

Dead feature

core

false optional

false optionalcore

false optional


Analyse von FMs (2)

f2

f1

f3FM = k = ?


Vergleich von FMs (1)[Thüm et al., 2008]

f1

<<exclude>>

f0

f2f1

f0

f2?

FM1 FM2


Kategorien

No Configs. added Configs. added

No Configs.deleted

Refactoring Generalization

Configs. deleted

Specialization Arbitrary Edit


PPU Beispiele


Aussagenlogische FD-Semantik[Batory, 2005]


Übersetzung von Feature-Diagrammen


Beispiel

FM

f4

f0

f1 f2 f3

<<exclude>>

∨


FM-Analyse durch SAT-Solver

Das SAT Problem ist NP-vollständig !


Ausdrucksmächtigkeit von

Feature-Diagrammen

Für jeden möglichen validen Konfigurationsraum über

einer Menge F von Features gibt es mindestens ein

Feature-Diagramm, das genau diese Konfigurationsmenge

spezifiziert.


Vergleich von FMs (2)[Bürdek et al., 2015]


KONFIGURATIONSPROZESSE



EinordnungD

om

ain

En

g.

Ap

plic

ati

on

En

g.

Feature-Auswahl


Implementierungs-

artefakte


GUIDSLFeatureIDE


Produktkonfiguration


Produktkonfiguration durch Feature-Selektion

BCS

AutPw

ManPw

CLS

<<exclude>>

RCK

CtrlPw

BCS

AutPw

ManPw

CLS

<<exclude>>

RCK

CtrlPw

BCS

AutPw

ManPw

CLS

<<exclude>>

RCK

CtrlPw

….

select

deselect

p = { BCS, ManPw, RCK } p‘ = { BCS, AutPw, CLS, RCK, CtrlPw }


Konfigurationsprozess Produkte werden schrittweise in einem Konfigurationsprozess konfiguriert

In jedem Konfigurationsschritt wird durch eine Konfigurationsoperation ein Feature an- oder abgewählt

BCS

AutPw

ManPw

CLS

<<exclude>>

RCK

CtrlPw

{ } { BCS } { BCS }+BCS -AutPw

{ BCS, ManPw }+ManPw

{ BCS, ManPw }-CLS

{ BCS, ManPw, RCK }+RCK

{ BCS, ManPw, RCK }-CtrlPw


Eigenschaften von Konfigurationsprozessen


Konfigurationsschritte (1)

1. Explizite Konfigurationsentscheidungen

2. Invalide Konfigurationsentscheidungen

BCS

AutPw

ManPw

CLS

<<exclude>>

RCK

CtrlPw

BCS

AutPw

ManPw

CLS

<<exclude>>

RCK

CtrlPw

BCS

AutPw

ManPw

CLS

<<exclude>>

RCK

CtrlPw


Konfigurationsschritte (2) 3. Implizite Konfigurationsentscheidungen

Core Features können immer automatisch angewählt werden

Analog: Dead Features können immer automatisch abgewählt werden

BCS

AutPw

ManPw

CLS

<<exclude>>

RCK

CtrlPw


Konfigurationsschritte (3)

Bereits getroffene Konfigurationsentscheidungen implizieren weitere Konfigurationsentscheidungen (Multi-Steps)

BCS

AutPw

ManPw

CLS

<<exclude>>

RCK

CtrlPw

Systematisierung: Algorithmus zur Ableitung valider Konfigurationssequenzen

{ BCS, CLS, RCK } { BCS, CLS, RCK, ManPw }+ManPw -AutPw -CtrlPw

Berechnung von Multi-Steps (1/5)

f ?Sommersemester 2016 ST2 - Feature Modellierung 53


3. Entscheidung über Feature-Hierarchie propagieren:

Bei Feature-Anwahl +f: (rekursiv) alle Eltern-Features von f bis

zum Wurzel-Feature anwählen

Bei Feature-Abwahl –f: (rekursiv) alle Kind-Features von f bis zu

den Blättern abwählen

f

f

root

f‘



4. Behandlung von Mandatory Features:

Angewähltes Feature +f hat ein mandatory Kind-Feature f‘: Kind-

Feature ebenfalls anwählen

Abgewähltes Feature –f ist ein mandatory Kind-Feature von

Eltern-Feature f‘: Eltern-Feature ebenfalls abwählen

f‘

f

f

f‘



5. Behandlung von Feature-Gruppen:

Angewähltes Feature +f ist Teil einer Alternativ-Gruppe

Ein anderes Feature f‘ ist bereits gewählt: error

Sonst: Alle anderen Features der Gruppe werden

abgewählt

Abgewähltes Feature –f ist Teil einer Alternativ/Or-Gruppe

Der Elternknoten ist nicht abgewählt und alle anderen

Features der Gruppe sind abgewählt: error

f‘‘

f f‘

f‘‘

f f‘

f‘‘

f f‘



6. Behandlung von Cross-Tree-Constraints:

Angewähltes Feature +f benötigt ein Feature f‘: Feature f‘

ebenfalls anwählen

Abgewähltes Feature –f wird von einem Feature f‘ benötigt:

Feature f‘ ebenfalls abwählen

Angewähltes Feature +f steht in Konflikt mit einem anderen

Feature f‘: Feature f‘ abwählen

f‘

<<exclude>>

f

f‘

<<require>>

f

f

<<require>>

f‘


Eigenschaften von Konfigurationsprozessen

Soundness und Liveness:

Konfigurationsprozesse, deren Schritte mit dem Multi-Step-Algorithmus ohne Fehler-Schritt erzeugt werden, enden immer in einer validen Produktkonfiguration.

Completeness:

Zu jeder validen Produktkonfiguration gibt es mindestens einen Konfigurationsprozess, dessen Schritte mit dem Multi-Step-Algorithmus ohne Fehler-Schritt produziert werden können.

[Lochau, 2013]

Anmerkung:Zur einer validen Konfiguration gibt es in der Regel mehrere mögliche Konfigurationsprozesse, die sich in der Reihenfolge der Konfigurationsschritte unterscheiden.


Kyo C. Kang, Sholom G. Cohen, James A. Hess, William E. Novak, and A. Spencer Peterson.Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical report, Carnegie-Mellon University Software Engineering Institute, November 1990.

Thomas Leich, Sven Apel, Laura Marnitz, and Gunter Saake. Tool Support for Feature-orientedSoftware Development: FeatureIDE: an Eclipse-based Approach. In Proceedings of the OOPSLA workshop on Eclipse technology eXchange, eclipse ’05, pages 55–59, New York, NY, USA, 2005. ACM.

David Benavides, Sergio Segura, and Antonio Ruiz-Cortés. Automated Analysis of Feature Models 20 Years Later: A Literature Review. Advanced Information Systems Engineering, 35:615–636, September 2010.

Pierre-Yves Schobbens, Patrick Heymans, and Jean-Christophe Trigaux. Feature Diagrams: A Survey and a Formal Semantics. In Requirements Engineering, 14th IEEE International Conference, pages 139 –148, sept. 2006.

Thomas Thüm, Don Batory, and Christian Kästner. Reasoning about Edits to Feature Models. In Proceedings of the IEEE 31st International Conference on Software Engineering, pages 254–264, Washington, DC, USA, 2009. IEEE Computer Society.

Don Batory. Feature Models, Grammars, and Propositional Formulas. In SPLC, pages 7–20. Springer, 2005.

Johannes Bürdek, Timo Kehrer, Malte Lochau, Dennis Reuling, Udo Kelter, Andy Schürr: Reasoning about Product-Line Evolution using Complex Differences on Feature Models. In Journal of ASE ,2015.

Arnaud Hubaux: Feature-based Configuration: Collaborative, Dependable, and Controlled.PhD thesis, University of Namur, Belgium, 2012.


Referenzen

ST2 - Featuremodelle - Praktische Informatikpi.informatik.uni-siegen.de/lehre/2016s/2016s_st2_ueb/2016s_st2... · Practices and Patterns, 2006. Weiterführende ... Produktkonfiguration

Documents