EPMD Teil 6 Feature-Orientierung

Transkript

1 EPMD Teil 6 Feature-Orientierung Christian Kästner (Universität Magdeburg) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg)

2 Kästner, Apel, Saake EPMD Folie 6-2 Grundidee Agenda Implementierung mit AHEAD Prinzip der Uniformität Formalisierung

3 Kästner, Apel, Saake EPMD Folie 6-3 Ziel: Feature-Kohäsion ( Feature Traceability Problem) Eigenschaft eines Programms alle Implementierungseinheiten eines Features an einer Stelle im Code zu lokalisieren Features sind explizit im Programmcode Ein Frage des Programmiersprache bzw. der Programmierumgebung! Virtuelle vs. physische Trennung

4 Kästner, Apel, Saake EPMD Folie 6-4 Feature Traceability mit Werkzeugunterstützung Feature-Modell Ein Werkzeug verwaltet die Abbildung Implementierungseinheiten

5 Kästner, Apel, Saake EPMD Folie 6-5 Feature Traceability mit Sprachunterstützung Feature-Modell 1:1 Abbildung (oder zumindest 1:n) Implementierungseinheiten

6 Kästner, Apel, Saake EPMD Folie 6-6 Feature-Orientierte Programmierung Prehofer, ECOOP'97 und Batory, ICSE'03 Sprachbasierter Ansatz zur Überwindung des Feature-Traceability-Problems Jedes Feature wird durch ein Feature-Modul implementiert Lösung des Feature-Traceability-Problems Trennung und Modularisierung von Features Einfache Feature-Komposition Algebra-basierte Programmgenerierung

7 Kästner, Apel, Saake EPMD Folie 6-10 Feature-Komposition

8 Kästner, Apel, Saake EPMD Folie 6-11 Produktlinien mit Feature-Modulen Feature-Modell 1:1 Mapping von Features zu Feature-Modulen Feature-Module Feature-Auswahl als Eingabe Feature-Auswahl Kompositions-Algorithmus Fertiges Program

9 Kästner, Apel, Saake EPMD Folie 6-12 Grundidee Agenda Implementierung mit AHEAD Prinzip der Uniformität Formalisierung

10 Kästner, Apel, Saake EPMD Folie 6-13 Implementierung von Feature-Modulen Aufteilung in Klassen ist etabliert und als Grundstruktur nutzbar Features werden oft von mehreren Klassen implementiert Klassen implementieren oft mehr als ein Feature Idee: Klassenstruktur prinzipiell beibehalten, aber Klassen aufteilen AHEAD (Algebraic Hierarchical Equations for Application Design) oder FeatureHouse als ein mögliches Werkzeug

11 Kästner, Apel, Saake EPMD Folie 6-14 Aufspalten von Klassen Klassen Graph Edge Node Weight Color Search Features Directed Weighted Colored

12 Kästner, Apel, Saake EPMD Folie 6-15 Kollaborationen & Rollen Kollaboration: eine Menge von Klassen, die miteinander interagieren, um ein Feature zu implementieren Verschiedene Klassen spielen verschiedene Rollen innerhalb einer Kollaboration Eine Klasse spielt verschiedene Rollen in verschiedenen Kollaborationen Eine Rolle kapselt das Verhalten/die Funktionalität einer Klasse, welche(s) für eine Kollaboration relevant ist

13 Kästner, Apel, Saake EPMD Folie 6-16 Kollaborationen & Rollen Klassen Graph Edge Node Weight Color Kollaborationen Search Directed Weighted Colored Rollen

14 Kästner, Apel, Saake EPMD Folie 6-17 Beispiel Die Kollaboration Weighted umfasst alle Rollen, die nötig sind, um gewichtete Kanten zu implementieren (Graph, Edge und Weight) Die Klasse Edge hat eine Rolle, die den relevanten Teil für gewichtete Kanten implementiert, z. B. das Feld weight, die Methoden getweight und setweight und die Erweiterung der Methode print. Die Klasse Edge hat eine weitere Rolle für gerichtete Kanten

15 Kästner, Apel, Saake EPMD Folie 6-18 Repräsentation von Rollen und Kollaborationen in AHEAD Verschiedene Möglichkeiten für Rollen Jede Rolle einer Kollaboration in einem Modul (z. B. einer Java Datei) Geringe Feature-Kohäsion Klassenhierarchien Unzureichende Variabilität Klassenverfeinerung (class refinement) Sammlung von Rollen in Kollaborationen Verzeichnisse enthalten Rollen (containment hierarchies); implementieren Feature-Module Geschachtelte Module möglich

16 Kästner, Apel, Saake EPMD Folie 6-19 Auszug: Kollaborationenentwurf class Graph { Vector nv = new Vector(); Vector ev = new Vector(); Edge add(node n, Node m) { Edge e = new Edge(n, m); nv.add(n); nv.add(m); ev.add(e); return e; void print() { for(int i = 0; i < ev.size(); i++) ((Edge)ev.get(i)).print(); class Edge { Node a, b; Edge(Node _a, Node _b) { a = _a; b = _b; void print() { a.print(); b.print(); class Node { int id = 0; void print() { System.out.print(id); refines class Graph { Edge add(node n, Node m) { Edge e = Super.add(n, m); e.weight = new Weight(); Edge add(node n, Node m, Weight w) Edge e = new Edge(n, m); nv.add(n); nv.add(m); ev.add(e); e.weight = w; return e; refines class Edge { Weight weight = new Weight(); void print() { Super.print(); weight.print(); class Weight { void print() {...

17 Kästner, Apel, Saake EPMD Folie 6-20 Auszug: Verzeichnishierarchie

18 Kästner, Apel, Saake EPMD Folie 6-21 Implementierung von Klassenverfeinerungen mit Jak Erweiterung von Java 1.4 mit neuen Schlüsselwörtern für Verfeinerungen refines für Klassenverfeinerungen Super für Methodenverfeinerungen Aus technischen Gründen müssen hinter Super die erwarteten Typen der Methode angegeben werden, z. B. Super(String, int).print('abc', 3) refines class Edge { private int weight; void print() { Super().print(); System.out.print(' weighted with' + weigth);

19 Kästner, Apel, Saake EPMD Folie 6-22 Implementierung von Klassenverfeinerungen mit FeatureHouse Behält Java 1.5 Syntax, aber neuer Kompositionsprozess Jede Klasse kann verfeinert werden (kein refines Schlüsselwort) original für Methodenverfeinerungen class Edge { private int weight; void print() { original(); System.out.print(" weighted with" + weigth);

20 Kästner, Apel, Saake EPMD Folie 6-23 Beispiel: Klassenverfeinerungen Edge.jak class Edge {... Schrittweise Erweiterung der Basisimplementierung durch Verfeinerungen Edge.jak refines class Edge { private Node start;... Ungenaue Definition der Basisimplementierung Edge.jak refines class Edge { private int weight;...

21 Kästner, Apel, Saake EPMD Folie 6-24 Beispiel: Methodenverfeinerungen Methoden können in jeder Verfeinerung eingeführt oder erweitert werden Überschreiben von Methoden Aufruf der Methode aus vorheriger Verfeinerung mit Super Ähnlich zu Vererbung class Edge { void print() { System.out.print( 'Edge between ' + node1+' and + node2); refines class Edge class { Edge { private Node start; void print() { Super.print(); original(); System.out.print( ' directed from ' + start); refines class Edge class { Edge { private int weight; void print() { Super.print(); original(); System.out.print( ' weighted with' + weigth);

22 Kästner, Apel, Saake EPMD Folie 6-25 Alternativen zu Klassenverfeinerungen Traits Keinen Zustand Virtuelle Klassen Kollaboration Familienklasse Rolle virtuelle (innere) Klasse Komposition und Instantiierung zur Laufzeit z.b. CaesarJ Verschachtelte Klassen-, Layer- und Package- Hierarchien z.b. Scala, Classbox/J, ContextL

23 Kästner, Apel, Saake EPMD Folie 6-26 Komposition in AHEAD Equation-Datei jampack Komponierte Jak-Dateien Composer mixin jak2java Feature-Module (Verzeichnisse) mit Jak-Dateien Java-Dateien

24 Kästner, Apel, Saake EPMD Folie 6-27 Komposition in AHEAD Equation-Datei FeatureHouse (FSTComposer) Java-Dateien Feature-Module (Verzeichnisse) mit Jak-Dateien

25 Kästner, Apel, Saake EPMD Folie 6-28 Komposition von Verzeichnissen Alle Rollen einer Kollaboration werden in einem Package/Modul gespeichert, r.d.r. in einem Verzeichnis Komposition von Kollaborationen durch Komposition von Klassen mit allen enthaltenen gleichnamigen Klassenverfeinerungen

26 Kästner, Apel, Saake EPMD Folie 6-29 Beispielkomposition Base Search Directed Weighted Colored Graph Edge Node Weight Color Graph Edge Node Feature-Auswahl in Equation-Datei (Textdatei, Feature-Namen in Zeilen)

27 Kästner, Apel, Saake EPMD Folie 6-30 Komposition mit Jampack Zusammenbauen zu einer Klasse durch Überlagerung (superimposition) Super/original- Aufrufe werden durch inlining integriert Ergebnis: eine Klasse class Edge { private Node start; private int weight; void print() { System.out.print( 'Edge between ' + node1+' and + node2); System.out.print( ' directed from ' + start); System.out.print( ' weighted with' + weigth);

28 Kästner, Apel, Saake EPMD Folie 6-31 Komposition mit Mixin Generierung einer Klasse pro Rolle mit entsprechender Hierarchie Umbenennung, so dass finale Klasse den Klassennamen erhält Ersetzen von Super durch super class Edge$$Base { void print() {... class Edge$$Directed extends Edge$$Base { private Node start; void print() { super.print(); System.out.print( ' directed from ' + start); class Edge extends Edge$$Directed{ private int weight; void print() { super.print(); System.out.print( ' weighted with' + weigth);

29 Kästner, Apel, Saake EPMD Folie 6-32 Jampack Mixins vs. Jampack Zuordnung von generierten Code zu Rollen verschwindet nach Generierung Mixins Code-Overhead Langsamer, durch Indirektion bei Methodenaufrufen

30 Kästner, Apel, Saake EPMD Folie 6-33 Werkzeuge AHEAD Tool Suite + Dokumentation Kommandozeilenwerkzeuge für Jak (Java 1.4-Erweiterung) FeatureHouse Kommandozeilenwerkzeug für Java, C#, C, Haskell, UML, FeatureC++ Alternative zu AHEAD für C++ FeatureIDE Eclipse Plugin für AHEAD, FeatureHouse und FeatureC++ Automatisches Bauen, Syntax Highlighting, etc

31 Kästner, Apel, Saake EPMD Folie 6-34 FeatureIDE Demo Feature-Modell anlegen Jak-Dateien erstellen Equation-Datei erstellen - Programm starten

32 Kästner, Apel, Saake EPMD Folie 6-35 Zusammenfassung zum AHEAD-Ansatz Eine Basisklasse + beliebige Verfeinerungen (Rollen) Klassenverfeinerungen können Felder einführen Methoden einführen Methoden erweitern Feature-Modul (Kollaboration): Verzeichnis mit Basisklassen und/oder Verfeinerungen Beim Kompilieren werden Basisklasse + Verfeinerungen der ausgewählten Feature-Module zusammengebaut

33 Kästner, Apel, Saake EPMD Folie 6-36 Grundidee Agenda Implementierung mit AHEAD Prinzip der Uniformität Formalisierung

34 Kästner, Apel, Saake EPMD Folie 6-37 Prinzip der Uniformität Software besteht nicht nur aus Java-Quellcode Andere Programmiersprachen (z. B. C++, Javascript) Build-Skripte (Make, XML) Dokumentation (XML, HTML, PDF, Text, Word) Grammatiken (BNF, ANTLR, JavaCC, Bali) Modelle (UML, XMI,...) Alle Software-Artefakte müssen verfeinert werden können Integration von verschiedenen Artefakten in Kollaborationen

35 Kästner, Apel, Saake EPMD Folie 6-38 Prinzip der Uniformität Features are implemented by a diverse selection of software artifacts and any kind of software artifact can be subject of subsequent refinement. -- Don Batory Don Batory

36 Kästner, Apel, Saake EPMD Folie 6-39 Beispiel: Prinzip der Uniformität Graph Edge Node Buildfile Documentation Base Grap h.jak Edge.jak Node.jak build. xml index.htm Search Grap h.jak Node.jak build. xml index.htm Directed Grap h.jak Edge.jak build. xml index.htm Weighted Grap h.jak Edge.jak build. xml index.htm Colored Node.jak Node.jak build. xml index.htm Weitere Dateien: Grammatiken, Unit-Tests, Modelle, Spezifikationen, u.v.m.

37 Kästner, Apel, Saake EPMD Folie 6-40 Werkzeugunterstüzung AHEAD Konzept sprachübergreifend, separate Tools für: Jak (Java 1.4) Xak (XML) Bali-Grammatiken FeatureHouse sprachübergreifendes Tool, leicht erweiterbar, z. Z. implementiert für: Java 1.5 C# C Haskell JavaCC- und Bali-Grammatiken XML Virtuelle Klassen, Traits, Scala sind sprachabhängig

38 Kästner, Apel, Saake EPMD Folie 6-41 Grundidee Agenda Implementierung mit AHEAD Prinzip der Uniformität Formalisierung

39 Kästner, Apel, Saake EPMD Folie 6-42 Wozu eine Formalisierung? Diskussion bisher hauptsächlich auf Ebene verschiedener Sprachkonstrukte Eine Formalisierung zeigt die gemeinsamen Ideen in einem abstrakten Modell und ignoriert ablenkende Details Abstrahiert von Details in AHEAD, FeatureHouse oder anderen Sprachen Ermöglicht die Diskussion von Konzepten unabhängig einer konkreten Programmiersprache ( Prinzip der Uniformität)

40 Kästner, Apel, Saake EPMD Folie 6-43 Wozu eine Formalisierung? Erlaubt später neue Operationen auf Features (z. B. Typprüfung oder Interaktionsanalyse) formal und sprachunabhängig zu diskutieren Vereinfacht die Implementierung von Werkzeugen (z. B. Komposition innerer Klassen?) Analyse algebraischer Eigenschaften von Feature- Komposition potentielle Optimierung

41 Kästner, Apel, Saake EPMD Folie 6-44 Feature-Komposition Features können mit anderen Features komponiert werden und bilden so komplexere Features Programme sind selber auch (zusammengesetzte) Features Menge F der Features; Kompositionsoperator (assoziativ, aber nicht kommutativ, wie wir zeigen werden)

42 Kästner, Apel, Saake EPMD Folie 6-45 Features modelliert als Bäume Ein Feature besteht aus einem oder mehreren Code-Artefakten, je mit einer internen Struktur Features werden als Bäume modelliert (Feature StructureTree FST), welche die Struktur der Artefakte reflektieren util package util; class Calc { int e0 = 0, e1 = 0, e2 = 0; void enter(int val) { e2 = e1; e1 = e0; e0 = val; void clear() { e0 = e1 = e2 = 0; String top() { return String.valueOf(e0); e0 Calc e1 e2 top enter clear Feature Structure Tree (FST)

43 Kästner, Apel, Saake EPMD Folie 6-46 Struktur von FSTs Nur die wesentliche Struktur eines Artefakts im FST Beispiel Java: Packages, Klassen, Methoden, und Felder abgebildet Statements, Parameter, Initialwert von Feldern nicht im FST abgebildet Andere Granularität möglich je nach Programmiersprache und Aufgabe wählen

44 Kästner, Apel, Saake EPMD Folie 6-47 Eigenschaften von FSTs Knoten im FST haben einen Namen und einen Typ Ordnung der Kinder kann relevant sein package util; class Calc { int e0 = 0, e1 = 0, e2 = 0; void enter(int val) { e2 = e1; e1 = e0; e0 = val; void clear() { e0 = e1 = e2 = 0; String top() { return String.valueOf(e0); e0 util Calc package class e1 e2 top enter clear field field field method method method

45 Kästner, Apel, Saake EPMD Folie 6-48 package util; class Calc { void add() { e0 = e1 + e0; e1 = e2; feature: Add Komposition durch Überlagerung von Bäumen feature: CalcBase package util; class Calc { int e0 = 0, e1 = 0, e2 = 0; void enter(int val) { e2 = e1; e1 = e0; e0 = val; void clear() { e0 = e1 = e2 = 0; String top() { return String. valueof(e0); = feature: CalcAdd package util; class Calc { int e0 = 0, e1 = 0, e2 = 0; void enter(int val) { e2 = e1; e1 = e0; e0 = val; void clear() { e0 = e1 = e2 = 0; String top() { //... void add() { e0 = e1 + e0; e1 = e2; util Calc util = Calc util Calc add e0 e1 e2 top enter clear e0 e1 e2 top enter clear add

46 Kästner, Apel, Saake EPMD Folie 6-49 Überlagerung von Bäumen Rekursive Überlagerung (superimposition) der Knoten, beginnend bei der Wurzel Zwei Knoten werden überlagert, wenn ihre Vaterknoten überlagert wurden... und beide den gleichen Namen und Typ haben Nach der Überlagerung von zwei Knoten, werden ihre Kinder rekursiv überlagert Wenn zwei Knoten nicht überlagert wurden, werden sie beide dem Ergebnisbaum an entsprechender Stelle hinzugefügt

47 Kästner, Apel, Saake EPMD Folie 6-50 Terminal- und Nichtterminalknoten Nichtterminalknoten Transparente Knoten Können Kinder haben Name und Typ, aber keinen weiteren Inhalt Können problemlos überlagert werden Terminalknoten Haben keine Kinder Name und Typ Können weiteren Inhalt haben, Überlagerung daher nicht trivial

48 Kästner, Apel, Saake EPMD Folie 6-51 Feature-Komposition Rekursive Komposition der FST-Elemente package package package (auch für Unterpakete) class class class (auch für innere Klassen) method method? field field?

49 Kästner, Apel, Saake EPMD Folie 6-52 Überlagerung von Terminalknoten Option 1: Zwei Terminalknoten mit gleichem Namen und Typ können nie überlagert werden Option 2: Zwei Terminalknoten mit gleichem Namen und Typ können unter bestimmten Umständen überlagert werden method method method, falls eine Methode die andere erweitert, z. B. indem sie Super oder original aufruft field field field, falls min. ein Attribut keinen Initialwert hat

50 Kästner, Apel, Saake EPMD Folie 6-53 Komposition von Terminalknoten class Calc { int count = 0; void enter(int val) { original(val); count++; class Calc { int count; void enter(int val){ = e2 = e1; e1 = e0; e0 = val; class Calc { int count = 0; void enter(int val) { e2 = e1; e1 = e0; e0 = val; count++;... Calc... = Calc... Calc enter count enter count enter count

51 Kästner, Apel, Saake EPMD Folie 6-54 Bedingungen durch bisherige Definition Die Struktur eines Features muss hierarchisch sein (Baumstruktur) Jedes Strukturelement muss einen Namen und einen Typ haben Ein Element darf nicht zwei Kinder mit dem gleichen Namen und dem gleichen Typ haben Elemente, die keine hierarchische Unterstruktur haben (Terminale) müssen eine spezielle Kompositionsregel angeben oder können nicht komponiert werden

52 Kästner, Apel, Saake EPMD Folie 6-55 Welche Sprachen können mittels FSTs modelliert werden? Objektorientierte Sprachen erfüllen meist die Bedingungen Einige andere Sprachen, u. a. Grammatiken, erfüllen die Bedingungen auch Sprachen, welche die Bedingungen nicht erfüllen gelten als nicht feature-ready, da sie nicht ausreichend Struktur aufweisen Einige Sprachen können mit zusätzlicher Struktur angereichert werden, z. B. XML

53 Kästner, Apel, Saake EPMD Folie 6-56 Feature-Algebra Feature-Algebra beschreibt Operationen auf FSTs Beschreibt die Komposition als algebraische Ausdrücke

54 Kästner, Apel, Saake EPMD Folie 6-57 Pfade und Introduktionen Jedes Element im FST wird als atomare Introduktion bezeichnet Notation als Pfadausdruck i 1 = util i 3 = util.calc.enter util Calc enter count i 2 = util.calc i 4 = util.calc.count Die hierarchische Struktur ist in den Identifikatoren kodiert

55 Kästner, Apel, Saake EPMD Folie 6-58 Introduktionen kodieren Feature- und Typinformationen Zusätzlich zu der in den Folien verwendeten Notation müssen die Pfade auch die Typen und das Feature kodieren util package Calc class e0 e1 e2 top enter clear field field field method method method i CalcBase:util package. Calc class.enter method

56 Kästner, Apel, Saake EPMD Folie 6-59 Features und Introduktionen Ein Feature kann durch eine Summe von Introduktionen ( ) beschrieben werden CalcProg CalcBase CalcBase.Calc CalcBase.Calc.e0 CalcBase.Calc.e1 CalcBase.Calc.e2 CalcBase.Calc.enter CalcBase.Calc.clear CalcBase.Calc.top Ein Compiler kann diesen Ausdruck auswerten, optimieren und Code erzeugen

57 Kästner, Apel, Saake EPMD Folie 6-60 Feature-Komposition Zwei Features werden komponiert indem ihre Introduktionen addiert werden F j Werden zwei Introduktionen mit gleichem Pfad addiert, werden diese überlagert (oder gelten als Fehler) Aus der Introduktionssumme kann jetzt rückwärts wieder ein FST erstellt werden F i

58 Kästner, Apel, Saake EPMD Folie 6-61 Neue Knoten & Unterbäume einfügen Calculator Calculator Calculator Display notify Display show = show Display notify Calculator Calculator Calculator Display notify Calc enter = Calc enter Display notify

59 Kästner, Apel, Saake EPMD Folie 6-62 Anwendungsfälle der Introduktionssumme Einfügen neuer Knoten und/oder Unterbäume Hinzufügen neuer Pakete, Klassen, Schnittstellen, Methoden, Attribute Überschreiben von Blattknoten Methoden überschreiben Initialwert von Feldern überschreiben (Konkatenieren von implements und extends Klauseln)

60 Kästner, Apel, Saake EPMD Folie 6-63 Introduktionssumme Die Summe über der Menge I der Introduktionen erzeugt einen idempotenten, nichtkommutativen Monoid ( I,, ξ ) Assoziativität: (a b) c = a (b c) Identität: ξ a = a ξ = a (ξ - Xi ist die leere Introduktion) Nicht-Kommutativität: a b b a (aufgrund von nicht-kommutativer Terminal- Komposition) Idempotenz: a a = a (sogar entfernte Idempotenz: a b a = b a )

61 Kästner, Apel, Saake EPMD Folie 6-64 Formalisierung Fazit Soweit FST-Modell Features sind Bäume Komposition durch Addition der Baumelemente Spezielle Kompositionsregeln für Terminale Die Feature-Algebra mit Introduktionssumme kann den gesamten Funktionsumfang Kollaborationssprachen (z. B. Jak) modellieren Ausblick Später Erweiterung um Aspekte Einführung eines weiteren Konstrukts neben Introduktionen: die Modifikation

62 Kästner, Apel, Saake EPMD Folie 6-65 Wozu war das ganze gut? Die Algebra zeigt die Grenzen von Feature-Komposition à la Jak... die Anforderungen an Sprachen um feature-ready zu sein... grundsätzliche, wiederverwendbare Mechanismen für die Implementierung von Kompositionstools

63 Kästner, Apel, Saake EPMD Folie 6-66 FeatureHouse FeatureHouse entstand aus der Formalisierung

64 Kästner, Apel, Saake EPMD Folie 6-67 FeatureHouse-Fallstudien Features LOC Artifact Types Description FFJ JavaCC Grammar of the FFJ language Arith Haskell Arithmetic expression evaluator GraphLib C Low level graph library Phone XMI/UML Phone system ACS XMI/UML Audio control system CMS XMI/UML Conference management system GPL (C#) C# Graph product line (C# version) GBS XMI/UML Gas boiler control system (IKERLAN) GPL (Java) Java, XHTML Graph product line (Java version) FGL Haskell Functional graph library Violet Java, Text Visual UML editor GUIDSL Java Product line configuration tool Berkeley DB Java Oracle's embedded DBMS

65 Kästner, Apel, Saake EPMD Folie 6-68 Perspektiven der Algebra Diskussion von Sprachmitteln unabhängig einer spezifischen Sprache, z. B. Was würde es bedeuten wenn ein Feature in einem Ausdruck mehrfach vorkommen kann (z. B. X Y X)? Wie können wir Komposition von Strukturen erreichen, bei dem die Reihenfolge der Kinder wichtig ist (z. B. XML)? Unter welchen Voraussetzungen ist Feature-Komposition kommutativ? Wie können wir eine Sprache feature-ready gestalten (insb. Definition von Sprachmechanismen für Terminalüberlagerung)? Was passiert wenn wir das Löschen von Methoden erlauben wollen?

66 Kästner, Apel, Saake EPMD Folie 6-69 Zusammenfassung Feature-orientierte Programmierung löst das Feature-Traceability-Problem durch Kollaborationen und Rollen (1:1 Mapping) Implementierung mittels Klassenverfeinerungen Prinzip der Uniformität Formalisierung als Feature Structure Trees und Feature-Algebra

67 Kästner, Apel, Saake EPMD Folie 6-70 Ausblick Implementierung von querschneidenen Belangen kann in bestimmten Fällen sehr aufwendig sein Aspektorientierung Features sind nicht immer unabhängig. Wie implementiert man abhängige Kollaborationen? Bewertung / Abgrenzung

68 Kästner, Apel, Saake EPMD Folie 6-71 Literatur I D. Batory, J. N. Sarvela, and A. Rauschmayer. Scaling Step- Wise Refinement. IEEE Transactions on Software Engineering, 30(6), [Vorstellung von AHEAD] S. Apel, C. Kästner, and C. Lengauer. FeatureHouse: Language-Independent, Automated Software Composition. In Proc. Int l Conf. Software Software Engineering, [Überblick über FSTs und FeatureHouse] M. Kuhlemann, M. Rosenmüller, S. Apel, and T. Leich. Streamlining Feature-Oriented Designs. In Proc. Int'l. Symp. Software Composition, 2007 [Vergleich von Mixin und Jampack]

69 Kästner, Apel, Saake EPMD Folie 6-72 Literatur II S. Apel, C. Lengauer, B. Möller, and C. Kästner. An Algebra for Features and Feature Composition. In Proc. Int l Conf. Algebraic Methodology and Software Technology, Springer, [Formalisierung & Feature-Algebra]