Technische Universität Berlin

http://www.swt.tu-berlin.de/menue/studium_und_lehre/lehrveranstaltungen/eks/wise2008/

Featuremodellierungsmethodik

Entwicklung verteilter eingebetteter Systeme

Helko Glathe (Helko.Glathe@mailbox.tu-berlin.de)

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.