1. Featuremodellierungsmethodik
Entwicklung verteilter eingebetteter Systeme
Helko Glathe (Helko.Glathe@mailbox.tu-berlin.de)
12.12.2008
Technische Universität Berlin
http://www.swt.tu-berlin.de/menue/studium_und_lehre/
lehrveranstaltungen/eks/wise2008/

2. Gliederung
Was ist Featuremodellierung? Wozu wird sie verwendet?
►
► Featuremodellierungsmethodiken und -notationen
► Zusammenfassung + Diskussion
2

3. Gliederung
Was ist Featuremodellierung? Wozu wird sie verwendet?
►
► Featuremodellierungsmethodiken und -notationen
► Zusammenfassung + Diskussion
3

4. Produktlinie / (Software)-System-Familien
7er BMW ist eine Produktlinie
►
► Wieviele Konfigurationsmöglichkeiten aller optionalen
Eigenschaften?
► Ca. 11 Milliarden!
From: WWW (FinancialTimesDeutschland)
http://www.ftd.de/auto/bilder/390509.html?
bid=390510&p=1&cp=1
Weiteres Beispiel: Informationsintegrationssysteme (IIS)
►
From slides
From: Dr. Susanne Busse
of Paper BGH+ 07
CIS (DIMA) TU Berlin
4

5. Was ist Feature-Modellierung?
Modellierung: Gemeinsame + unterschiedliche Merkmale /
►
Charakeristiken innerhalb einer Domäne.
► Variabilität
► Ergebnis ist Struktur: Features + Feature-Beziehungen
► Features: Unterschiedliches Abstraktionsniveau
► Zusätzliche Metainformationen:
 Zusätzliche Hinweise, Ursprung, Beispielsysteme, Kategorie u.v.m. möglich
Produkt -> Spezialisierung / Konfiguration
►
5

6. Wozu Feature-Modellierung?
Einheitliche Domänensprache (Bedeutung, Synonyme,
►
Homonyme, etc.)
► Gemeinsame + unterschiedliche Eigenschaften von
Produkten/Systemen
► Beschreibung der Domäne (Scoping) + Domänenvergleiche
► Identifikation: Wiederverwendbares Wissen
► Identifikation: Indirekte Feature-Beziehungen
► Produkt- / Systemerstellung: Diskussionsgrundlage / Roadmap
6

7. Feature? Was ist das?!?! Viele Definitionen!
„Ein prominente, unterscheidbare und erkennbare Charakteristik
►
für einen Benutzer.“ (u.a. [10], [11], [8])
„Eine unterscheidbare Charakteristik eines Konzepts, welche
►
relevant für einen Stakeholder (Analyst, Designer etc.) ist und
benutzt wird, um Gemeinsamkeiten und Unterschiede zwischen
Systemen herauszufinden.“ (u.a. [4], [6])
„Eine logische Einheit von Verhalten, welche durch mehrere
►
funktionale und qualitative Anforderungen spezifiziert wird.“
(u.a. [15])
► Hier nur Beispiele. Viele weitere Definitionen!
7

8. Gliederung
Was ist Featuremodellierung? Wozu wird sie verwendet?
►
► Featuremodellierungsmethodiken und -notationen
► Zusammenfassung + Diskussion
8

9. Original Feature Trees (OFT)
Erste Form eines Feature-Modells (1990 von Kang et al.)
►
► Eingeführt in der Feature Oriented Domain Analysis (FODA)
► Absicht: Identifizierung von Gemeinsamkeiten und Variabilitäten
auf Anforderungsebene (Domänenmodell)
 Bestimmung herausragender, sichtbarer und unterscheidbarer Features ->
Requirements (Klassifizierung: Presentation, Functional, Operational)
Ablauf nach FODA
9

10. OFT - Formale Notation
Baum als Feature-Anordnung
►
 Jedes Feature hat maximal ein Vater-Feature
Wurzel des Baumes ist das Konzept
►
 Repräsentiert als Begriff die betrachtete Domäne
 Ist obligatorisch
 Hat keine übergeordneten Features
Knoten sind Feature
►
 Vater ist ein Feature oder das Konzept
 Kann weiter verfeinert werden -> Sub-Feature(s)
 Unterscheidung:
• Pflicht-Feature (Mandatory) -> grundsätzlich im Produkt/System vorhanden
• Optional-Feature (Optional) -> möglicherweise im Produkt/system vorhanden
• Alternativ-Feature
10

11. OFT - Formale Notation
Feature-Beziehungen (Kanten)
►
► Hierarchische Vater-Kind-Beziehung
► Verfeinerung/Zerlegung eines Features in Sub-Feature(s)
► Sub-Features eines Vater-Feature sind Geschwister-Feature
► Unterscheidung von Dekompositionen:
 AND -> Sub-Features stehen in einem logischen UND zueinander
 XOR -> Sub-Features stehen in einem logischen XOR zueinander
 Logische Beziehungen zwischen Geschwister-Feature muss bei Konfiguration beachtet
werden
Explizite Constraints (textuell): Requires + MUTEX
►
11

12. OFT – Graphische Notation
Konzept
Monitor Engine System
AND Dekomposition
Monitor Engine Monitor Fuel
Pflicht-Feature
Performance Consumption
Monitor Monitor RPM Monitor exhaust levels Measures Methods
Temperatures And temperature
coolant oil Engine transmission l/km gallon/mile Based on Based on Based on
distance Type drive
of driving
Optional-Feature
XOR Dekompositionen mit alternativen Features
 Based on drive requires Monitor RPM From: [1]
12

13. Original Feature Diagrams (OFD)
Ebenfalls von Kang et al.
►
► Erweiterung von FODA -> Feature Oriented Reuse Method
(FORM)
FODA
From: [11]
13

14. Original Feature Diagrams (OFD)
Erweiterung der Sicht der Feature-Modellierung
►
 Nun auch Softwarearchitektur und -design relevant -> Whitebox
 Wiederverwendbare Domain-Artefakte werden aus Features abgeleitet
Zusätzliche Feature-Klassifizierung durch Layer:
►
 Capability Layer -> High Level; Dienste, Operationen, Funktionen, Performance
(Funktional vs. Non-Funktional)
 Operating Environment Layer -> Umgebung; Betriebssysteme, Datenbanken,
Netzwerkumgebung u.v.m.
 Domain Technology Layer -> Low Level; spezielle Implementierung für die Domäne
 Implementation Technique Layer -> Low Level; Implementierung einsetzbar in
mehreren Domänen
14

15. OFD – Formale + Graphische Notation
Änderung gegenüber OFT
►
Feature 1
 Direkter azyklischer Graph (DAG) statt Baum
 Vorteil: Mehrere Vater-Features möglich
Feature 2 Feature 3
Feature 4
Erweiterung der Semantik von Feature-Beziehungen
►
 Generalisierung/Spezialisierung Getriebe
Automatikgetriebe Schaltgetriebe
 Implemented by -> Zuweisung/Unterordnung von Domain Technology Feature zu
Capability Feature oder Implementation Feature zu Domain Technology Feature
15

16. RSEB Feature Diagrams (RFD) - Hintergrund
Einbettung von FODA in Reuse-Driven Software Engineering
►
Business (RSEB) -> FeatuRSEB
► 1998 -> UML und Modellierung wird immer populärer (OMG
etc.)
► Softwarearchitektur + -design mit Modellierungssprachen
► RSEB: Modellgetriebene Softwarefamilien
 Gemeinsames Domain Use Case Model
 Stereotypische Erweiterung durch Variantionspunkte und Varianten
16

17. RSEB Feature Diagrams (RFD)
Absicht von FeatuRSEB
►
 Feature-Modell für wichtige Use Cases des Domain Use Case Model -> nicht
sämtliche!
 Feature-Modell ist Katalog -> Terminologie der Domäne
 Feature-Modell ist Roadmap -> Konfigurationsmöglichkeiten (Gemeinsamkeiten +
Unterschiede) und Kombinationsmöglichkeiten
Features hier als Eigenschaften die Benutzer wahrnimmt/sieht
►
► Dennoch nicht nur Features für Use Cases
► Klassifizierung
 Funktionale Features (Use Cases)
 Architekturale Features (Architektur; Einteilung in Sub-Systeme)
 Implementierungs-Features (Design; Implementierung; Objektparameter)
Features in UML: Stereotypische Erweiterung
►
17

18. RFD – Formale + Graphische Notation
From: [12]
Optionale OR-
Dekomposition XOR-
Dynamisches Binden
Statisches Binden
Use Time Binding
Dekomposition
Reuse Time Binding
Feature 1
Requires + Mutex
nun auch direkt im Modell Feature 11 Feature 12
Requires
Feature 111 Feature 121 Feature 122
Mutex
18

19. Erweiterung von FeatuRSEB in 2 Richtungen
VBFD (Van Gurp / Bosch):
Mail Client
Mehrere statische und
Dynamische Bindungszeiten.
TCP Connection Type Message Receive Message Send Message Runtime platform
Zusätzlich externe Feature.
runtime runtime compiletime
Signature file Edit Pop3 IMAP win32 Linux
runtime
Grundsatz: Variabilität so spät wie möglich auflösen -> Produkt/System hat mehr
VI Emacs Internal Editor Optionen.
or specialization composition
anExternalFeature
xor specialization optional feature
aFeature
Hier Teilmenge von Kind-Features als Alternativen möglich!
From: [15]
PLUSS (Griss et al.):
Alternativ-Features bestimmen
Art der Alternative.
From: [7]
19

20. Generative Programming Feature Tree (GPFT)
Feature: Allgemein unterscheidbare Charakteristik eines
►
Konzepts
► „Unterscheidbar“ betrifft jegliche Stakeholder
 End-Anwender, Systemarchitekten, Designer, Programmierer, etc...
Features für High- und Low-Level einer Systemfamilie
►
 Requirements, Architektur, Komponenten, Implementierung, Algorithmen, Parameter,
...
Ziel:
►
Domain Engineering vs. Application Engineering from [4]
20

21. GPFT – Formale + Graphische Notation (1/2)
Feature-Baum! (Wobei auch Graph laut Riebisch et al.)
►
► Ähnlich zu OFT + OR, OFD und RFD
 Unterscheidung von Pflicht- und Optional-Features (Mandatory vs. Optional)
 Können Einzel-Features (Solitary Feature) sein -> Einzel-Features mit gleichem Vater-
Feature stehen über logisches UND in Beziehung
 Können Gruppen-Features (Grouped Feature) sein -> Gruppen-Features mit gleichem
Vater-Feature stehen entweder über logisches XOR oder logisches OR in Beziehung
Auch hier: Require + MUTEX möglich
►
F1 kann Optional werden!
► Normalisierung für XOR und OR gefordert Aus OR stattdessen AND!
AND XOR OR
21

22. GPFT (Extended) – Formale + Graphische Notation (2/2)
Kardinalitäten für Feature-Gruppen (Riebisch et al. -> siehe EFD)
►
► Kardinalitäten für Features (nur Solitary Features!)
► Parametrisierte Features (Typisierung: String, Integer)
► Mehrere Gruppen pro Vater-Feature möglich
Auch mehrere Kardinalitätsintervalle pro
Element möglich! Z.B. [0..2] [4..4]
Implizit [0..1]
Kein oder max. 3 gebundene
Features
Z.B. {java, class, txt, ...}
Implizit [1..1]
From: [6]
22

23. Extended Feature Diagrams (EFD)
Riebisch et al.: Ausdrucksmöglichkeit in Feature-Modellen
►
► Wie GPFT-Erweiterung: Kardinalitäten bei Feature-Gruppen
► Problematik bei Feature-Graphen
Sub-Feature (C) gehört zu 2 Vater-Features (A und B)

Von A aus ist C obligatorisch (C ist Pflicht-Feature)

Von B aus ist C otional (C ist Optional-Feature)

Das geht bisher nicht! -> Knotenbasierte-Semantik

Veränderung: Definition von Obligatorisch und Optional nicht im
►
Feature hinterlegen
Kantenbasierte
Semantik
Hohle Stecknadel -> C optional zu B
Gefüllte Stecknadel -> C mandatory zu A
23

24. Gliederung
Was ist Featuremodellierung? Wozu wird sie verwendet?
►
► Featuremodellierungsmethodiken und -notationen
► Zusammenfassung + Diskussion
24

25. Zusammenfassung + Diskussion
Feature-Arten5 Strukt Alternativ Sonder Variabilitäts Weitere Feature- Weitere Besonderheiten
ur en beziehu -Semantik Klassifizierung
ngen
OFT (FODA) M/O/A Baum XOR Require/ Knoten Capability
MUTEX1 (Functional/Operational/Represe
ntation)
OFD (FORM) M/O/A DAG XOR Require/ Knoten Capability/Operating Gen/Spec- + ImplementedBy-
MUTEX1 Environment/Domain Beziehungen
Techn./Implementation Techn.
RFD M/O/A DAG XOR/OR Require/ Knoten Functional/Architectural/Implem Implizit BindingTime für XOR/
(FeatuRSEB) MUTEX entation OR
VBFD (Van M/O /A/ DAG XOR/OR Require/ Knoten Architectural/Design/Source BindingTimes an Feature-
Gurp / External MUTEX Code/Compiled Code/Linked Beziehungen; Gen/Spec bei
Bosch) Code/Running Code XOR/OR
PFT (PLUSS) M / O / Baum XOR/OR Require/ Knoten Functional (Verfeinerung:
SingleAdaptor / MUTEX Scenario + Step)
MultipleAdaptor
GPFT(D) M/O/A Baum4 XOR/OR2 Require/ Knoten Keine Klassifizierung (alles, was Feature-Kardinalitäten +
(Gen. Prog.) bzw. MUTEX ein unterscheidbares Feature -Parameter
Kardinalitä ausmacht).
ten3
EFD Keine DAG Kardinalitä Require/ Kanten Keine Klassifizierung (alles, was
(Extended Unterscheidung ten MUTEX ein unterscheidbares Feature
FM) ausmacht).
1: Textuell formulierte Regeln 2: Ursprüngliche Variante 3: Erweiterte Variante
4: später DAG durch Kanten-Referenzen 5: Mischformen möglich (z.B. Feature ist alternativ und optional)
Feature-Arten: M=(Mandatory/Pflicht) / O=(Optional) / A=(Alternative) DAG = Directed Acyclic Graph
25

26. Informationsmaterialien
[1] Bontemps, Y., Heymans, P., Schobbens, P., and Trigaux, J. The seman-
tics of foda feature diagrams. In Workshop on Software Variability Management
for Product Derivation - Towards Tool Support (2004).
[2] Busse, S., Glathe, H., Stark, T., and Zhang, J. A feature-based framework
for model-driven engineering. In Nordic Workshop on Model Driven Engineering
(2007), Blekinge Institute of Technology, pp. 22–36.
[3] Czarnecki, K., and Antkiewicz, M. Mapping features to models: A template
approach based on superimposed variants. In GPCE (2005), pp. 422–437.
[4] Czarnecki, K., and Eisenecker, U. W. Generative Programming : Methods,
Tools, and Applications. Addison-Wesley, Boston et. al., 2000. ISBN: 0-201-30977-7.
[5] Czarnecki, K., Helsen, S., and Eisenecker, U. Staged configuration using
feature models. 2004, pp. 266–283.
[6] Czarnecki, K., Helsen, S., and Eisenecker, U. Formalizing cardinality-
based feature models and their specialization. Software Process: Improvement and
Practice 10, 1 (2005), 7–29.
[7] Eriksson, M., B¨ rstler, J., and Borg, K. The pluss approach - domain
modeling with features, use cases and use case realizations. 2005, pp. 33–44.
[8] Griss, M. L., Favaro, J., and D’alessandro, M. Integrating feature modeling
with the rseb. pp. 76–85.
26

27. Informationsmaterialien
[9] Jacobson, I., Griss, M., and Jonsson, P. Software Reuse: Architecture, Pro-
cess and Organization for Business Success. 1997.
[10] Kang, K., Cohen, S., Hess, J., Nowak, W., and Peterson, S. Feature-
oriented domain analysis (foda) feasibility study. Technical Report CMU/SEI-90-
TR-21 (1990).
[11] Kang, K., Kim, S., Lee, J., Kim, K., Shin, E., and Huh, M. Form: A feature-
;oriented reuse method with domain-;specific reference architectures. Annals of
Software Engineering 5, 1 (January 1998), 143–168.
[12] Lichter, H., Maßen, T., Nyßen, A., and Weiler, T. Technical Report
ISSN 0935-3232 Aachener Informatik Berichte AIB-2003-07 .
[13] Riebisch, M., B¨ llert, K., Streitferdt, D., and Philippow, I. Extending
feature diagrams with uml multiplicities. In 6th World Conference on Integrated
Design & Process Technology (IDPT2002) (June 2002).
[14] Schobbens, P.-Y., Heymans, P., Trigaux, J.-C., and Bontemps, Y. Ge-
neric semantics of feature diagrams. Computer Networks 51, 2 (February 2007),
456–479.
[15] van Gurp, J., Bosch, J., and Svahnberg, M. On the notion of variability
in software product lines. In Software Architecture, 2001. Proceedings. Working
IEEE/IFIP Conference on (2001), pp. 45–54.
27