Softwareproduktlinien Teil 13: The Big Picture/Ausblick

Transkript

1 Softwareproduktlinien Teil 13: The Big Picture/Ausblick Sven Apel (Universität Passau) Christian Kästner (Universität Marburg) Gunter Saake (Universität Magdeburg) 1

2 Was haben wir gelernt? Grundlagen Software-Produktlinien Klassische Implementierung (Parameter, #ifdefs, Framework, Komponenten ) und ihre Grenzen Vision Feature-orientierter Produktlinien Sprachunterstützung für Features Kollaborationen, Rollen, Aspekte, AFMs, etc. Behandlung von Feature-Interaktionen Verbesserte Präprozessoren: Virtuelle Trennung 2

3 Perspektive? Wie passen die Inhalte der Vorlesung in den großen Gesamtzusammenhang der Softwareentwicklung? Inhalte der Vorlesung 3

4 Softwareproduktlinien Featureorientierte Produktlinien AOP 4

5 Generative Programmierung Metaprogrammierung Model-Driven Engineering Feature- Orientierung Domänenspezifische Sprachen Software- Produktlinien Software- Architektur Service-Orientierte Architekturen 5

6 Weitere Produktlinien-Themen Definition Variabilität Domain-Analyse, Scoping, Requirements Engineering ROI-Bewertung, Produktmanagement, Marktanalyse, Risiko-Management Organisation Projektinitiierung, Finanzierung Organisationsplanung, Rollen, Verantwortlichkeiten Prozesse Architektur und Implementierung Frameworks, Komponenten, Präprozessoren, COTS Testen, Verifikation 6

7 Einige aktuelle Forschungsthemen (SPLC 2011) Product Line Engineering using Domain-Specific Languages Model Comparison to Synthesize a Model-Driven Software Product Line Automatic Derivation of a Product Performance Model from a Software Product Line Model Formal Description of Variability in Product Families Requirements Uncertainty in a Software Product Line Optimizing User Guidance during Decision-Makin Scalable Prediction of Non-functional Properties in Software Product Lines 7

8 Software Ecosystems Offene Plattformen Jeder kann Erweiterungen beitragen Massschneiderbar Geschlossene Variabilitätsmodellierung und Produktlinienanalyse nicht möglich 8

9 Generative Programmierung I Software wird durch einen Generator anhand einer Spezifikation auf Basis von Codefragmenten weitestgehend automatisch erzeugt Generative programming (GP) is a style of computer programming that uses automated source code creation through generic classes, prototypes, templates, aspects, and code generators to improve programmer productivity. Anwendungsgebiete Formulargeneratoren Compiler-Compiler Parsergeneratoren Anfrageoptimierung Eingabe: Problembeschreibung Generator (Konfigurationswissen) Ausgabe: Programm 9

10 Generative Programmierung II FOP ist eine Form von GP Feature-Selektion abstraktes Eingabeprogramm Feature-Module Code-Schablonen Feature-Komposition Generierung GP darüber hinaus Komplexere Eingaben als Feature-Auswahl (z. B. Formularbeschreibung, Grammatik, Domänenspezifische Sprachen ) Jede Form von Generatoren Metaprogrammierung (Programme manipulieren Programme) 10

11 Metaprogrammierung Programme manipulieren Programme Einteilung in Ebenen Basisprogramm, 1-n Metaebenen (Metaprogramme) Durch Abstraktion Programmiereffizienz erreichen GP mit Programmen als Eingabe Meta-Programm AOP & FOP als Meta-Programmierung interpretierbar Metaprogramming (MP) is the writing of computer programs that write or manipulate other programs (or themselves) as their data or that do part of the work during compile time that is otherwise done at run time. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually. 11

12 Domänenspezifische Sprachen I Prinzip der Abstraktion Drücke das Problem und die Lösung in einer dafür geeigneten Sprache aus Generator/Interpreter erzeugt Zielcode Vorteile: weniger Redundanz, bessere Lesbarkeit, weniger technische Details, leicht erlernbar, bessere Fehlermeldungen, Set camera size: 400 by 300 pixels. Set camera position: 100, 100. Move 200 pixels right. Move 100 pixels up. Move 250 pixels left. Move 50 pixels down. 12 A domain-specific language (DSL) is a programming language designed for, and intended to be useful for, a specific kind of task. This is in contrast to a general-purpose programming language, such as C, or general-purpose modeling languages like UML.

13 Domänenspezifische Sprachen II Anfragesprachen Unix-Shell-Skripte Tabellenkalkulationsprogramme Reguläre Ausdrücke Dokument- und Datenbeschreibungssprachen Graphbeschreibungssprachen Sprache zum Beschreiben von Formularen etc. 13

14 Domänenspezifische Sprachen III Domänenspezifische Sprache als Eingabe für GP Zusammenhang Produktlinien/FOP: Feature-Modell DSL Feature Sprachkonstrukt in einer DSL Feature-Komposition Übersetzungsprozess DSL: M = { BasicGraph,Weighted,Colored, Search} Programme: 14 Prog1 Weighted BasicGraph Prog2 Colored BasicGraph Prog3 Sear ch Weighted BasicGraph

15 Model-Driven Engineering I Software wird durch Modelle beschrieben Abstrakte Modelle werden in konkrete überführt Transformation kann in mehreren Schritten erfolgen Modell am Ende der Transformationskette ist die Implementierung des Systems (in Form von Code) Model-Driven Engineering (MDE) or Model-Driven Development (MDD) refer to the systematic use of models as primary engineering artifacts throughout the engineering lifecycle. MDE/MDD can be applied to software, system, and data engineering. Models are considered as first class entities. 15

16 Model-Driven Engineering II MDE ist eine Form der Generativen Programmierung Modell als Eingabe, neues Modell oder Code als Ausgabe MDE als Domänenspezifische Sprache Modellierungssprache für eine Domäne, z. B. BPEL Zusammenhang zu Feature-Orientierung aus verschiedenen Sichten A) Feature-Auswahl als Modell, das zu Quelltext transformiert wird (wie bei GP/DSL) B) Features können Modelle verfeinern 16

17 MDE + FOP Modelltransformation 17 (MDE) Modell/Klassenverfeinerung (FOP) Generierung

18 Feature-Oriented Model-Driven Development 18

19 Software-Architektur I Prinzip der Abstraktion Betrachte die groben Software- Strukturen, die von Bedeutung sind; blende irrelevante Details aus Dokumentation und Entwurf stehen im Vordergrund Komponenten, Konnektoren, UML, Deployment, etc. The software architecture of a program or computing system is the structure or structures of the system, which comprise software compo-nents, the externally visible properties of those components, and the rela-tionships between them. 19

20 Software-Architektur + FOP Feature-Orientierung ist eine Art Software-Architekturen zu strukturieren Feature Komponente Glue-Code Konnektor (verbindet zwei Komponenten) Feature-Modell Produktlinienarchitektur Feature-Selektion Produktarchitektur Vorteil: Lücke zwischen Entwurf und Implementierung ist geschlossen, insbesondere querschneidende Belange 20

21 Service-Orientierte Architekturen Trennung von Belangen mittels Services Services sind verteilt und sprachunabhängig Verschiedenste Kommunikations- und Orchestrierungsmuster Service Oriented Architecture (SOA) is an architectural style that guides all aspects of creating and using business processes, packaged as services, throughout their lifecycle, as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes loosely coupled from the operating systems and programming languages underlying those applications. 21

22 Service-Orientierte Architekturen + FOP Zusammenhang SOA und FOP (Sicht #1) Feature-Modell SOA Feature Service Feature-Selektion Service-Lookup Feature-Komposition Service-Integration Zusammenhang SOA und FOP (Sicht #2) Eine Feature betrifft die Implementierung vieler Services, d.h., es schneidet quer Features als Mechanismus zur Konfiguration von Services 22

23 Querschneidende Features in SOA 23

24 Zusammenfassung Feature-Orientierung ist ein ganzheitlicher Ansatz zur Software-Entwicklung Verwandtschaft und Überlappungen mit mehreren aktuellen Entwicklungen in Forschung und Industrie Eine guter Startpunkt um in die Felder Software Engineering und Programmiersprachen einzutauchen, beruflich oder akademisch 24

25 Ausblick Bachelor-, Master-, Diplomarbeiten Software-/Laborpraktika Hiwi-Stellen 25

26 Analyse von Produktlinien Maße und Strukturanalyse Bug Finding, statische Analyse Testing Model Checking, Deduktion Interaktionen erkennen Nicht-funktionale Eigenschaften Kosten-Nutzen-Modelle 26

27 Modularität und Interfaces Features modular prüfen? Interfaces für Feature-Module? Nutzen und Kosten Syntaktisch vs. semantisch Funktionale vs. Nicht-funktionale Eigenschaften Separates Übersetzen von Feature-Modulen in einer offenen Welt (z.b. in Software Ecosystems) 27

28 Werkzeuge und Sprachen Analysewerkzeuge Compiler, Transformatoren Versionsverwaltung + Configuration Management Basierend auf bestehenden Werkzeugen FeatureIDE FeatureHouse Fuji CIDE SPLverifier FeatureVisu 28

29 Formale Modelle Modellierung von Kernaspekten von Produktlinien Struktur, Interaktionen Variabilität Verhalten Kosten-Nutzen-Verhältnis Aufbauend auf früheren Arbeiten Choice Calculus Feature Featherweight Java Feature Algebra Program Cubes 29

30 Literatur I (Software-Produktlinien allgemein) Paul Clements, Linda Northrop. Software Product Lines Practice and Pattern. Addison-Wesley Klaus Pohl, Günter Böckle, Frank van der Linden. Software Product Line Engineering. Foundations, Principles, and Techniques. Springer Günter Böckle, Peter Knauber, Klaus Pohl, Klaus Schmid (Hrsg.), Software-Produktlinien - Methoden, Einführung und Praxis. dpunkt

31 Literatur II K. Czarnecki and U. Eisenecker. Generative Programming - Methods, Tools, and Applications. Addison-Wesley, [Standardliteratur zu GP] J. Bartlett. The Art of Metaprogramming, Part 1: Introduction to Metaprogramming. IBM developerworks, [Überblick über Metaprogrammierung] M. Mernik, J. Heering, and A. Sloane. When and How to Develop Domain-Specific Languages. ACM Computing Surveys, 37(4), [Überblick über DSL-Entwicklung] 31

32 Literatur III L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice, Second Edition. Addison-Wesley, 2003 [Standardwerk zu Software-Architektur] D. Schmidt. Model-Driven Engineering. IEEE Computer, 39(2), [Einführung in MDE/MDD] T. Erl. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall, [Überblick über SOA] 32

33 Prüfungsvorbereitung Abfragewissen 50% Faktenwissen Vorlesungsfolien Evtl. Hilfsblatt auf Webseite 30% Verstehen Vergleich und Bewertung von Implementierungstechniken Was ist wann besser / mehr geeignet? 20% Anwendung Aufgabe wie bei Flip-Chart Präsentation Siehe nächste Folie 33

34 Aufgabe: Entwicklung eines Cloud Music Players Kontext: Sie sind Chef einer Entwicklungsbteilung im Unternehmen Elbe. Das Unternehmen möchte einen Cloud Music Player anbieten, der von anderen Entwicklern erweitert werden kann. Aufgabe: Welche Implementierungstechnik würden Sie vorschlagen? Begründen Sie ihren Vorschlag anhand mehrerer Kriterien (z.b. Erweiterbarkeit, Wartbarkeit, etc.). Skizzieren Sie die grundlegende Architektur bzw. geben Sie einen Eindruck wie die geforderte Variabilität realisiert werden kann. 34

35 Aufgabe: Entwicklung einer DBMS Produktlinie Kontext: Sie sind Chef einer Abteilung im Unternehmen Orakel. Das Unternehmen bietet bereits ein DBMS an. Aufgrund neuer Kundenanforderungen sollen nun aber anstatt eines generellen DBMS maßgeschneiderte Varianten ausgeliefert werden. Aufgabe: Welche Implementierungstechnik würden Sie vorschlagen? Begründen Sie ihren Vorschlag anhand mehrerer Kriterien (z.b. Erweiterbarkeit, Wartbarkeit, etc.) Skizzieren Sie die grundlegende Architektur bzw. geben Sie einen Eindruck wie die geforderte Variabilität realisiert werden kann. 35

36 Faktenwissen I (SPLs) 1. Frage: Was ist eine Softwareproduktlinie (SPL)? Features vs. Belange vs. Varianten vs. Versionen Warum SPLs? Was bringen sie? Application vs. Domain Engineering Wie führt man sie ein? (proaktive, reaktive, extraktiv) Feature Modelle (Warum? Wie sehen sie aus? Elemente?) Aussagenlogische Ausdrücke, Feature Diagramm Einordnung aller Themen (siehe nächste Folie) 36

37 Einordnung der Themen Domain Eng. Feature-Modell Wiederverwendbare Implementierungsartefakte Application Eng. 37 Feature-Auswahl Generator Fertiges Program

38 Faktenwissen II Klassiche Implementierungstechniken Parameter (wie realisiert und konfiguriert?) Design Patterns (Observer, Template, Strategy, Decorater) Vererbungshierarchien (wie? Motivation) Unflexibilität, Diamantenproblem Delegation statt Vererbung Modularität (Definition, Motivation, Kohäsion, Kapselung) Code scattering, code tangling, code replication 38

39 Faktenwissen III Versionierungssysteme Branching & Merging, Varianten vs. Versionen, Probleme Buildsysteme Wie funktionieren sie? Warum sind bisher alle Systeme unflexibel? Präprozessoren Was ist das? Wie funktionieren sie? Beispiele in Java nennen Vor- und Nachteile z.b. Lesbarkeit von Quellcode, Komplexität Feature-Tracability(-Problem) 39

40 Faktenwissen IV Komponenten (Kapselung, Interfaces, Geheimnisprinzip) Diskussion Vor- und Nachteile, Modularität, Granularität Frameworks Grundsätzliche Funktion (hot spots, plug-ins) White vs. Black-box -> Auswirkungen auf Modularität Querschneidende Belange (was ist das? Beispiele) Probleme, Tyrannei der dominanten Dekomposition (expression problem) Preplanning Problem (Erweiterungen vorhersehen) 40

41 Faktenwissen V Feature-orientierte Programmierung (FOP) Ziele (Feature-Kohäsion um tracability problem zu lösen) Virtuelle vs. physische Trennung von Belangen Feature-Komposition (Kollaborationen, Rollen, Aufmalen!) Klassen-/Methodenverfeinerung mit Jak (Jampack, Mixin) und FeatureHouse Prinzip der Uniformität Abstraktes Modell zur Komposition Feature Structure Trees (Aussehen, Aufmalen, wie funktioniert Komposition dort?) Feature-Algebra kommt nicht dran 41

42 Faktenwissen VI Aspekt-orientierte Programmierung (AOP) Ziel (Modularisierung querschn. Belange) Was kann AspectJ? (statische vs. dynamische Erweiterungen) Quantifizierung (Pointcuts vs. Join-Points -> was ist das?) Advice, explizite und anonyme Pointcuts, Unbewusstheitsprinzip (Diskussion) Probleme von AOP (fragile pointcut, Syntax, etc.) Aspectual-Feature Modules (AFM) Was ist das? Ziel? Welche Probleme werden gelöst? Wie soll das funktionieren? Heteronege vs. homogene & stat. vs. dyn. Erweiterungen 42

43 Faktenwissen VII Feature-Interaktionen (Beispiele, Einfluss auf Variabilität) Probleme (Verursachen Abhängigkeiten, optionale Features) Wie aufteilen in Module? Dyn. vs. statisch & domänen vs. impl. Interaktionen Lösungen (siehe Mengendiagramme) Ordnungen von Interaktionen Nicht-funktionale Eigenschaften (Definition, Fragen) 43 Qualitative vs. quantitativ Methoden des Messens (artefakt vs. ) Feature-Interaktionen (wie Messen? Wie Finden?) Modell zur Featurekomposition benutzen, um sich ändernde Deltas zu finden: (axbxc) - (axb) = c. a#c. b#c. a#b#c

44 Faktenwissen (die Letzte ;) ) Variability-aware Type-checking Wie funktioniert das? (Precondition -> boolische Formel vom Featuremodell + Referenzverfolgung auf Quelltextebene) Das war s 44