Feature Modelling Techniques
Upcoming SlideShare
Loading in...5
×
 

Feature Modelling Techniques

on

  • 3,521 views

 

Statistics

Views

Total Views
3,521
Views on SlideShare
3,512
Embed Views
9

Actions

Likes
1
Downloads
29
Comments
0

1 Embed 9

http://www.slideshare.net 9

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Feature Modelling Techniques Feature Modelling Techniques Presentation Transcript

  • 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/
  • Gliederung Was ist Featuremodellierung? Wozu wird sie verwendet? ► ► Featuremodellierungsmethodiken und -notationen ► Zusammenfassung + Diskussion 2
  • Gliederung Was ist Featuremodellierung? Wozu wird sie verwendet? ► ► Featuremodellierungsmethodiken und -notationen ► Zusammenfassung + Diskussion 3
  • 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
  • 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
  • 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
  • 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
  • Gliederung Was ist Featuremodellierung? Wozu wird sie verwendet? ► ► Featuremodellierungsmethodiken und -notationen ► Zusammenfassung + Diskussion 8
  • 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
  • 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
  • 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
  • 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
  • Original Feature Diagrams (OFD) Ebenfalls von Kang et al. ► ► Erweiterung von FODA -> Feature Oriented Reuse Method (FORM) FODA From: [11] 13
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Gliederung Was ist Featuremodellierung? Wozu wird sie verwendet? ► ► Featuremodellierungsmethodiken und -notationen ► Zusammenfassung + Diskussion 24
  • 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
  • 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
  • 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