1 / 62

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

Produktlinien für Software- und Systementwicklung Hauptseminar Sommersemester 2006, Prof. Broy. Product Line Evolution and AOP. Rainer Burgstaller Garching, 19.06.2006. Agenda. AOP in a nutshell: Quo vadis? Einführung, Grundlagen, Überblick PL und AOP NAPLES Vorgehensweise

shira
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related