Produktlinien für Software- und Systementwicklung Hauptseminar Sommersemester 2006, Prof. Broy

1. Produktlinien für Software- und SystementwicklungHauptseminar Sommersemester 2006, Prof. Broy Product Line Evolution and AOP Rainer Burgstaller Garching, 19.06.2006 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

2. 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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

3. 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 … Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

4. Software Engineering is a Piece of Cake? Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

5. Software Engineering is a Piece of Cake? Security Persistence Transaction Logging Performance Distribution Scalability Fault Tolerance Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

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

7. Strategie für große Probleme: Separation of Concerns “Divide et Impera” Julius Caesar “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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

8. Separation of Concerns - Ordnung Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

9. Separation of Concerns - Mülltrennung Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

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

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

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

13. Ein Beispiel: Tomcat Schlechte Trennung der Belange: Logging in Tomcat Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

14. 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). Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

15. 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). Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

16. 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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

17. AOP • Was können wir tun?? Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

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

19. Lösung • Durch Verwendung eines Aspekt-Webers Weaver Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

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

21. 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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

22. 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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

23. 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 !? Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

24. 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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

25. 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, … Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

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

27. 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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

28. 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“ Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

29. 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 (<s> … </s>) Bsp <w pos=„JJ“ sem=„S7.4+“>authorised</w> 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) Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

30. 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. Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

31. NAPLES – Vorgehensweise Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

32. 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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

33. NAPLES – Gemeinsamkeiten und Variabilitäten Analyse Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

34. NAPLES – Gemeinsamkeiten und Variabilitäten Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

35. 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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

36. NAPLES – Vorgehensweise Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

37. Lifecycle-Abdeckung NAPLES NAPLES NAPLES Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

38. 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). Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

39. 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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

40. 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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

41. 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) Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

42. 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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

43. 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. Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

44. 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 Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

45. ? Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

46. Backup Folien Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

47. Beispiel: Observer Pattern Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

48. Verwendung des Observer Patterns Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

49. 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. Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering

50. Realisierung des Observer Patterns mit Aspekten Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering