Software Product Lines

Transkript

1 Software Product Lines Concepts, Analysis and Implementation Feature-Modelle und Produktkonfiguration 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) Dr. rer. nat. Malte Lochau author(s) of these slides 2008 including research results of the research network ES and TU Darmstadt otherwise as specified at the respective slide

2 Inhalt 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 Feature Diagramme Feature Model Semantik und Analyse Konfigurationsprozesse III. Produktlinien-Analyse Feature-Interaktion Testen von Produktlinien Verifikation von Produktlinien IV. Fallbeispiele und aktuelle Forschungsthemen Software Product Lines - Concepts, Analysis and Implementation

3 Application Eng. Domain Eng. Software-Product-Line Engineering Feature-Modell Wiederverwendbare Implementierungsartefakte Feature-Auswahl Generator Fertiges Program Software Product Lines - Concepts, Analysis and Implementation

4 Feature-Modelle im Alltag Software Product Lines - Concepts, Analysis and Implementation

5 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), Software Product Lines - Concepts, Analysis and Implementation

6 BCS: Features und Constraints Domain Analysis Feature-Liste HMI LED Fensterheber Einklemmschutz Alarmanlage Innenraumüberwachung Zentralverriegelung Remote Key Software Product Lines - Concepts, Analysis and Implementation 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

7 Beispiel: BCS Konfigurationstabelle P11.767!!! Spalten: valide Produktkonfigurationen Zeilen: Features Produktkonfiguration P6 enthält Feature CLS Software Product Lines - Concepts, Analysis and Implementation

8 FODA Feasibility Study (1990) Software Product Lines - Concepts, Analysis and Implementation

9 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] Software Product Lines - Concepts, Analysis and Implementation

10 Feature-Hierarchie Syntax Eltern Feature Beispiel Exterior Mirror (EM) Kind Feature Electric (E) Heatable (H) Semantik Zerlegen komplexer Features in Unter-Features Die Auswahl des Kind-Features ist nur möglich, wenn das Eltern- Feature ausgewählt ist Software Product Lines - Concepts, Analysis and Implementation Valide Konfigurationen { EM } { EM, E } { EM, H } { EM, E, H } { E, H } { E } { H }

11 Feature-Modalitäten (1/2): Mandatory Features Syntax Eltern Feature Beispiel Exterior Mirror (EM) Kind Feature Electric (E) Heatable (H) Semantik Komposition komplexer Features aus festen Bestandteilen Die Auswahl des Eltern-Features erzwingt die Auswahl des Kind- Features Software Product Lines - Concepts, Analysis and Implementation Valide Konfigurationen { EM } { EM, E } { EM, H } { EM, E, H } { E, H } { E } { H }

12 Feature-Modalitäten (2/2): Optionale Features Syntax Eltern Feature Beispiel Exterior Mirror (EM) Kind Feature Electric (E) Heatable (H) Semantik Aggregation komplexer Features aus optionalen Bestandteilen Die Auswahl des Eltern-Features ermöglicht die Auswahl des Kind- Features Software Product Lines - Concepts, Analysis and Implementation Valide Konfigurationen { EM } { EM, E } { EM, H } { EM, E, H } { E, H } { E } { H }

13 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 Software Product Lines - Concepts, Analysis and Implementation

14 Feature-Gruppen (1/2): Alternativ-Gruppen Syntax Beispiel Eltern Feature Power Window Kind Feature 1 Kind Feature k ManPW AutPW Semantik Valide Konfigurationen Zerlegen von Features in k sich gegenseitig ausschließende Alternativen Die Auswahl des Eltern-Features erzwingt die Auswahl von genau einem Kind-Feature Software Product Lines - Concepts, Analysis and Implementation { PW } { PW, ManPW } { PW, AutPw } { PW, ManPW, AutPW } { ManPW, AutPW } { ManPW } { AutPW }

15 Feature-Gruppen (2/2): Or-Gruppen Syntax Beispiel Eltern Feature LED Kind Feature 1 Kind Feature k LED- CLS LED- FP Semantik Valide Konfigurationen Zerlegen von Features in k beliebig kombinierbare Bestandteile Die Auswahl des Eltern-Features erzwingt die Auswahl von mindestens einem Kind-Feature Software Product Lines - Concepts, Analysis and Implementation { LED } { LED, LED-CLS } { LED, LEP-FP } { LED, LED-CLS, LED-FP } { LED-CLS, LED-FP } { LED-CLS } { LED-FP }

16 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 Software Product Lines - Concepts, Analysis and Implementation

17 Cross-Tree-Constraints (1/2): Require-Kanten Syntax Beispiel Feature 1 Feature 2 LED Heatable Heatable <<require>> <<require>> Semantik Abhängigkeiten zwischen hierarchisch unkorrelierten Features Die Auswahl von Feature 1 erzwingt die Auswahl von Feature Software Product Lines - Concepts, Analysis and Implementation Valide Konfigurationen { LED-Heatable } { LED-Heatable, Heatable } { Heatable }

18 Cross-Tree-Constraints (2/2): Exclude-Kanten Syntax Beispiel Feature 1 Feature 2 ManPW RCK PW Control <<exclude>> <<exclude>> Semantik Konflikt zwischen hierarchisch unkorrelierten Features Die Features 1 und 2 schließen sich aus Software Product Lines - Concepts, Analysis and Implementation Valide Konfigurationen { ManPW } { ManPW, RCK-PW-COntrol } { RCK-PW-Control }

19 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 Software Product Lines - Concepts, Analysis and Implementation

20 Feature-Modelle: Erweiterungen Gruppenkardinalitäten Eltern Feature [k..l] Feature 1 Feature n Nicht-Boole sche Features Feature a : int b : { low, med, high } Abstrakte Features (nicht in Konfig. sichtbar und ohne Mapping) Feature Feature-Kardinalitäten (Mehrfachinstanziierung) Feature [3..*] => Übung Software Product Lines - Concepts, Analysis and Implementation

21 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 Software Product Lines - Concepts, Analysis and Implementation

22 Document Management System (DMS) Software Product Lines - Concepts, Analysis and Implementation

23 FAME DBMS (Core) Software Product Lines - Concepts, Analysis and Implementation

24 Berkley DB Software Product Lines - Concepts, Analysis and Implementation

25 PicoDBMS (für Smartcards) Software Product Lines - Concepts, Analysis and Implementation

26 Coment DB (für Sensornetzwerke) Software Product Lines - Concepts, Analysis and Implementation

27 Storage Manager Software Product Lines - Concepts, Analysis and Implementation

28 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, ) Software Product Lines - Concepts, Analysis and Implementation => Übung

29 Feature-Modell Semantik Configuration Space Enumeration and Analysis Product Configuration Derivation and Validation Automated Feature-Model Configuration and Analysis requires Precise Configuration Semantics Software Product Lines - Concepts, Analysis and Implementation

30 Feature-Model Analysis Survey (Benavides et al.) Software Product Lines - Concepts, Analysis and Implementation

31 Mengendarstellung der Feature-Modell-Semantik Konfiguration Konfigurationsraum f1 f1,f3 F = f1, f2, f3 f2 f3 f2,f3 f1, f2 Feature-Menge f1, f2, f3 FM = f2 f1 f3 f1, f2 f1, f2, f3 = [FM] Feature-Modell über Feature-Menge Valide Konfiguration Valider Konfigurationsraum Software Product Lines - Concepts, Analysis and Implementation

32 Analyse von Feature-Modellen (1/3) [Schobbens et al., 2005, Benavides et al., 2010] f0 f1 f2 <<exclude>> f0 f1 f2 <<require>> f SPL VL f1 f2 <<exclude>>

33 Mandatory Features vs. Core Features Ein mandatory Feature ist nicht zwangsläufig ein core Feature: f2 f1 f0 Ein core Feature ist nicht zwangsläufig ein mandatory Feature: f3 f0 f2 <<require>> => f3 ist ein false optional feature (entsprechendes gilt für dead features) SPL VL

34 Beispiel: Versteckte Anomalien dead core f0 core core f4 f5 f1 <<require>> f3 f2 <<exclude>> dead dead SPL VL

35 Analyse von Feature-Modellen (2/3) f1 FM = k =? f2 f SPL VL

36 Analyse von Feature-Modellen (3/3) [Thüm et al., 2008] f0 f0 f1 f2? f1 f2 <<exclude>> SPL VL

37 Vergleich von Feature-Modellen No Configs. added Configs. added No Configs. deleted Refactoring Generalization Configs. deleted Specialization Arbitrary Edit SPL VL

38 Aussagenlogische Feature-Modell-Semantik [Batory, 2005] SPL VL

39 Übersetzung von Feature-Diagrammen FODA Notation Aussagenlogischer Term Wurzel-Feature Optionales Feature Mandatory Feature Alternativ-Gruppe root f0 f1 f0 f1 f0 f1 fk Or-Gruppe f0 f1 fk Require-Kante Exclude-Kante SPL VL f0 f0 <<require>> <<exclude>> f1 f1

40 Beispiel FM f0 f1 f2 f3 <<exclude>> f4 f0 f SPL VL

41 Feature-Modell-Analyse durch SAT-Solver Das SAT Problem ist NP-complete SPL VL

42 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 SPL VL

43 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 SPL VL

44 Application Eng. Domain Eng. Software-Product-Line Engineering Feature-Modell Wiederverwendbare Implementierungsartefakte Feature-Auswahl Generator Fertiges Program Software Product Lines - Concepts, Analysis and Implementation

45 Produktkonfiguration FeatureIDE GUIDSL Software Product Lines - Concepts, Analysis and Implementation

46 Produktkonfiguration durch Feature-Selektion select deselect Aut Pw BCS Man Pw CLS RCK <<exclude>> Ctrl Pw BCS BCS. Aut Pw Man Pw CLS RCK Aut Pw Man Pw CLS RCK <<exclude>> Ctrl Pw <<exclude>> Ctrl Pw p = { BCS, ManPw, RCK } p = { BCS, AutPw, CLS, RCK, CtrlPw } Software Product Lines - Concepts, Analysis and Implementation

47 Konfigurationsprozess Produkte werden schrittweise in einem Konfigurationsprozess konfiguriert In jedem Konfigurationsschritt wird durch eine Konfigurationsoperation ein Feature an- oder abgewählt BCS Aut Pw Man Pw CLS RCK <<exclude>> Ctrl Pw +BCS -AutPw { } { BCS } { BCS } +RCK { BCS, ManPw, RCK } +ManPw -CtrlPw { BCS, ManPw } -CLS { BCS, ManPw, RCK } { BCS, ManPw } Software Product Lines - Concepts, Analysis and Implementation

48 Eigenschaften von Konfigurationsprozessen Software Product Lines - Concepts, Analysis and Implementation

49 Konfigurationsschritte 1. Explizite Konfigurationsentscheidungen BCS Aut Pw Man Pw CLS RCK <<exclude>> 2. Invalide Konfigurationsentscheidungen Ctrl Pw BCS BCS Aut Pw Man Pw CLS RCK Aut Pw Man Pw CLS RCK <<exclude>> Ctrl Pw <<exclude>> Ctrl Pw Software Product Lines - Concepts, Analysis and Implementation

50 Konfigurationsschritte 3. Implizite Konfigurationsentscheidungen Core Features können immer automatisch angewählt werden BCS Aut Pw Man Pw CLS RCK <<exclude>> Ctrl Pw Analog: Dead Features können immer automatisch abgewählt werden Software Product Lines - Concepts, Analysis and Implementation

51 Konfigurationsschritte Bereits getroffene Konfigurationsentscheidungen implizieren weitere Konfigurationsentscheidungen (Multi-Steps) BCS Aut Pw Man Pw CLS RCK <<exclude>> Ctrl Pw +ManPw -AutPw -CtrlPw { BCS, CLS, RCK } { BCS, CLS, RCK, ManPw } Systematisierung: Algorithmus zur Ableitung valider Konfigurationssequenzen Software Product Lines - Concepts, Analysis and Implementation

52 Berechnung von Multi-Steps (1/5) f? Software Product Lines - Concepts, Analysis and Implementation

53 Berechnung von Multi-Steps (2/5) 3. Entscheidung über Feature-Hierarchie propagieren: root Bei Feature-Anwahl +f: (rekursiv) alle Eltern-Features von f bis zum Wurzel-Feature anwählen f f Bei Feature-Abwahl f: (rekursiv) alle Kind-Features von f bis zu den Blättern abwählen f Software Product Lines - Concepts, Analysis and Implementation

54 Berechnung von Multi-Steps (3/5) 4. Behandlung von Mandatory Features: Angewähltes Feature +f hat ein mandatory Kind-Feature f : Kind- Feature ebenfalls anwählen f f Abgewähltes Feature f ist ein mandatory Kind-Feature von Eltern-Feature f : Eltern-Feature ebenfalls abwählen f f Software Product Lines - Concepts, Analysis and Implementation

55 Berechnung von Multi-Steps (4/5) 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 f f f f f f 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 Software Product Lines - Concepts, Analysis and Implementation

56 Berechnung von Multi-Steps (5/5) 6. Behandlung von Cross-Tree-Constraints: Angewähltes Feature +f benötigt ein Feature f : Feature f ebenfalls anwählen f f <<require>> Abgewähltes Feature f wird von einem Feature f benötigt: Feature f ebenfalls abwählen f f <<require>> Angewähltes Feature +f steht in Konflikt mit einem anderen Feature f : Feature f abwählen f f <<exclude>> Software Product Lines - Concepts, Analysis and Implementation

57 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. Zur einer validen Konfiguration gibt es in der Regel mehrere mögliche Konfigurationsprozesse, die sich in der Reihenfolge der Konfigurationsschritte unterscheiden. [Lochau, 2013] Software Product Lines - Concepts, Analysis and Implementation

58 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.] Software Product Lines - Concepts, Analysis and Implementation

59 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 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 , Washington, DC, USA, IEEE Computer Society. Thomas Leich, Sven Apel, Laura Marnitz, and Gunter Saake. Tool Support for Featureoriented 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, 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 , sept Don Batory. Feature Models, Grammars, and Propositional Formulas. In SPLC, pages Springer, 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: , September Software Product Lines - Concepts, Analysis and Implementation

60 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, Arnaud Hubaux, Andreas Classen, and Patrick Heymans: Formal Modelling of Feature Configuration Workflows. In Proceedings of the 13th International Software Product Line Conference, Arnaud Hubaux: Feature-based Configuration: Collaborative, Dependable, and Controlled. PhD thesis, University of Namur, Belgium, Marcilio Mendonca, Andrzej Wasowski, and Krzysztof Czarnecki: SAT-based Analysis of Feature Models is easy. In Proceedings of SPLC, pages , Jules White, Brian Dougherty, Douglas C. Schmidt, and David Benavides: Automated Reasoning for Multi-step Feature Model Configuration Problems. In Proceedings of SPLC, pages ACM Press, Software Product Lines - Concepts, Analysis and Implementation