software product lines - es.tu-darmstadt.de · bcs: features und constraints domain analysis...

© author(s) of these slides 2008 including research results of the research network ES and TU Darmstadt otherwise as specified at the respective slide

19.05.2014

ES Real-Time Systems Lab

Prof. Dr. rer. nat. Andy Schürr

Dept. of Electrical Engineering and Information Technology

Dept. of Computer Science (adjunct Professor)

www.es.tu-darmstadt.de

Software Product Lines Concepts, Analysis and Implementation

Dr. rer. nat. Malte Lochau

[email protected]

Feature-Modelle und Produktkonfiguration

ES – Real-Time Systems Lab 2 | 19.05.2014 | Software Product Lines - Concepts, Analysis and Implementation

I. Einführung

Motivation und Grundlagen

Feature-orientierte Produktlinien

II. Produktlinien-Engineering

Feature-Modelle und Produktkonfiguration

Variabilitätsmodellierung im Lösungsraum

Programmierparadigmen für Produktlinien

III. Produktlinien-Analyse

Feature-Interaktion

Testen von Produktlinien

Verifikation von Produktlinien

IV. Fallbeispiele und aktuelle Forschungsthemen

Inhalt

Feature Diagramme

Feature Model Semantik

und Analyse

Konfigurationsprozesse


Software-Product-Line Engineering D

om

ain

En

g.

Ap

pli

ca

tio

n E

ng

.

Feature-Auswahl

Feature-Modell Wiederverwendbare

Implementierungs-

artefakte

Generator Fertiges Program


Feature-Modelle im Alltag


Feature-Modelle: Einführung

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

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), …


Feature-Liste • HMI • LED • Fensterheber • Einklemmschutz • Alarmanlage • Innenraumüberwachung • Zentralverriegelung • Remote Key • ….

BCS: Features und Constraints

Domain

Analysis

Feature-Abhängigkeiten und Constraints • „das optional wählbare Status-LED-

Panel des HMI besteht aus mindestens einer LED-Anzeige“

• „der Fensterheber ist entweder manuell oder automatisch“

• „Der Außenspiegel kann als beheizbar konfiguriert werden“

• „Alle Sicherheitsfunktionen sind optional“

• „Der manuelle Fensterheber eignet sich nicht zur Fernsteuerung mit dem Remote Key“


Beispiel: BCS Konfigurationstabelle

Spalten: valide

Produktkonfigurationen

Zeilen: Features

… P11.767!!!

Produktkonfiguration P6

enthält Feature CLS

…


FODA Feasibility Study (1990)


Feature Diagramme

Baumartige Anordnung der Domain Features (Knoten)

Abhängigkeiten zwischen Feature-Knoten (Kanten, Gruppierung, …)

Graphische Notation nach Kang et al. [Kang et al., 1990]


Feature-Hierarchie

Syntax

Semantik

Zerlegen komplexer Features in Unter-Features

Die Auswahl des Kind-Features ist nur möglich, wenn das Eltern-Feature ausgewählt ist

Beispiel

Valide Konfigurationen

{ EM } { EM, E } { EM, H } { EM, E, H } { E, H } { E } { H }

Eltern

Feature

Kind

Feature

Exterior

Mirror

(EM)

Electric

(E)

Heatable

(H)


Feature-Modalitäten (1/2): Mandatory Features

Syntax

Semantik

Komposition komplexer Features aus festen Bestandteilen

Die Auswahl des Eltern-Features erzwingt die Auswahl des Kind-Features

Beispiel



Eltern

Feature

Kind

Feature

Exterior

Mirror

(EM)

Electric

(E)

Heatable

(H)


Feature-Modalitäten (2/2): Optionale Features

Syntax

Semantik

Aggregation komplexer Features aus optionalen Bestandteilen

Die Auswahl des Eltern-Features ermöglicht die Auswahl des Kind-Features

Beispiel



Eltern

Feature

Kind

Feature

Exterior

Mirror

(EM)

Electric

(E)

Heatable

(H)


Zusammenfassung: Feature-Hierarchie

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

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

Jedes einzelne Kind-Feature ist entweder mandatory oder optional

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


Feature-Gruppen (1/2): Alternativ-Gruppen

Syntax

Semantik

Zerlegen von Features in k sich gegenseitig ausschließende Alternativen

Die Auswahl des Eltern-Features erzwingt die Auswahl von genau einem Kind-Feature

Beispiel


{ PW } { PW, ManPW } { PW, AutPw } { PW, ManPW, AutPW } { ManPW, AutPW } { ManPW } { AutPW }

Eltern

Feature

Kind

Feature

1

Kind

Feature

k

Power

Window

ManPW AutPW …


Feature-Gruppen (2/2): Or-Gruppen

Syntax

Semantik

Zerlegen von Features in k beliebig kombinierbare Bestandteile

Die Auswahl des Eltern-Features erzwingt die Auswahl von mindestens einem Kind-Feature

Beispiel


{ LED }

{ LED, LED-CLS }

{ LED, LEP-FP }

{ LED, LED-CLS, LED-FP }

{ LED-CLS, LED-FP }

{ LED-CLS }

{ LED-FP }

Eltern

Feature

Kind

Feature

1

Kind

Feature

k

…

LED

LED-

CLS

LED-

FP


Zusammenfassung: Feature-Gruppen

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

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

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

Abhängigkeiten zwischen hierarchisch unkorrelierten Features durch Cross-Tree-Constraints


Cross-Tree-Constraints (1/2): Require-Kanten

Syntax

Semantik

Abhängigkeiten zwischen hierarchisch unkorrelierten Features

Die Auswahl von Feature 1 erzwingt die Auswahl von Feature 2

Beispiel


{ LED-Heatable }

{ LED-Heatable, Heatable }

{ Heatable }

Feature 1 Feature 2

… Heatable

LED

Heatable


Cross-Tree-Constraints (2/2): Exclude-Kanten

Syntax

Semantik

Konflikt zwischen hierarchisch unkorrelierten Features

Die Features 1 und 2 schließen sich aus

Beispiel


{ ManPW }

{ ManPW, RCK-PW-COntrol }

{ RCK-PW-Control }

Feature 1 Feature 2

… RCK PW Control

ManPW


Zusammenfassung: Cross-Tree Constraints

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

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


Feature-Modelle: Erweiterungen Gruppenkardinalitäten

Nicht-Boole‘sche Features

Abstrakte Features (nicht in Konfig. sichtbar und ohne Mapping)

Feature-Kardinalitäten (Mehrfachinstanziierung)

Eltern

Feature

Feature 1 Feature n …

[k..l]

Feature

a : int

b : { low, med, high }

Feature

Feature

[3..*]

=> Übung


Example: Body Comfort System

Feature-Abhängigkeiten und Constraints • „das optional wählbare Status-LED-Panel des

HMI besteht aus mindestens einer LED-Anzeige“

• „der Fensterheber ist entweder manuell oder automatisch“

• „Der Außenspiegel kann als beheizbar konfiguriert werden“

• „Alle Sicherheitsfunktionen sind optional“ • „Der manuelle Fensterheber eignet sich nicht

zur Fernsteuerung mit dem Remote Key“


Document Management System (DMS)


FAME DBMS (Core)


Berkley DB


PicoDBMS (für Smartcards)


Coment DB (für Sensornetzwerke)


Storage Manager


Feature-Modell-Editor: FeatureIDE [Leich et al., 2005]

Erstellung von Feature-Diagrammen in FODA Notation

Semantische Analysen: Anzahl Produktkonfiguration, Anomalien, …

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

=> Übung


Feature-Modell Semantik

Configuration Space Enumeration

and Analysis

Product Configuration Derivation

and Validation

Automated Feature-Model Configuration and

Analysis requires Precise Configuration Semantics


Feature-Model Analysis Survey (Benavides et al.)


f1, f2, f3

Mengendarstellung der Feature-Modell-Semantik

f1, f2

f1

f1, f2, f3

F =

f2

f1

f3 FM = = [FM]

Konfigurationsraum

Valider Konfigurationsraum Feature-Modell über

Feature-Menge

Feature-Menge

Konfiguration

Valide Konfiguration

f1,f3

f3 f2

f1, f2

f1, f2, f3

f2,f3

ES – Real-Time Systems Lab 32 | 19.05.2014 | SPL VL

Analyse von Feature-Modellen (1/3) [Schobbens et al., 2005, Benavides et al., 2010]

f1

f0

f2

f1

f0

f2

f1

f0

f2


f2

Mandatory Features 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)

f1

f0

f3

f0

f2


Beispiel: „Versteckte“ Anomalien

f0

f4 f5 f1

f3 f2

dead

core

dead

core

core

dead


Analyse von Feature-Modellen (2/3)

f2

f1

f3 FM = k = ?


Analyse von Feature-Modellen (3/3) [Thüm et al., 2008]

f1

f0

f2 f1

f0

f2 ?


Vergleich von Feature-Modellen

No Configs. added Configs. added

No Configs.

deleted

Refactoring Generalization

Configs.

deleted

Specialization Arbitrary Edit


Aussagenlogische Feature-Modell-Semantik [Batory, 2005]


Übersetzung von Feature-Diagrammen

FODA Notation Aussagenlogischer Term

Wurzel-Feature

Optionales Feature

Mandatory Feature

Alternativ-Gruppe

Or-Gruppe

Require-Kante

Exclude-Kante

root

f0

f1

f0

f1

f0

f1 fk …

f0

f1 fk …

f0 f1

f0 f1


f4

Beispiel

f0

f1 f2 f3

FM

𝑓0 → 𝑓3 ∧


Feature-Modell-Analyse durch SAT-Solver

Das SAT Problem ist NP-complete


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.


Aktuelle Forschungsthemen

Feature-Model Mining: Automatisierte Generierung eines Feature-

Modells für eine Konfigurationsmenge

extraktives SPLE

Feature-Modell Komposition: Kombination von Feature-Modellen in

größere Feature-Modelle

Multi-SPL

Feature-Modell Slicing und Dekomposition: Reduktion / Zerlegung in

Teilmodelle mit explizit definierten Abhängigkeiten

skalierbare Analysen


Software-Product-Line Engineering D

om

ain

En

g.

Ap

pli

ca

tio

n E

ng

.

Feature-Auswahl

Feature-Modell Wiederverwendbare

Implementierungs-

artefakte

Generator Fertiges Program


GUIDSL FeatureIDE

Produktkonfiguration


Produktkonfiguration durch Feature-Selektion

BCS

Aut Pw

ManPw

CLS

RCK

CtrlPw

BCS

Aut Pw

ManPw

CLS

RCK

CtrlPw

BCS

Aut Pw

ManPw

CLS

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

Aut Pw

ManPw

CLS

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. Explizite Konfigurationsentscheidungen

2. Invalide Konfigurationsentscheidungen

BCS

Aut Pw

ManPw

CLS

RCK

CtrlPw

BCS

Aut Pw

ManPw

CLS

RCK

CtrlPw

BCS

Aut Pw

ManPw

CLS

RCK

CtrlPw



3. Implizite Konfigurationsentscheidungen

Core Features können immer automatisch angewählt werden

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

BCS

Aut Pw

ManPw

CLS

RCK

CtrlPw



Bereits getroffene Konfigurationsentscheidungen implizieren weitere Konfigurationsentscheidungen (Multi-Steps)

BCS

Aut Pw

ManPw

CLS

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 ?



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‘

f

f‘

f

f

f‘


Eigenschaften von Konfigurationsprozessen

Soundness und Liveness: Konfigurationsprozesse, deren Schritte mit dem Multi-Step-Algorithmus ohne Fehler-Schritt erzeugt werden, enden immer 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]

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


Staged Configuration [Czarnecki et al., 2005]

Konfigurationsentscheidungen werden Stakeholdern zugeordnet

Konfigurations-Stages (Views) werden in einer bestimmten Reihenfolge durchlaufen

Implizite Priorisierung von Stakeholder-Entscheidungen

Erweiterung um Multi-Steps und Workflow-Modelle [Hubaux et al., Mendonca et al.]


Referenzen (1/2) 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 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.

Thomas Leich, Sven Apel, Laura Marnitz, and Gunter Saake. Tool Support for Feature-oriented Software 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.

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.

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

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.


Referenzen (2/2) Krzysztof Czarnecki, Simon Helsen, and Ulrich Eisenecker: Staged Configuration

through Specialization and Multi-Level Configuration of Feature Models. In Software Process Improvement and Practice, 2005.

Arnaud Hubaux, Andreas Classen, and Patrick Heymans: Formal Modelling of Feature Configuration Workflows. In Proceedings of the 13th International Software Product Line Conference, 2009.

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

Marcilio Mendonca, Andrzej Wasowski, and Krzysztof Czarnecki: SAT-based Analysis of Feature Models is easy. In Proceedings of SPLC, pages 231–240, 2009.

Jules White, Brian Dougherty, Douglas C. Schmidt, and David Benavides: Automated Reasoning for Multi-step Feature Model Configuration Problems. In Proceedings of SPLC, pages 11–20. ACM Press, 2009.

software product lines - es.tu-darmstadt.de · bcs: features und constraints domain analysis...

Documents