Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering1 Produktlinien für Software- und Systementwicklung Hauptseminar Sommersemester 2006,

Präsentation zum Thema: "Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering1 Produktlinien für Software- und Systementwicklung Hauptseminar Sommersemester 2006,"—  Präsentation transkript:

1 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering1 Produktlinien für Software- und Systementwicklung Hauptseminar Sommersemester 2006, Prof. Broy Rainer Burgstaller Garching, 19.06.2006 Product Line Evolution and AOP

2 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering2 Agenda AOP in a nutshell: Quo vadis? Einführung, Grundlagen, Überblick PL und AOP NAPLES –Vorgehensweise –Lifecycle-Abdeckung –Unterstützung Requirements Engineering –Einsatzerfahrung, Verbreitung Zusammenfassung und Fazit Diskussion

3 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering3 AOP Gleich mal vorweg … OO war und ist nach wie vor sehr erfolgreich. Aber … –Die Komplexität der Systeme hat zugenommen (und nimmt nach wie vor zu). These: Jeder Entwickler ist in der Lage große Software Systeme zu entwickeln …

4 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering4 Software Engineering is a Piece of Cake?

5 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering5 Software Engineering is a Piece of Cake? Persistence Transaction Security Logging Distributio n Scalability Performanc e Fault Tolerance

6 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering6 Problem “I have a small mind and can only comprehend one thing at a time”. Edsger Dijkstra

7 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering7 Strategie für große Probleme: Separation of Concerns “When faced with any large task, it is usually best to put aside some of its aspects for a moment and concentrate on others“ David Gries “Divide et Impera” Julius Caesar

8 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering8 Separation of Concerns - Ordnung

9 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering9 Separation of Concerns - Mülltrennung

10 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering10 Wie sieht das nun im Software Engineering aus??

11 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering11 Ein Beispiel: Tomcat Gute Trennung der Belange (Concerns): XML parsing

12 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering12 Ein Beispiel: Tomcat Faire Trennung der Belange (Concerns): URL pattern matching

13 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering13 Ein Beispiel: Tomcat Schlechte Trennung der Belange: Logging in Tomcat

14 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering14 Querschneidende Belange (Crosscutting Concerns) CCC sind verflochten (tangled) und verteilt (scattered) im System, und können aufgrund dessen nicht klar lokalisiert werden. Einige Aspekte/Belange sind von Natur aus schwer zu modularisieren (im Sinne OO Modulen).

15 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering15 Definitionen Joinpoint – ein Punkt im Ausführungsfluss eines Programms. Pointcut – selektieren von joinpoints; beschreibt eine Menge von joinpoints. Advice – erweitern oder einschränken von Belangen bei joinpoints. Aspekt – Element zur Modularisierung von sonst querschneidenden Belangen. Viewpoint – Blickwinkel aus dem man etwas betrachtet (Betrachtungsweise auf ein Artefakt).

16 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering16 Konsequenzen von schlechtem Separation of Concerns Redundanz –ähnliche Code Fragmente an vielen Stellen Code ist schwer zu verstehen –schwer das Gesamtbild zu bekommen Wartung/Änderungen ist/sind sehr teuer –Code muss lokalisiert werden –Code muss in vielen Stellen geändert werden Wiederverwendung wird erschwert

17 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering17 AOP Was können wir tun??

18 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering18 Lösung Beide Teile, sprich: Anwendungscode und Aspektcode voneinander unabhängig entwickeln Doch: Wie werden die beiden Teile miteinander kombiniert?? … +

19 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering19 Lösung Durch Verwendung eines Aspekt-Webers Weaver

20 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering20 Überblick Gibt verschiedene Zeitpunkte des Webens; zur –Übersetzungszeit, –Ladezeit und –zur Laufzeit. Bekannteste Implementierungen –AspectJ –AspectWerkz –JBossAOP –AspectC++

21 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering21 Agenda AOP in a nutshell: Quo vadis? Einführung, Grundlagen, Überblick PL und AOP NAPLES –Vorgehensweise –Lifecycle-Abdeckung –Unterstützung Requirements Engineering –Einsatzerfahrung, Verbreitung Zusammenfassung und Fazit Diskussion

22 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering22 PL und AOP Software Systeme „leben“ –neue Anforderungen bzw. Funktionalität –Anpassungen –Erweiterungen 80% der Aufwendungen machen Wartung und Weiterentwicklung aus. Deshalb sollte Wartbarkeit und Erweiterbarkeit besondere Beachtung geschenkt werden  Speziell für SPL

23 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering23 PL und AOP Instanzen einer Produktfamilie unterscheiden sich durch die Features welche sie enthalten. Während des SPL Entwicklungs-Prozesses werden Gemeinsamkeiten und Unterschiede herausgearbeitet. Funktionalität eines Features umspannt oft mehrere Teile eines Systems. Erfahrung hat gezeigt, dass Klassen im Sinne von OO Features nur unzureichend „einfangen“ Feature entspricht oft einem Crosscutting Concern (  AOP) Werden Features in Modulen gekapselt, kann man sie leichter „rein“ und „raus“ nehmen.  AO-Ansätze besser geeignet !?

24 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering24 Agenda AOP in a nutshell: Quo vadis? Einführung, Grundlagen, Überblick PL und AOP NAPLES –Vorgehensweise –Lifecycle-Abdeckung –Unterstützung Requirements Engineering –Einsatzerfahrung, Verbreitung Zusammenfassung und Fazit Diskussion

25 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering25 NAPLES Ziel: automatisieren der zeitaufwendigen Aktivitäten wie das identifizieren von (querschneidenden) Belangen, Viewpoints, Gemeinsamkeiten und Variabilitäten Dabei kann prinzipiell auf beliebigen Dokumenten gearbeitet werden, unabhängig von deren Struktur. Beispiele: unstrukturierte Interviews, Beschreibungen in PROSA, …

26 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering26 NAPLES AORE... Aspect Oriented Requirements Engineering FODA... Feature Oriented Domain Analysis

27 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering27 NAPLES – Mining Elements –Eingabe: Anforderungsdokumente, Benutzerhandbücher, dokumentierte Interviews, … –Zweck: wichtige Konzepte identifizieren, diese dem Benutzer so aufzubereiten, dass davon ein geeignetes strukturiertes Modell abgeleitet werden kann (AORE und FODA Modell) –Funktionsweise: EA-Miner verwendet natürliche Spracherkennungsmechanismen von WMATRIX

28 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering28 NAPLES – WMATRIX (Funktionen) –WMATRIX stellt Funktionen wie Wortartanalyse, semantische Analyse, Worthäufigkeitsanalyse usw. zur Verfügung –Wortartanalyse zielt auf die Herauslockung von Wortarten (z.B.: Hauptwörter, Zeitwörtern) ab. –Semantische Analyse hat sich zum Ziel gesetzt verwandte oder verschiedene Ausdrücke von Wörtern zu gruppieren Bsp: driver(s), vehicle(s), traffic  „land transport“

29 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering29 NAPLES – Mining Elements (Resultat) –WMATRIX produziert aus der Eingabedatei eine XML-Datei, welche für jedes Wort die Wortart und die semantische Bedeutung markiert. Dabei ist die XML-Datei in Sätzen strukturiert ( … ) Bsp authorised JJ …allgemeines Eigenschaftswort S7.4+ …bedeutet „Zulassung/Erlaubnis“ –Mit diesen Mitteln können Domänen Konzepte mit besonderem Stellenwert erkannt werden (Early Aspects, Viewpoints, Gemeinsamkeiten und Variabilitäten)

30 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering30 NAPLES – Early Aspects Identifizierung –basiert auf einem domänenspezifischen Lexikon (XML Datei), welches erstellt wurde unter Berücksichtigung von nichtfunktionalen Wörtern vorhanden im NFR (Nonfunctional Requirements) Framework Katalog. –EA-Miner vergleicht nun jedes Wort, ob es gleichwertig („equalTo“) zu einem NFR Konzept ist. –Die „equalTo“-Operation ist dabei definiert wie folgt: if a word is lexically equal, ignoring case and suffixes, to the word in the lexicon AND the word has the same semantic class as a word in lexicon.

31 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering31 NAPLES – Vorgehensweise

32 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering32 NAPLES – Gemeinsamkeiten und Variabilitäten Analyse –Basiert auf einem domänenspezifischen Lexikon (XML-Datei) für z.B. Tempomaten (Bsp.: Fahrzeug, Fahrer, Geschwindigkeit, …) –EA-Miner wendet auch hier die „equalTo“-Operation auf jedes Wort an

33 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering33 NAPLES – Gemeinsamkeiten und Variabilitäten Analyse

34 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering34 NAPLES – Gemeinsamkeiten und Variabilitäten

35 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering35 NAPLES – Zusammenfassung –Viewpointsidentifizierung wird unterstützt –Early Aspects spiegeln querschneidende Belange wider, welche Viewpoints durchkreuzen –Viewpoints helfen die Implementierung der funktionalen Anforderungen abzuleiten –Early Aspects dienen zur Lokalisierung von CCCs welche mehrere Features betreffen und nicht durch das FODA- Modell repräsentiert werden

36 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering36 NAPLES – Vorgehensweise

37 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering37 Lifecycle-Abdeckung NAPLES

38 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering38 Unterstützung im Requirements-Engineering NAPLES unterstützt mehr oder weniger alle Phasen des Produktlinien-Lifecycle ein bißchen – vor allem aber das Domain Engineering Primärer Fokus war die Unterstützung der RE-Phase Unterstützung der RE-Phase –Elicitation  Requirements Engineer fokusiert sich nur auf bestimmte Teile des Dokuments –Strukturierung  Feature-Modell kann als oberstes Strukturierungsschema für Anforderungen dienen. Ea-Miner stellt bestimmte Sichten auf die Anforderungen dar. –Modellierung  Feature Diagramm wird für Requirements benutzt Traceability –für nicht querschneidende als auch für querschneidende Belange gegeben (da sehr früh erkannt).

39 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering39 Einsatzerfahrung, Verbreitung Bereits (erfolgreich?) auf einzelne Fallstudien angewendet. Noch nicht sehr verbreitet, da es sich um einen Prototypen handelt. Wurde der Öffentlichkeit noch nicht zugänglich gemacht

40 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering40 Agenda AOP in a nutshell: Quo vadis? Einführung, Grundlagen, Überblick PL und AOP NAPLES –Vorgehensweise –Lifecycle-Abdeckung –Unterstützung Requirements Engineering –Einsatzerfahrung, Verbreitung Zusammenfassung und Fazit Diskussion

41 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering41 Zusammenfassung und Fazit NAPLES ist ein vielversprechender Ansatz, der die Produktlinienorientierte Entwicklung durch den Lebenszyklus hindurch unterstützt/unterstützen wird. Verwendet verschiedene Techniken wie Wortanalyse, und AOSD Techniken um „automatische“ Unterstützung für (querschneidende) Belange zu erreichen. Noch nicht alle Phasen werden unterstützt, da sich der Ansatz noch in den frühen Phasen der Entwicklung befindet. Primärer Fokus war auf Anforderungsanalyse, inzwischen aber schon auf Design und Implementierung erweitert (siehe Bsp)

42 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering42 Zusammenfassung und Fazit unterstützt zeitintensive und fehleranfällige Aktivitäten. ermöglicht dem Anforderungs-Entwickler ein schnelles Verständnis über ein System zu erlangen. unterstützt Modell-Verfeinerungen und Modell-Erstellungen. Ansatz konnte leider nicht kritisch in Aktion bewertet werden (da Werkzeug noch nicht verfügbar). Kann gegenwärtig nur in Verbindung mit englischen Texten (Anforderungen) angewendet werden

43 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering43 Ausblick/Aktivitäten First Workshop on Aspect-Oriented Product Line Engineering Part of GPCE 06 and colocated with OOPSLA 06 Sunday October 22, 2006 Portland, Oregon http://www.softeng.ox.ac.uk/aople Siemens: AMPLE-Projekt; Start: Oktober 2006. Framed Aspects Ansatz wird von Lancaster University im Rahmen des Projekts weiter verfolgt/erneut aufgegriffen.

44 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering44 Agenda AOP in a nutshell: Quo vadis? Einführung, Grundlagen, Überblick PL und AOP NAPLES –Vorgehensweise –Lifecycle-Abdeckung –Unterstützung Requirements Engineering –Einsatzerfahrung, Verbreitung Zusammenfassung und Fazit Diskussion

45 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering45 ?

46 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering46 Backup Folien

47 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering47 Beispiel: Observer Pattern

48 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering48 Verwendung des Observer Patterns

49 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering49 Verwendung des Observer Design Patterns Anwenden des Musters fügt Code bei allen Beteiligten ein Muster verschwindet im Code Implementierung des Muster kann nicht wiederverwendet werden.

50 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering50 Realisierung des Observer Patterns mit Aspekten

51 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering51 ObserverProtocol Aspekt Rollen Observer update konzeptuelle Op Update Logik Beteiligte Obj

52 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering52 ColorObserver Aspekt Rollen Mapping Mapping der konzeptuellen Op Update Logik

53 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering53 Vorteile des Aspekt-Ansatzes Lokalität –Pattern Code ist in den abstrakten und konkreten Aspekt- Klassen, nicht in den „teilnehmenden“ Klassen –Änderungen sind konsistent –(leichter zu verstehen, leichter zu debuggen) Wiederverwendbarkeit –Pattern Code ist abstrakt und wiederverwendbar Pattern Code ist leichter entfernbar

54 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering54 ObserverProtocol Aspekt Rollen Observer update konzeptuelle Op Update Logik Beteiligte Obj

55 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering55 Beispiel: Durchsetzen von Architekturrichtlinien Laufzeitfehler

56 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering56 Beispiel: Durchsetzen von Architekturrichtlinien Übersetzungsfehler

57 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering57 NAPLES – WMATRIX

58 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering58 NAPLES – WMATRIX

59 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering59 NAPLES – WMATRIX

60 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering60 NAPLES – Vorgehensweise

61 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering61 NAPLES – Vorgehensweise

62 Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering62 NAPLES – Vorgehensweise