Technische Universität Berlin
http://www.swt.tu-berlin.de/menue/studium_und_lehre/lehrveranstaltungen/eks/wise2008/
Featuremodellierungsmethodik
Entwicklung verteilter eingebetteter Systeme
Helko Glathe ([email protected])
12.12.2008
2
Gliederung
► Was ist Featuremodellierung? Wozu wird sie verwendet?► Featuremodellierungsmethodiken und -notationen► Zusammenfassung + Diskussion
3
Gliederung
► Was ist Featuremodellierung? Wozu wird sie verwendet?► Featuremodellierungsmethodiken und -notationen► Zusammenfassung + Diskussion
4
Produktlinie / (Software)-System-Familien
► 7er BMW ist eine Produktlinie► Wieviele Konfigurationsmöglichkeiten aller optionalen
Eigenschaften?► Ca. 11 Milliarden!
► Weiteres Beispiel: Informationsintegrationssysteme (IIS)
From slidesof Paper BGH+ 07
From: WWW (FinancialTimesDeutschland)http://www.ftd.de/auto/bilder/390509.html?bid=390510&p=1&cp=1
From: Dr. Susanne BusseCIS (DIMA) TU Berlin
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
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
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!
8
Gliederung
► Was ist Featuremodellierung? Wozu wird sie verwendet?► Featuremodellierungsmethodiken und -notationen► Zusammenfassung + Diskussion
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
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
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
12
OFT – Graphische Notation
Monitor Engine System
Monitor Engine Performance
Monitor Fuel Consumption
MonitorTemperatures
Monitor RPM Monitor exhaust levelsAnd temperature
coolant oil Engine transmission
Measures Methods
l/km gallon/milel/km Based ondistance
Based onType
of driving
Based ondrive
XOR Dekompositionen mit alternativen Features
AND DekompositionKonzept
From: [1]
Optional-Feature
Pflicht-Feature
Based on drive requires Monitor RPM
13
Original Feature Diagrams (OFD)
► Ebenfalls von Kang et al.► Erweiterung von FODA -> Feature Oriented Reuse Method
(FORM)
From: [11]
FODA
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
15
OFD – Formale + Graphische Notation
► Änderung gegenüber OFT Direkter azyklischer Graph (DAG) statt Baum Vorteil: Mehrere Vater-Features möglich
► Erweiterung der Semantik von Feature-Beziehungen Generalisierung/Spezialisierung
Implemented by -> Zuweisung/Unterordnung von Domain Technology Feature zu Capability Feature oder Implementation Feature zu Domain Technology Feature
Feature 4
Feature 2 Feature 3
Getriebe
Automatikgetriebe Schaltgetriebe
Feature 1
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
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
18
RFD – Formale + Graphische Notation
Feature 1
Feature 11 Feature 12
Feature 121 Feature 122
Requires
Mutex Feature 111
Requires + Mutexnun auch direkt im Modell
From: [12]
Dynamisches BindenUse Time Binding Statisches Binden
Reuse Time Binding
Optionale OR-Dekomposition XOR-
Dekomposition
19
Erweiterung von FeatuRSEB in 2 Richtungen
From: [7]
VBFD (Van Gurp / Bosch):Mehrere statische undDynamische Bindungszeiten.Zusätzlich externe Feature.
PLUSS (Griss et al.):Alternativ-Features bestimmen Art der Alternative.
Grundsatz: Variabilität so spät wie möglich auflösen -> Produkt/System hat mehrOptionen.
Hier Teilmenge von Kind-Features als Alternativen möglich!
Mail Client
Type Message Send MessageReceive Message
Pop3 IMAP
Internal Editor
EditSignature file
runtime
runtime
VI Emacs
TCP Connection
anExternalFeature
aFeature
or specialization
xor specialization
composition
optional feature
runtime
Runtime platform
Linuxwin32
compiletime
From: [15]
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]
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► Normalisierung für XOR und OR gefordert
AND XOR OR
F1 kann Optional werden!Aus OR stattdessen AND!
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
Implizit [1..1]
Implizit [0..1]
Z.B. {java, class, txt, ...}
Kein oder max. 3 gebundeneFeatures
From: [6]
Auch mehrere Kardinalitätsintervalle proElement möglich! Z.B. [0..2] [4..4]
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
Hohle Stecknadel -> C optional zu BGefüllte Stecknadel -> C mandatory zu A
KantenbasierteSemantik
24
Gliederung
► Was ist Featuremodellierung? Wozu wird sie verwendet?► Featuremodellierungsmethodiken und -notationen► Zusammenfassung + Diskussion
25
Zusammenfassung + Diskussion
1: Textuell formulierte Regeln 2: Ursprüngliche Variante 3: Erweiterte Variante
Feature-Arten: M=(Mandatory/Pflicht) / O=(Optional) / A=(Alternative)
4: später DAG durch Kanten-Referenzen 5: Mischformen möglich (z.B. Feature ist alternativ und optional)
DAG = Directed Acyclic Graph
Feature-Arten5 Struktur
Alternativen
Sonderbeziehungen
Variabilitäts-Semantik
Weitere Feature-Klassifizierung
Weitere Besonderheiten
OFT (FODA) M / O / A Baum XOR Require/ MUTEX1
Knoten Capability (Functional/Operational/Representation)
OFD (FORM) M / O / A DAG XOR Require/ MUTEX1
Knoten Capability/Operating Environment/Domain Techn./Implementation Techn.
Gen/Spec- + ImplementedBy-Beziehungen
RFD (FeatuRSEB)
M / O / A DAG XOR/OR Require/ MUTEX
Knoten Functional/Architectural/Implementation
Implizit BindingTime für XOR/OR
VBFD (Van Gurp / Bosch)
M / O / A / External
DAG XOR/OR Require/ MUTEX
Knoten Architectural/Design/Source Code/Compiled Code/Linked Code/Running Code
BindingTimes an Feature-Beziehungen; Gen/Spec bei XOR/OR
PFT (PLUSS) M / O / SingleAdaptor / MultipleAdaptor
Baum XOR/OR Require/ MUTEX
Knoten Functional (Verfeinerung: Scenario + Step)
GPFT(D) (Gen. Prog.)
M / O / A Baum4 XOR/OR2 bzw. Kardinalitäten3
Require/ MUTEX
Knoten Keine Klassifizierung (alles, was ein unterscheidbares Feature ausmacht).
Feature-Kardinalitäten + -Parameter
EFD (Extended FM)
Keine Unterscheidung
DAG Kardinalitäten
Require/ MUTEX
Kanten Keine Klassifizierung (alles, was ein unterscheidbares Feature ausmacht).
26
Informationsmaterialien[1] Bontemps, Y., Heymans, P., Schobbens, P., and Trigaux, J. The seman-tics of foda feature diagrams. In Workshop on Software Variability Managementfor Product Derivation - Towards Tool Support (2004).
[2] Busse, S., Glathe, H., Stark, T., and Zhang, J. A feature-based frameworkfor 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 templateapproach 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 usingfeature models. 2004, pp. 266–283.
[6] Czarnecki, K., Helsen, S., and Eisenecker, U. Formalizing cardinality-based feature models and their specialization. Software Process: Improvement andPractice 10, 1 (2005), 7–29.
[7] Eriksson, M., B¨ rstler, J., and Borg, K. The pluss approach - domainmodeling with features, use cases and use case realizations. 2005, pp. 33–44.
[8] Griss, M. L., Favaro, J., and D’alessandro, M. Integrating feature modelingwith the rseb. pp. 76–85.
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 ofSoftware Engineering 5, 1 (January 1998), 143–168.
[12] Lichter, H., Maßen, T., Nyßen, A., and Weiler, T. Technical ReportISSN 0935-3232 Aachener Informatik Berichte AIB-2003-07 .
[13] Riebisch, M., B¨ llert, K., Streitferdt, D., and Philippow, I. Extendingfeature diagrams with uml multiplicities. In 6th World Conference on IntegratedDesign & 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 variabilityin software product lines. In Software Architecture, 2001. Proceedings. WorkingIEEE/IFIP Conference on (2001), pp. 45–54.