Softwareproduktlinien - Refactoring von SPLs und ihren Produkten
|
|
- Max Hauer
- vor 7 Jahren
- Abrufe
Transkript
1 Softwareproduktlinien - Refactoring von SPLs und ihren Produkten Sven Apel (Universität Passau) Christian Kästner (CMU) Martin Kuhlemann, Gunter Saake (Universität Magdeburg)
2 Agenda Grundlagen Refaktorisierung Feature-Refaktorisierung Refaktorisierung zum Erstellen von Produktlinien Einordnung, Motivation Herausforderungen, Granularität Refaktorisierung zum Ändern von Produktlinien Features aufspalten und zusammenlegen Reihenfolge vertauschen 2
3 Refaktorisierung Definition Refactoring is the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improves its internal structure Ziele sind Verbesserung der Lesbarkeit Verbesserung der Verständlichkeit Verbesserung der Wartbarkeit Verbesserung der Erweiterbarkeit Kurz: Nachträgliche Verbesserung der Struktur von existierendem Quelltext Refactorings existieren fast für jede Programmiersprache 3 [Fowler 1999]
4 Refaktorisierung Ein Widerspruch? Widerspricht eigentlich traditionellen Top-Down Softwaretechnikansätzen, z. B. Wasserfallmodell In der Praxis häufig nötig, besonders wenn sich Software weiterentwickelt Grundlage moderner Softwaretechnikansätze wie Agile Softwareentwicklung 4
5 Refaktorisierung Code Smells Anlass zu Refaktorisierung ist ein Code Smell A code smell is a perceivable property of source code that is an indicator of an undesired code property. Code Smell-Beispiele in OO-Code Kopierter Quelltext (code clones) Sehr lange Methoden, sehr große Klassen, lange Parameterlisten Nutzlose Klassen Zu starke Kopplung u.v.m. 5
6 Katalog zur Refaktorisierung Refaktorisierung als Vorgehensvorschrift Je mit Name, Beschreibung, Motivation, Vorbedingungen, Algorithmus, und Beispiel Validität teils formal bewiesen, dass keine Verhaltensänderungen auftreten können oder so klein und überschaubar dass offensichtlich keine Verhaltensänderungen auftreten Üblicherweise klein und überschaubar, leicht verständlich Zum Teil mit Werkzeugen automatisiert, z. B. Eclipse nur geringer Ausschnitt der vorgeschlagenen Refactorings von Fowler (M. Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2000.) 6
7 Bekannte OO-Refaktorisierungen Rename Class, Rename Method,... Move Method, Move Field Extract Method Encapsulate Field Inline Class, Extract Class Push Down Method, Pull Up Method Replace Method with Method Object Replace Constructor with Factory Method u.v.m. 7
8 Beispiel: Extract Method Code Smell: lange Methode, Zweck von Codefragmenten darin nicht deutlich Extraktion von Statements in eigene Methode Automatisierbar in Eclipse class Foo { void printowing() { printbanner(); //print details System.out.println("name " + _name); System.out.println("amount " + getoutstanding()); class Foo { void printowing() { printbanner(); printdetails(getoutstanding()); void printdetails(double outst){ System.out.println("name " + _name); System.out.println("amount " + outst); 8
9 Domänenspezifische Refaktorisierungen Funktionale Programmiersprachen Algebraic or existential type Concrete to Abstract Data Type SQL Refactorings Benenne Tabelle/Spalte um Definiere Default-Wert Aspekt-Orientierte Programmierung Move Method from Class to Inter-Type Declaration Push down pointcut Model-getriebene Softwareentwicklung... 9
10 10 Refaktorisierung bei Softwareproduktlinien
11 Refaktorisierung bei Softwareproduktlinien Definition A product-line refactoring is a refactoring step specific to feature-oriented product-line development that may affect the feature model and the domain artifacts of a software product line Ziele sind Erstellung von Produktlinien Änderung von Produktlinien Lesbarkeit/Verbesserung der Verständlichkeit Verbesserung der Erweiterbarkeit Einfügen neuer Produkte [Apel et al. 2013] 11
12 Arten von Refaktorisierungen 1. Refaktorisierung zur Erstellung von Produktlinien Zerlegung einer bestehenden Anwendung in Features (Feature-Extraktion) Verbesserung der Struktur der Anwendung durch explizitmachen der Features (Feature Traceability Problem) Fügt ggf. Konfigurationsoptionen hinzu 2. Refaktorisierung zur Änderung von Produktlinien Verbesserung der Programmstruktur durch Umformung der Features, z. B. zusammenlegen oder aufspalten 12
13 Exkurs: Ansätze zur Einführung von SPLs Es gibt drei übliche Ansätze eine Software Produktlinie zu erstellen / einzuführen 1. Proaktives Vorgehensmodell 2. Extraktives Vorgehensmodell 3. Reaktives Vorgehensmodell Auswahl anhand betrieblicher Gesichtspunkte.Kosten.Risiko.Chancen... 13
14 Exkurs: Proaktives Vorgehensmodell SPL neu entwerfen und implementieren; wie Wasserfallmodell Komplette Domänenanalyse zu Beginn Kann die normale Entwicklung für mehrere Monate unterbrechen, bis Produktlinie auf dem Stand der bestehenden Produkte ist Hohe Kosten und hohes Risiko Gut wenn Anforderungen wohl-definiert sind 14
15 Exkurs: Proaktives Vorgehensmodell II Proactive Implementation [Krueger 2001] 15
16 Exkurs: Extraktives Vorgehensmodell Nutzt eine oder mehrere bestehende Anwendungen (legacy application) als Basis Extrahiert daraus Features und erzeugt so Varianten Geeignet für den schnellen Wechsel von traditionellen Anwendungen zu Produktlinien Relativ geringer Ressourcenaufwand und Risiko Sehr anspruchsvoll für Werkzeuge und Sprachen, da Zerlegung einer Anwendung, die nicht als SPL entworfen wurde (vgl. Unbewusstheitsprinzip in AOP) 16
17 Exkurs: Extraktives Vorgehensmodell II Extract [Krueger 2001] 17
18 Exkurs: Reaktives Vorgehensmodell Analog zu Spiralmodell oder Agiler Softwareentwicklung Implementiert zuerst wenige Variationen; fügt inkrementell weitere hinzu Geeignet, wenn benötigte Varianten nicht komplett im voraus bekannt, und für unvorhergesehene Änderungen Kleinere Projektgröße, geringere initiale Kosten; weniger Ressourcenbindung, schnellere Ergebnisse später evtl. Umstrukturierungen nötig 18
19 Iterate Exkurs: Reaktives Vorgehensmodell II React [Krueger 2001] 19
20 Refaktorisierung bei Softwareproduktlinien Refaktorisierung zur Erstellung von Produktlinien 20
21 Refaktorisierung zur Erstellung von Produktlinien Refaktorisierung in Features wird im extraktiven Modell genutzt Code aus bestehender Anwendung in Feature verschieben ohne Verhaltensänderung ( mit aktiviertem Feature muss sich die Produktlinie wie die originale Anwendung verhalten) Typische Refaktorisierungen sind Move Class/Method/Field/Statements to Feature Konkrete Umsetzung abhängig von verwendeten Implementierungsansatz (Präprozessor, FOP, AOP, Framework,...) 21
22 Herausforderung: optionale Features Extraktion eines Features Neue Variante(n) Alle Varianten müssen korrekte Programme sein (die sich natürlich anders verhalten) d. h. Extraktion eines Features muss vollständig sein (nicht nur die einzelnen Refaktorisierungen von Code- Fragmenten müssen stimmen) Code tangling & scattering Extraktion nicht unmittelbar möglich Wie kann Feature-Code vollständig erkannt werden? Wie erkennt man korrekte Refaktorisierungen von Features? Was könnten Pre- und Post-Conditions sein? 22
23 Beispiel: Feature-Refaktorisierung Einstiegsbeispiel: Graph-Beispiel mit Farben; der Code für die Farben (blau markiert) soll in ein Feature verschoben werden class Node { int id = 0; Color color = new Color(); void print() { Color.setDisplayColor(color); System.out.print(id); class Edge { Node a, b; Color color = new Color(); Edge(Node _a, Node _b) { a = _a; b = _b; void print() { Color.setDisplayColor(color); a.print(); b.print(); class Color { static void setdisplaycolor(color c) {... 23
24 Refaktorisierung mit Jak Die Klasse Color kann direkt in das Feature-Verzeichnis verschoben werden Die Felder color werden in Rollen (Klassenverfeinerungen) verschoben Die Aufrufe setdisplaycolor werden mittels Methodenverfeinerung in Rollen implementiert class Node { int id = 0; Color color = new Color(); void print() { Color.setDisplayColor(color); System.out.print(id); 24 class Node { int id = 0; void print() { System.out.print(id); refines class Node { Color color = new Color(); void print() { Color.setDisplayColor(color); Super.print();
25 Refaktorisierung mit AspectJ Die Klasse Color wird als innere statische Klasse des Aspekts verschoben Die Felder color werden in Inter-Type Deklarationen verschoben Die Aufrufe setdisplaycolor werden mittels Advice implementiert class Node { int id = 0; Color color = new Color(); void print() { Color.setDisplayColor(color); System.out.print(id); 25 class Node { int id = 0; void print() { System.out.print(id); aspect Colors { Color Node.color = new Color(); before(node n) : execution(void Node.print()) && this(n) { Color.setDisplayColor(n.color);
26 Schwierige Refaktorisierungen Anweisungen in der Mitte einer Methode Refaktorisierung von Parametern oder Exceptions class Edge { Node a, b; Color color = new Color(); Edge(Node _a, Node _b) { a = _a; b = _b; void print() { Color.setDisplayColor (Color.WEIGHTCOLOR); weight.print(); Color.setDisplayColor(n.color); a.print(); b.print(); class Graph {... Edge add(node n, Node m, Weight w) throws InvalidWeightException { Edge e = new Edge(n, m); nv.add(n); nv.add(m); ev.add(e); e.setweight(w); return e; 26
27 Anweisungen in einer Methode AspectJ aspect Colors { Color Edge.color = new Color(); before() : execution(void Edge.print()) { Color.setDisplayColor(Color.WEIGHTCOLOR); after(edge e) : call(void Weight.print()) && withincode(void Edge.print()) && this(e) { Color.setDisplayColor(e.color); Jak (mittels Hook-Methoden) class Edge { void print() { weight.print(); hook(); a.print(); b.print(); void hook() {; refines class Edge { Color color = new Color(); void print() { Color.setDisplayColor (Color.WEIGHTCOLOR); Super.print(); void hook() { Color.setDisplayColor(n.color); 27
28 Anweisungen in einer Methode II Der AspectJ-Ansatz nutzt das fein-granulare Join-Point- Modell von AspectJ Gefährlich wenn als Hack genutzt (Fragile Pointcut Problem) Nicht immer möglich (Code um Anweisungssequenz, Code vor Anweisungen, die keinen JP haben z. B. if) Hook-Methoden fügen neue Erweiterungspunkte (oder Join-Points) ein Können Code-Lesbarkeit erschweren Code Tangling 28
29 Parameter und Exceptions einfügen In fast allen Sprachen sind Signaturen fixiert, weil sie zum Adressieren verwendet werden (z. B. in einem Pointcut) Zu den Deklarationen müssen auch alle Aufrufe angepasst werden Einfügen von neuen Parametern ist nicht möglich Refaktorisierungen nur mit Hacks/Workarounds Duplizierte Methoden und Feldvariablen Parameter-Objekte Wormhole Pattern in AspectJ Ausnahme: Präprozessoren 29
30 Eine Frage der Granularität Dateien/Verzeichnisse einf. Module/Komponenten/Klassen einf. Explizite Erweiterungspunkte Methoden/Felder einfügen Methoden erweitern Statement in Methodenmitte Ausdrücke/Terme erweitern Signaturen von Methoden erweitern Token einfügen Zeichen einfügen Einfache SPL Tools Frameworks, Komp. FOP AOP Präprozessoren 30
31 Granularität bei der Refaktorisierung Ursprüngliche Anwendung nicht für Features vorbereitet Erweiterungen oft sehr fein-granular Viel mehr Erweiterungspunkte als bei proaktivem Vorgehen, wo häufig wenige geplante Punkte ausreichen Aufgrund vieler Hacks wird Quelltext schnell unlesbar 31
32 Fallstudie: Refaktorisierung von Berkeley DB mittels AspectJ Zerlegung einer Datenbank (80 KLOC) in 38 Features; Refaktorisierung mit AspectJ Art und Granularität der Erweiterungen 1124 Erweiterungen in 151 Aspekten, davon 640 statisch (Methoden, Felder, Klassen einfügen) und 484 dynamisch 214 einfache Methodenerweiterungen 285 Erweiterungen in der Mitte einer Methode Davon 121 `call && within' 164 Erweiterungen mittels Hook-Methode 32
33 Fallstudie Berkeley DB II Parametererweiterungen traten nur in wenigen Features, dort aber sehr gehäuft auf Transaktion: 64 Methoden mit Txn Parameter Locking: Locker, LockMode oder LockType in über 200 Methoden erwartet; Feature aufgrund des enormen Aufwands nicht extrahiert Exceptions wurden von einem Feature Synchronisation in sehr vielen Methoden eingefügt Stmt Ext. 22% Expr. Ext. 2% Param. Ext. 5% Class Intr. 5% Method Intr. 30% Method Ext. 18% Field Intr. 18% 33
34 Fallstudie Berkeley DB - Fazit Insgesamt hat die zu grobe Granularität die Refaktorisierung sehr aufwendig gemacht (zudem fehlte Werkzeugunterstützung) Aufgrund der vielen Workarounds sind einige Feature sehr schwer lesbar AspectJ ist keine geeignete Sprache für Feature- Refaktorisierung, aber auch andere Sprachen haben Defizite hinsichtlich der Granularität Extraktion von Features aus bestehenden Anwendungen sehr anspruchsvoll 34
35 Werkzeug: CIDE Colored Integrated Development Environment Features werden durch Hintergrundfarben repräsentiert Feingranulare Zuweisungen Disziplinierte Annotationen: nur syntaktisch sinnvolle Elemente können annotiert werden (keine einzelnen Zeichen) Automatische Refaktorisierung von markiertem Code in Feature-Module z. Z. Jak, FeatureHouse und AspectJ Nutzt Workarounds wie Hook-Methoden für schwierige Refactorings Generierter Code kaum lesbar, Wartung auf gefärbtem Code 35
36 CIDE II 36
37 Refaktorisierung bei Softwareproduktlinien Refaktorisierung zur Änderung von Produktlinien 37
38 Änderung von Produktlinien Untergliederung I 1. Variabilitätserhaltende Refaktorisierung: A variability-preserving refactoring is a product-line refactoring that does not change the set of valid products and corresponding feature selections (modulo renaming) and preserves the observable behavior of all valid products (modulo binding time changes). [Apel et al. 2013] 2. Variabilitätssteigernde Refaktorisierungen A variability-enhancing refactoring is a product-line refactoring that does not remove products from the set of valid products and preserves the observable behavior of all previously valid products. A variability-enhancing refactoring may introduce additional valid products. [Apel et al. 2013] 38
39 Änderung von Produktlinien Untergliederung II 3. Produkterhaltende Refaktorisierung: A product-preserving refactoring is a product-line refactoring that does not remove products from a given set of products and preserves the observable behavior of all those products. A product-preserving refactoring may add and remove products outside the given set. [Apel et al. 2013] 39
40 Refaktorisierung zur Änderung von Produktlinien Grund für Refaktorisierung: Evolution oder Wartung Ungeplante SPL-Erweiterungen Code-Replikation Übersichtlichkeit Verbesserung der Struktur / Lesbarkeit bei gleichem Verhalten Mögliche Refaktorisierungen sind u. a. Umbenennen von Features (rename) Zusammenfügen von Features (merge) Aufspalten von Features (split) Umsortieren von Features (reorder) Refaktorisierungen von Feature Modellen 40
41 Variability Smells I A variability smell is a perceivable property of a product line that is an indicator of an undesired code property. It may be related to all kinds of artifacts in a product line, including feature models, domain artifacts, feature selections, and derived products. Ein optionales Feature wird in jeder Konfiguration benötigt Feature kann zum Basiscode hinzugefügt werden Oder: Feature Modell anpassen 41
42 Variability Smells II Ein Feature wird immer zusammen mit einem anderen Feature ausgewählt Komplexität verringern durch Zusammenlegen (merge) Ein Feature wird in keiner Konfiguration benötigt Feature löschen Ein Feature wird häufig benötigt, nur weil es Code enthält, den ein anderes Feature braucht Feature aufspalten und den gemeinsamen Code herauslösen Ein Feature benötigt Funktionalität, die erst von einem späteren Feature zur Verfügung gestellt wird Reihenfolge ändern (reorder) 42
43 Herausforderungen Refaktorisierung SPLs Semantik wird als Summe aller Produkte angesehen Komplexität der notwendigen Anpassungen und Auswirkungen Refaktorisierung erfordert Änderungen in verschiedenen Sprachen Feature-Umbenennung: Anpassungen: Cross-Tree Constraints, Modul-Name, Konfigurationen Pull-Up Method: Accidental Overriding in anderen Refinements 43
44 Umbenennen von Features Feature-Name wird in Feature-Modell und Feature-Modul (Verzeichnisname) verwendet Außerdem ggf. noch in Konfigurationen (Equation-Dateien) Jak-Dateien (Keyword layer) AspectJ-Dateien (Package-Deklaration)... Simple Automatisierung in FeatureIDE: Bei Umbenennungen im Feature-Modell wird auch das Feature-Modul umbenannt 44
45 Zusammenfügen von Features (merge) Benachbarte Features können i.d.r. kombiniert werden, indem die Erweiterungen zusammengefügt werden. Lediglich Erweiterungen des gleichen Codefragments müssen kombiniert werden Sind Features nicht benachbart, muss zuerst die Reihenfolge entsprechend verändert werden Formalisierung: Introduktionssumme und Modifikationssumme 45
46 Zusammenfügen von Features class Foo { void print() { System.out.print('<core/>'); refines class Foo { int a; void print() { System.out.print('<inner>'); Super.print(); System.out.print('</inner>'); refines class Foo { Object b; void print() { System.out.print('<outer>'); Super.print(); System.out.print('</outer>'); class Foo { void print() { System.out.print('<core/>'); refines class Foo { int a; Object b; void print() { System.out.print('<outer>'); System.out.print('<inner>'); Super.print(); System.out.print('</inner>'); System.out.print('</outer>'); P = InnerOuter Core P = Outer Inner Core 46
47 Aufspalten von Features Aufspalten von Features ist ähnlich der Refaktorisierung zur Erstellung von Produktlinien Der zu entsprechende Code muss ausgewählt werden und in ein neues Feature verschoben werden Das eigentliche Verschieben kann automatisiert werden 47
48 Umsortieren von Features Bei vielen Features ist die Reihenfolge nicht relevant, weil sie disjunkte Codefragmente erweitern und einander nicht referenzieren Erweitern beide Features das gleiche Code Fragment (die gleiche Methode, den gleichen Join Point), muss der Feature-Quelltext geändert werden Kann im allgemeinen Fall schwierig sein, aber z. B. durch Hook-Methoden möglich 48
49 Umsortieren von Features (gemeinsamer Join- Point) class Foo { void print() { System.out.print('<core/>'); refines class Foo { void print() { System.out.print('<inner>'); Super.print(); System.out.print('</inner>'); refines class Foo { void print() { System.out.print('<outer>'); Super.print(); System.out.print('</outer>'); 49 P = Outer Inner Core class Foo { void print() { System.out.print('<core/>'); refines class Foo { void print() { System.out.print('<outer>'); hook1(); Super.print(); hook2(); System.out.print('</outer>'); void hook1() { void hook2() { refines class Foo { void hook1() { System.out.print('<inner>'); void hook2 () { System.out.print('</inner>'); P = Inner Outer Core
50 X Refaktorisierung von Feature Modellen Veränderung im Code erfordern teilweise Veränderungen im Feature Modell A Evolution A B C B C B C B C Nicht mehr benötigt 50
51 Zukünftige Herausforderungen Objekt-orientierte Refactorings nicht ohne weiteres auf SPLs anwendbar Refactorings in SPLs transformieren nicht nur ein Programm sondern viele Wie die Vorbedingungen prüfen? Was tun bei Mehrdeutigkeiten? Auch neue Refaktorisierungen denkbar: z.b. Verschiebung von Code zwischen Features Änderungen im Code erfordern Änderungen in anderen Bereichen der SPL (Konfig, Module, ) Variability Smells 51
52 Zusammenfassung Refaktorisierung ist ein übliche Methode zur nachträglichen Verbesserung der Code-Struktur Refaktorisierung zur Erstellung von Produktlinien Zerlegung einer Anwendung in Features Probleme bei fein-granularen Erweiterungen Refaktorisierung zur Änderung von Produktlinien Verbesserung der SPL-Struktur durch das Zusammenfügen, Aufspalten oder Umsortieren von Features 52
53 Literatur I S. Apel, D. Batory, C. Kästner, and G. Saake. Feature- Oriented Software Product Lines - Concepts and Implementation. Springer, Chapter 8: Refactoring of Software Product Lines M. Fowler. Refaktorisierung. Improving the Design of Existing Code. Addison-Wesley, [Standardliteratur zu Refaktorisierung im Allgemeinen] P. Clements and C. Krueger. Point/Counterpoint: Being Proactive Pays Off/Eliminating the Adoption Barrier. IEEE Software, 19(4), [Vorgehensmodelle zur SPL-Entwicklung] 53
54 Literatur II C. Kästner, S. Apel, and M. Kuhlemann. Granularity in Software Product Lines. Proc. Int'l. Conf. Software Engineering, [Granularität und Überblick CIDE] S. Apel, C. Kästner and D. Batory. Program Refactoring using Functional Aspects. In Proc. of Int'l Conf. Generative Programming and Component Engineering, [Reihenfolge von Features (Aspekten) ändern] C. Kästner and S. Apel and D. Batory. A Case Study Implementing Features using AspectJ. In Proc. of Int'l Software Product Line Conference, [Fallstudie Berkeley DB] 54
55 Literatur III V. Alves, R. Gheyi, T. Massoni, U. Kulesza, P. Borba, and C. J. P. de Lucena. Refactoring Product Lines. In Proc. Int l Conf. Generative Programming and Component Engineering, ACM, Hagen Schink, Martin Kuhlemann, Gunter Saake, and Ralf Lämmel. Hurdles in Multi-Language Refactoring of Hibernate Applications. In Proceedings of the International Conference on Software and Data Technologies (ICSOFT), SciTePress, Charles W. Krueger. Easing the Transition to Software Mass Customization. In Proceedings of the 4th International Workshop on Software Product-Family Engineering, Bilbao, Spain
56 Literatur Ambler, S. Agile Database Techniques: Effective Strategies for the Agile Software Developer. JohnWiley & Sons, Inc., New York, NY, USA, Huiqing Li, REFACTORING HASKELL PROGRAMS, Dissertation at the University of Kent, September 2006 S. Trujillo, D. Batory, and O. Diaz. Feature refactoring a multi-representation program into a product line. In Proceedings of the Conference on Generative Programming and Component Engineering (GPCE), ACM Press,
Software-Refactoring. 29. Mai 2013
Software-Refactoring 29. Mai 2013 Überblick Was ist Refactoring und wozu dient es? Welche Refactorings gibt es? Refactoring-Katalog: www.refactoring.com Wann, wo und wie führt man Refactorings durch? Wie
MehrSoftware-Refactoring. 27. Mai 2015
Software-Refactoring 27. Mai 2015 Überblick Was ist Refactoring und wozu dient es? Welche Refactorings gibt es? Refactoring-Katalog: www.refactoring.com Wann, wo und wie führt man Refactorings durch? Wie
MehrSoftwareproduktlinien - Versionsverwaltungs- und Buildsysteme
Softwareproduktlinien - Versionsverwaltungs- und Buildsysteme Christian Kästner (Carnegie Mellon University) Sven Apel (Universität Passau) Gunter Saake, Martin Kuhlemann (Universität Magdeburg) 1 Application
MehrSoftwareproduktlinien Teil 4: Versionsverwaltungs- und Buildsysteme
Softwareproduktlinien Teil 4: Versionsverwaltungs- und Buildsysteme Christian Kästner (Universität Marburg) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg) 1 Application Eng. Domain
MehrSoftwareproduktlinien Teil 9: Features vs. Aspekte
Softwareproduktlinien Teil 9: Features vs. Aspekte Sven Apel (Universität Passau) Christian Kästner (Universität Marburg) Gunter Saake (Universität Magdeburg) AOP vs. FOP AOP und FOP implizieren keine
MehrVorlesung Software-Reengineering
Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2007/08 Überblick I 1 Refactoring Refactorings
MehrErweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Teil 3: Software-Produktlinien
Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Teil 3: Software-Produktlinien Sven Apel, Christian Kästner, Gunter Saake Apel, Kästner, Saake EPMD Folie 3-2 Agenda Produktlinien und Programmfamilien
MehrSoftwareproduktlinien Teil 12: Analyse von Produktlinien
Softwareproduktlinien Teil 12: Analyse von Produktlinien Christian Kästner (Universität Marburg) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg) inkl. Folien von Das Problem Database
MehrSoftwareproduktlinien Teil 2: Entwicklungsprozess und Variabilitätsmodellierung
Softwareproduktlinien Teil 2: Entwicklungsprozess und Variabilitätsmodellierung Sven Apel (Universität Passau) Christian Kästner (Universität Marburg) Gunter Saake (Universität Magdeburg) 1 Agenda Produktlinien
MehrSoftwareproduktlinien - Features vs. Aspekte
Softwareproduktlinien - Features vs. Aspekte Sven Apel (Universität Passau) Christian Kästner (Universität Marburg) Gunter Saake (Universität Magdeburg) AOP vs. FOP AOP und FOP implizieren keine konkreten
MehrFeature-Komposition auf Bytecode-Ebene
Feature-Komposition auf Bytecode-Ebene Claus Hunsen Sergiy Kolesnikov Sven Apel FOSD-Treffen 2012 Feature-Komposition Quellcode-Komposition Feature-Module (Quellcode) ➊ Komposition Variante (Quellcode)
MehrMichael C. Feathers. Legacy Code. Effektives Arbeiten mit. Refactoring und Testen bestehender Software
Michael C. Feathers Effektives Arbeiten mit Legacy Code Refactoring und Testen bestehender Software Vorwort................................................... 13 Geleitwort.................................................
MehrSoftwareproduktlinien - Entwicklungsprozess und Variabilitätsmodellierung
Softwareproduktlinien - Entwicklungsprozess und Variabilitätsmodellierung Sven Apel (Universität Passau) Christian Kästner (Universität Marburg) Gunter Saake, Thomas Thüm (Universität Magdeburg) 1 Agenda
MehrSoftwareproduktlinien Teil 5: Präprozessoren (Variabilitätsannotationen)
Softwareproduktlinien Teil 5: Präprozessoren (Variabilitätsannotationen) Christian Kästner (Universität Marburg) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg) Wie Variabilität implementieren?
MehrSo#wareproduktlinien - Feature-Orien4erung. Sven Apel (Universität Passau) Chris4an Kästner (CMU) Gunter Saake, Thomas Thüm (Universität Magdeburg)
So#wareproduktlinien - Feature-Orien4erung Sven Apel (Universität Passau) Chris4an Kästner (CMU) Gunter Saake, Thomas Thüm (Universität Magdeburg) 1 Wie Variabilität implemen4eren? Domain Eng. Feature-Modell
MehrSoftwareproduktlinien - Analyse von Produktlinien
Softwareproduktlinien - Analyse von Produktlinien Christian Kästner (CMU) Sven Apel (Universität Passau) Gunter Saake, Thomas Thüm (Universität Magdeburg) Das Problem Variability = Complexity 33 optional,
MehrSoftware Product Lines
Software Product Lines Concepts, Analysis and Implementation Programmier-Paradigmen für Software-Produktlinien (3/3) ES Real-Time Systems Lab Prof. Dr. rer. nat. Andy Schürr Dept. of Electrical Engineering
MehrComparing Software Factories and Software Product Lines
Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich
MehrRefactoring. Vortrag im Rahmen des Softwareprojekts: Übersetzerbau. Referenten: Vivienne Severa Alpin Mete Sahin Florian Mercks. Datum:
Refactoring Vortrag im Rahmen des Softwareprojekts: Übersetzerbau Referenten: Vivienne Severa Alpin Mete Sahin Florian Mercks Datum: 20.06.2013 Überblick Einführung Refactoring im Einsatz Werkzeugunterstützung
MehrSoftwareproduktlinien - Laufzeitvariabilität
Softwareproduktlinien - Laufzeitvariabilität Christian Kästner (Universität Marburg) Sven Apel (Universität Passau) Gunter Saake, Thomas Thüm (Universität Magdeburg) 1 Wie Variabilität implementieren?
Mehr3. GI-Workshop EPK 2004 Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten Luxemburg. ARIS meets RUP
3. GI-Workshop EPK 2004 Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten Luxemburg ARIS meets RUP Der ARIS Unified Information System Development Process Martin Plümicke Berufsakademie
MehrSoftwareproduktlinien Teil 3: Laufzeit-Variabilität
Softwareproduktlinien Teil 3: Laufzeit-Variabilität Christian Kästner (Universität Marburg) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg) 1 Application Eng. Domain Eng. Wie Variabilität
MehrSoftwareproduktlinien - Analyse von Produktlinien
Softwareproduktlinien - Analyse von Produktlinien Christian Kästner (CMU) Sven Apel (Universität Passau) Gunter Saake, Thomas Thüm (Universität Magdeburg) Das Problem Variability = Complexity 33 optional,
MehrVorlesung Software-Reengineering
Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke 1 1 Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2005/06 Überblick I 1 Refactoring 1 Refactoring
MehrRefactoring. Uschi Beck
Refactoring Uschi Beck uschibeck@web.de Gliederung Was ist Refactoring Definition, Einordnung in das Seminar Motivation Testen Code-Smells Katalog von Refactorings Aufbau, Beispiele Design Patterns als
MehrBehutsame Modernisierung
Software Evolution mit Legacy Systemen Forum Forschungsförderung / ViSEK Trends im Software Engineering Software Evolution mit Legacy Systemen Behutsame Modernisierung Jan Wloka
MehrAdvanced Software Engineering WS0910 Kapitel4. Dr. Dominik Haneberg
Advanced Software Engineering WS0910 Kapitel4 Dr. Dominik Haneberg ASPEKT-ORIENTIERTE ENTWICKLUNG 08.02.2010 Advanced Software Engineering 2 Einführung Aspektorientierte Programmierung (AOP) ist ein Programmierparadigma,
MehrInstrumentation von Android Anwendungen mit ExplorViz
Instrumentation von Android Anwendungen mit ExplorViz Jan Witzany 28. September 2016 Jan Witzany Instrumentation von Android Anwendungen mit ExplorViz 28. September 2016 1 / 19 Gliederung 1. Motivation
MehrRefactoring. PG Reclipse Seminar: Refactoring Jan-Christopher Bals (1/30)
Refactoring PG Reclipse Seminar: Refactoring Jan-Christopher Bals (1/30) Gliederung des Vortrags Definition Hintergrund und Motivation Refactoring am Beispiel Refactoring-Katalog Unterstützung durch Tools
MehrSoftwareproduktlinien Teil 11: Verbesserte Präprozessoren
Softwareproduktlinien Teil 11: Verbesserte Präprozessoren Christian Kästner (Universität Marburg) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg) Agenda Wiederholung: Probleme von Präprozessoren
MehrEffektives Arbeiten mit Legacy Code
Effektives Arbeiten mit Legacy Code Refactoring und Testen bestehender Software von Michael C. Feathers 1. Auflage Effektives Arbeiten mit Legacy Code Feathers schnell und portofrei erhältlich bei beck-shop.de
MehrRefactoring Transformationen. Martin Freund Januar 2003 Seminar Refactoring in extreme Programming AG Kastens Universität Paderborn
Refactoring Transformationen Martin Freund bbl@upb.de Januar 2003 Seminar Refactoring in extreme Programming AG Kastens Universität Paderborn Gliederung 1. Transformationen-Übersicht 2. Beispiel: Methode
MehrJava Tools JDK. IDEs. Downloads. Eclipse. IntelliJ. NetBeans. Java SE 8 Java SE 8 Documentation
Java Tools JDK http://www.oracle.com/technetwork/java/javase/ Downloads IDEs Java SE 8 Java SE 8 Documentation Eclipse http://www.eclipse.org IntelliJ http://www.jetbrains.com/idea/ NetBeans https://netbeans.org/
MehrSoftwareproduktlinien Teil 12: Analyse von Produktlinien. Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg)
Softwareproduktlinien Teil 12: Analyse von Produktlinien ChristianKästner (Universität Marburg) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg) inkl. Folien von Das Problem Database
MehrEinführung in AOP. Rico Schiekel - 012816 rschiekel@web.de. Agenda. Kernproblem der Objekt Orientierung
Einführung in AOP Informatikseminar Rico Schiekel - 012816 rschiekel@web.de Fachhochschule Ravensburg Weingarten Hochschule für Technik und Sozialwesen Einführung in AOP Agenda Kernproblem der Objekt Orientierung
MehrAspektorientierte Middleware Florian Wagner
Anwendungen der Aspektorientierung (5) Übersicht Middleware? Middleware-Concerns Java 2 Enterprise Edition AO Implementierung AOP & JBoss 2 mid dle ware (mĭd'l-wâr') n. Software that serves as an intermediary
MehrErweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Teil 12 The Big Picture
Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Teil 12 The Big Picture Sven Apel (Universität Passau) Christian Kästner (Universität Magdeburg) Sven Apel, Christian Kästner Moderne Programmierparadigmen
MehrImplementieren von Klassen
Implementieren von Klassen Felder, Methoden, Konstanten Dr. Beatrice Amrhein Überblick Felder/Mitglieder (Field, Member, Member-Variable) o Modifizierer Konstanten Methoden o Modifizierer 2 Felder und
MehrRefactoring I. Nach Martin Fowler - Refactoring
Refactoring I Nach Martin Fowler - Refactoring Kapitel 6 : Methoden zusammenstellen Kapitel 9 : Bedingte Ausdrücke vereinfachen Kapitel 10: Methodenaufrufe vereinfachen - Mario Boley - Methoden zusammenstellen
MehrSoftwaretechnik. Prof. Dr. Rainer Koschke. Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen
Softwaretechnik Prof. Dr. Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Wintersemester 2010/11 Überblick I Software-Produktlinien Software-Produktlinien:
MehrFeature Modelle. und ihre Anwendung. Feature Modelle und ihre Anwendungen. Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
Feature Modelle und ihre Anwendung Feature Modelle und ihre Anwendungen 22.07.2010 1 Software-Produktlinien Zusammenfassung mehrerer verwandter Softwaresysteme zu einer Domäne (Anwendungsgebiet) Softwaresysteme
MehrAspektorientierte Programmierung mit.net
Aspektorientierte Programmierung mit.net David Hahn & Viktor Steinwand 1 1. 2. 3. 4. 5. Vorgehen beim AOP 6. 7. durch AOP 8. 9. 10. 2 1. AOP ist ein mächtiges Werkzeug für den Entwickler-Werkzeugkoffer
MehrSoftwaretechnik. Überblick I. Prof. Dr. Rainer Koschke. Sommersemester 2006
Softwaretechnik Prof. Dr. Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Sommersemester 2006 Überblick I 1 Software-Produktlinien Software-Produktlinien:
MehrOO Programmiersprache vs relationales Model. DBIS/Dr. Karsten Tolle
OO Programmiersprache vs relationales Model Vorgehen bisher Erstellen eines ER-Diagramms Übersetzen in das relationale Datenmodell Zugriff auf das relationale Datenmodell aus z.b. Java ER rel. Modell OO
MehrVorlesung Software-Reengineering
Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2011/12 Überblick I Refactoring Code-Transformationen:
MehrFachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn. Testen. Tutorial im Rahmen des Software(technik)praktikums SS 2012
Testen Tutorial im Rahmen des Software(technik)praktikums SS 2012 Grundlagen (1) Software ist ein fundamentales Element in der Softwarequalitätssicherung Software wird am häufigsten eingesetzt Viele Organisationen
MehrObjektorientierte PL/SQL-Entwicklung Ein Erfahrungsbericht aus Sicht von JAVA-Entwicklern
Thema Objektorientierte PL/SQL-Entwicklung Ein Erfahrungsbericht aus Sicht von JAVA-Entwicklern Referent: Frank Sanders Seite 1 Inhalt Der Vortrag hat einen sehr kurzen Einleitungsteil der sich mit Objektorientierung
MehrProduct Line Engineering (PLE)
Product Line Engineering (PLE) Produktlinienentwicklung Von Christoph Kuberczyk Christoph Kuberczyk, SE in der Wissenschaft 2015, Product Line Engineering 1 Gliederung 1. Was ist PLE? 2. Motivation 3.
MehrJavadoc. Programmiermethodik. Eva Zangerle Universität Innsbruck
Javadoc Programmiermethodik Eva Zangerle Universität Innsbruck Überblick Einführung Java Ein erster Überblick Objektorientierung Vererbung und Polymorphismus Ausnahmebehandlung Pakete und Javadoc Spezielle
Mehr3. Dokumentieren und Testen Advanced Programming Techniques Prof. Dr. Bernhard Humm FB Informatik, Hochschule Darmstadt
3. Dokumentieren und Testen Advanced Programming Techniques Prof. Dr. Bernhard Humm FB Informatik, Hochschule Darmstadt 1 Kontrollfragen zu Schnittstellen Was bedeutet Orthogonalität / Separation of Concerns?
MehrDynamische Datentypen. Destruktor, Copy-Konstruktor, Zuweisungsoperator, Dynamischer Datentyp, Vektoren
Dynamische Datentypen Destruktor, Copy-Konstruktor, Zuweisungsoperator, Dynamischer Datentyp, Vektoren Probleme mit Feldern (variabler Länge) man kann sie nicht direkt kopieren und zuweisen Probleme mit
MehrModel Querys zur Überprüfung von sicherheitsrelevanten Eigenschaften
Model Querys zur Überprüfung von sicherheitsrelevanten Eigenschaften Proseminarvortrag Werkzeugunterstützung für sichere Software Jens Knipper Fakultät für Informatik Technische Universität Dortmund 31.
MehrVerschlüsseln eines Bildes. Visuelle Kryptographie. Verschlüsseln eines Bildes. Verschlüsseln eines Bildes
Verschlüsseln eines Bildes Visuelle Kryptographie Anwendung von Zufallszahlen Wir wollen ein Bild an Alice und Bob schicken, so dass Alice allein keine Information über das Bild bekommt Bob allein keine
MehrMDA auf der Grundlage der OMG Konzepte
MDA auf der Grundlage der OMG Konzepte Tutorial auf der GI-Jahrestagung GI2010 Siegfried Nolte Beethovenstraße 57 22951 Bargteheide 04532 24295 0176 49954432 siegfried@siegfried-nolte.de www.siegfried-nolte.de
MehrSchlussendlich geben wir die Listen aus. Es kommt zu folgender Ausgabe:
Musterlösung Übung 7 Aufgabe 1 Sehen wir uns zu allererst das gegebene Forth Programm an: 0 3 new - list constant list1 list1 5 new - list constant list2 list1 6 new - list constant list3 list2 2 new -
MehrSoftwareproduktlinien Teil 12: Analyse von Produktlinien. Christian Kästner (CMU) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg)
Softwareproduktlinien Teil 12: Analyse von Produktlinien Christian Kästner (CMU) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg) Das Problem Variability = Complexity 33 optional, independent
MehrStrategy & Decorator Pattern
Strategy & Decorator Pattern Design Patterns Nutzen Wouldn t it be dreamy if only there were a way to build software so that when we need to change it, we could do so with the least possible impact on
MehrIterative Softwareentwicklung. Ullrich Köthe 19. April 2001
Iterative Softwareentwicklung Ullrich Köthe 19. April 2001 2 Traditionelles Entwicklungsmodell von Geräteentwicklung inspiriert: je später eine Änderung notwendig wird, desto teurer 12000 10000 8000 6000
MehrModellgetriebene Softwareentwicklung: Zusammenfassung und Ausblick. 7. Februar 2013
Modellgetriebene Softwareentwicklung: Zusammenfassung und Ausblick 7. Februar 2013 Überblick Zusammenfassung: Generell: Konzepte der Softwaretechnik im Kontext der modellgetriebenen Entwicklung Diskussion
MehrSoftwarefamilien und Produktlinien - systematische Wiederverwendung - Matthias Clauß Intershop Research & TU Dresden
Softwaretechnologie Softwarefamilien und Produktlinien - systematische Wiederverwendung - Matthias Clauß Intershop Research & TU Dresden Einleitung Was würden Sie machen, wenn Ihr Auftraggeber oder Chef
MehrProgrammiermethodik 3. Klausur Lösung
Programmiermethodik 3. Klausur Lösung 9. 1. 2014 Name Matrikelnummer Aufgabe mögliche Punkte erreichte Punkte 1 20 2 16 3 45 4 19 5 20 Gesamt 120 1 Seite 2 von 10 Aufgabe 1) Objekt-Orientierung und Vererbung
MehrKonsolidierung von Software-Varianten in Software-Produktlinien ein Forschungsprogramm
Konsolidierung von Software-Varianten in Software-Produktlinien ein Forschungsprogramm Rainer Koschke Universität Bremen Workshop Software-Reengineering Bad Honnef 5. Mai 2005 Bauhaus Forschungskooperation
MehrProzeduren vs. Funktionen
Prozeduren vs. Funktionen Mit der Formalisierung wird auch der Unterschied zwischen Prozeduren und Funktionen noch einmal klar. Der Aufruf beider Varianten bewirkt zunächst das Gleiche: die Eingabevariablen
MehrSoftwareproduktlinien Teil 7: Feature-Orientierung
Softwareproduktlinien Teil 7: Feature-Orientierung Sven Apel (Universität Passau) Christian Kästner (Universität Marburg) Gunter Saake (Universität Magdeburg) 1 Application Eng. Domain Eng. Wie Variabilität
Mehr11. Komponenten Grundlagen der Programmierung 1 (Java)
11. Komponenten Grundlagen der Programmierung 1 (Java) Fachhochschule Darmstadt Haardtring 100 D-64295 Darmstadt Prof. Dr. Bernhard Humm FH Darmstadt, 10. Januar 2006 Einordnung im Kontext der Vorlesung
MehrSeminar: CASE-Tools WS 06/ Refactoring. Thomas Löffler
Seminar: CASE-Tools WS 06/07 31.01.2007 Refactoring Thomas Löffler Überblick 1. Einführung: Refactoring Was ist das? Warum Refactoring? Ziele 2. Vorgehen Wo wird refactorisiert? Beispiele 3. Refactoringtools
MehrTestgetriebene Entwicklung mit JUnit4
Testgetriebene Entwicklung mit JUnit4 Seminarvortrag im Fach Fortgeschrittenes Programmieren in Java, Dozent: Prof. Klinker Datum: 30.04.2010 Referent: Marius Schmeding Ausgangsfragen... Wie testet man
Mehr8. Generics Grundlagen der Programmierung 1 (Java)
8. Generics Grundlagen der Programmierung 1 (Java) Fachhochschule Darmstadt Haardtring 100 D-64295 Darmstadt Prof. Dr. Bernhard Humm FH Darmstadt, 6. Dezember 2005 Einordnung im Kontext der Vorlesung 1.
MehrAspekt Orientierte Programmierung
Kapitel 13 Aspekt Orientierte Programmierung 13.1 Aspekte in Apache Wir betrachten den Quellcode des Apache-Servers: Der Code zum XML-Parsen steckt in einer eigenen Klasse (rot) Quelle: aspectj.org 0 ausgearbeitet
MehrOOP. Tagesprogramm. Aspektorientierte Programmierung. Annotationen
1 2014-12-03 Tagesprogramm Aspektorientierte Programmierung Annotationen 2 Aspektorientierte Programmierung Programmierparadigma AspectJ separation of concerns Modularisierung Aspekte kapseln Verhalten
MehrWas sind embedded DBMS? Eingebettete DBMS. Motivation für Embedded Databases. Besonderheiten Smartcards. in Programme eingebettet z.b.
Eingebettete DBMS Was sind embedded DBMS? in Programme eingebettet z.b. (embedded database management systems) Aktuelle Praxis und Herausforderungen Berkeley DB DB4O embedded systems z.b. Smartcard Christian
MehrUmstieg auf OSGi - aber wie? Martin Lippert & Matthias Lübken akquinet it-agile
Umstieg auf OSGi - aber wie? Martin Lippert & Matthias Lübken akquinet it-agile OSGi The dynamic module system for Java Bundles Exports Imports Dependencies Services Declarative Services Versionen Dynamic
MehrSoftwareproduktlinien The Big Picture. Sven Apel (Universität Passau) Christian Kästner (CMU) Gunter Saake, Thomas Thüm (Universität Magdeburg)
Softwareproduktlinien The Big Picture Sven Apel (Universität Passau) Christian Kästner (CMU) Gunter Saake, Thomas Thüm (Universität Magdeburg) Was haben wir gelernt? Grundlagen Software-Produktlinien Klassische
MehrAspektorientierte Programmierung
Aspektorientierte Programmierung Programmierparadigma AspectJ separation of concerns Modularisierung Aspekte kapseln Verhalten das mehrere Klassen betrifft Objektorientierte Programmiertechniken: Aspektorientiertheit,
MehrRefactoring. Programmiermethodik. Eva Zangerle Universität Innsbruck
Refactoring Programmiermethodik Eva Zangerle Universität Innsbruck Einführung Java Ein erster Überblick Objektorientierung Vererbung und Polymorphismus Ausnahmebehandlung Pakete und Javadoc Spezielle Themen
MehrCloud Architektur Workshop
Cloud Architektur Workshop Ein Angebot von IBM Software Services for Cloud & Smarter Infrastructure Agenda 1. Überblick Cloud Architektur Workshop 2. In 12 Schritten bis zur Cloud 3. Workshop Vorgehensmodell
MehrKapitel 3 Software Quality III
Kapitel 3 Software Quality III Software Architecture, Quality, and Testing FS 2015 Prof. Dr. Jana Köhler jana.koehler@hslu.ch Agenda Heute Von Bad Smells zu Refactorings Wie wird Refactoring durchgeführt?
MehrWas ist Wartung und welche vier Arten der Wartung unterscheidet die Norm ISO/IEC 12207? Wie lautet die Regel von Boehm? (ein Beispiel ausrechnen)
1.99 Fragen zu: Software-Wartung Was ist Wartung und welche vier Arten der Wartung unterscheidet die Norm ISO/IEC 12207? Welche Qualitätseigenschaften erhöhen (Ihrer Auffassung nach) die Wartbarkeit und
MehrCustomer-specific software for autonomous driving and driver assistance (ADAS)
This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs
MehrSoftwareproduktlinien Teil 13: The Big Picture/Ausblick
Softwareproduktlinien Teil 13: The Big Picture/Ausblick Sven Apel (Universität Passau) Christian Kästner (Universität Marburg) Gunter Saake (Universität Magdeburg) Was haben wir gelernt? Grundlagen Software-Produktlinien
MehrSoftwareschnittstellen
P4.1. Gliederung Rechnerpraktikum zu Kapitel 4 Softwareschnittstellen Einleitung, Component Object Model (COM) Zugriff auf Microsoft Excel Zugriff auf MATLAB Zugriff auf CATIA Folie 1 P4.2. Einleitung
MehrC++ Templates - eine kleine Einführung. Funktionstemplates. Fabian Scheler, Peter Ulbrich, Niko Böhm. 20. Oktober 2008
Überblick 1 Allgemein C++ Templates - eine kleine Einführung Fabian Scheler, Peter Ulbrich, Niko Böhm Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte Systeme und Betriebssysteme)
MehrEin Design Tool für objektorientierte portable Programmierschnittstellen
Diplomarbeit Ein Design Tool für objektorientierte portable Programmierschnittstellen Vortragender: Elias Volanakis Inhalt 1. Entwurfsmuster 2. Wrapper Facade (WF) Aufgaben & Struktur Implementierung Nutzen
MehrUnified. Copyright Adriano Gesué UML 2.0 UML 1.4 UML 1.3 UML 1.2 UML 1.1 UML 1.0 UML 0.9. Method 0.8
Literatur Martin Fowler and Kendall Scott: UML Distilled: Applying the Standard Object Modeling Language. Addison-Wesley 1997. James Rumbaugh, Ivar Jacobson, and Grady Booch: The Unified Language Reference
MehrEPMD Teil 6 Feature-Orientierung
EPMD Teil 6 Feature-Orientierung Christian Kästner (Universität Magdeburg) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg) Kästner, Apel, Saake EPMD Folie 6-2 Grundidee Agenda Implementierung
MehrWarum Programme Verträge schließen sollten
1 Warum Programme Verträge schließen sollten RALF HINZE Institut für Informatik, Lehrstuhl Softwaretechnik, Universität Freiburg Georges-Köhler-Allee, Gebäude 079, 79110 Freiburg i. Br. Email: ralf@informatik.uni-bonn.de
MehrCOPE COuPled Evolution of metamodels and models
COPE COuPled Evolution of metamodels and models Diplomarbeit in Zusammenarbeit mit der BMW Car IT (Betreuer: Elmar Jürgens, Sebastian Benz) Markus Herrmannsdörfer 7. November 2007 Perlen der Informatik
MehrRefactoring von Legacy Systemen. Jochen Winzen jochen.winzen@andrena.de andrena objects ag
Refactoring von Legacy Systemen Jochen Winzen jochen.winzen@andrena.de andrena objects ag Was ist ein Legacy System Ein Legacy System hat folgenden Eigenschaften: + Besitzt die geforderte Funktionalität
MehrSoftwareproduktlinien Teil 8: Aspektorientierung
Softwareproduktlinien Teil 8: Aspektorientierung Sven Apel (Universität Passau) Christian Kästner (Universität Marburg) Gunter Saake (Universität Magdeburg) Agenda Aspektorientierte Programmierung: Ideen
MehrSeminar: Software Engineering verteilter Systeme
Seminar: Software Engineering verteilter Systeme Hauptseminar im Sommersemester 2011 Programmierung verteilter Systeme Institut für Informatik Universität Augsburg 86135 Augsburg Tel.: +49 821 598-2118
MehrObjekt-orientierte Programmierung
Objekt-orientierte Programmierung Eine (sehr) kurze Einführung Daniel Lübke Gliederung Motivation Grundlagen (Objekte, Klassen, Vererbung) Interfaces Klassenvariablen
MehrInfo B VL 11: Innere Klassen/Collections
Info B VL 11: Innere Klassen/Collections Objektorientiere Programmierung in Java 2003 Ute Schmid (Vorlesung) Elmar Ludwig (Übung) FB Mathematik/Informatik, Universität Osnabrück Info B VL 11: Innere Klassen/Collections
MehrSoftwareproduktlinien - Entwicklungsprozess und Variabilitätsmodellierung
Softwareproduktlinien - Entwicklungsprozess und Variabilitätsmodellierung Sven Apel (Universität Passau) Christian Kästner (Universität Marburg) Gunter Saake (Universität Magdeburg) Thomas Thüm (TU Braunschweig)
MehrInterface. So werden Interfaces gemacht
Design Ein Interface (=Schnittstelle / Definition) beschreibt, welche Funktionalität eine Implementation nach Aussen anzubieten hat. Die dahinter liegende Algorithmik wird aber der Implementation überlassen.
MehrComplex Event Processing
[10] Armin Steudte HAW Hamburg Masterstudiengang Informatik - WS 2011/2012 Agenda Motivation Grundlagen Event Processing Networks Ausblick Quellen 2 Agenda Motivation Grundlagen Event Processing Networks
MehrContainer für eine Folge gleichartiger Daten. Dynamische Datentypen. Probleme mit Feldern...aber nicht mit std::vector. ... und auch std::vector
// Container für eine Folge gleichartiger Daten Dynamische Datentyen Listen; Funktionalität, Coy- Konstruktor, Zuweisungsoerator,, Konzet Dynamischer Datenty n Bisher: Felder (T[],std::array, std::vector)
MehrRelease Automation für Siebel
June 30 th 2015 Release Automation für Siebel Stefan Kures Agenda + Herausforderungen + Lösung mit Automic + Vorteile + Resultate 3 Property of Automic Software. All rights reserved Siebel als zentrale
MehrState-of-the-Art in Software Product Line Testing and Lessons learned
State-of-the-Art in Software Product Line Testing and Lessons learned Sebastian Oster Sebastian Oster oster@es.tu-darmstadt.de Tel.+49 6151 16 3776 ES Real-Time Systems Lab Prof. Dr. rer. nat. Andy Schürr
MehrVisuelle Kryptographie. Anwendung von Zufallszahlen
Visuelle Kryptographie Anwendung von Zufallszahlen Verschlüsseln eines Bildes Wir wollen ein Bild an Alice und Bob schicken, so dass Verschlüsseln eines Bildes Wir wollen ein Bild an Alice und Bob schicken,
MehrProgrammierkurs C/C++
Blockkurs: "Einführung in C/C++" Programmierkurs C/C++ Donnerstag Sandro Andreotti andreott@inf.fu-berlin.de WS 2008/09 1 Structs Blockkurs: "Einführung in C/C++" 2 Structs sind Bündel von Variablen (unter
Mehr