- Antipatterns - der Softwareentwicklung. Tanja Brockmeier

Größe: px

Ab Seite anzeigen:

Download "- Antipatterns - der Softwareentwicklung. Tanja Brockmeier"

Kathrin Klein
vor 8 Jahren
Abrufe

1 - Antipatterns - der Softwareentwicklung Tanja Brockmeier

2 Antipatterns Definition Antipatterns: sind eine häufige wiederkehrende Lösungen, die fehlerhaft sind und Merkmale mit sich bringen, die unerwünscht sind nicht auszugleichen durch das Positive was die Lösung mit sich bringt Antipatterns sind Negativ-Beispiele Sie beschreiben wie man etwas nicht machen sollte 2/35

sind nicht auszugleichen durch das Positive was die Lösung mit sich bringt

3 Antipatterns in unterschiedlichen Bereichen Allgemein: Antipattern existieren in so gut wie jedem Bereich Beispiel: soziale Antipatterns (Kriminalität, Terrorismus, etc.) Von Interesse für Softwareprojekte Antipatterns der Softwareentwicklung Antipatterns der Softwarearchitektur und Management Antipatterns 3/35

4 Antipatterns vs. Code Smells Bestimmte Antipatterns (der Programmierung) nennt man auch: Code Smells : Ein Symptom das etwas schief läuft Der Code sollte Verbesserungsmaßnahmen (Refactorings) unterzogen werden und/oder das Gesamtdesign sollte erneut überprüft werden z.b.:duplicated code, Long Parameter List, Lage Class, etc. 4/35

Smells : Ein Symptom das etwas schief läuft Der Code sollte Verbesserungsmaßnahmen

5 Antipatterns der Softwareentwicklung Antipattern-Lösungen sind schlechte Ergebnisse Bsp.: geringe Performance nur schwer zu wartender Code scheitern des ganzen Projekts etc. Ziele der Antipatterns: Erfolgreiche Softwareprojekte Softwareprojekte, die mit zu vielen negativen Konsequenzen umgesetzt wurden erfolgreich verbessern Entwurfsfehler erkennen und vermeiden 5/35

Ziele der Antipatterns: Erfolgreiche Softwareprojekte Softwareprojekte, die mit zu vielen

6 Antipattern-Lösungen 5 von 6 Softwareprojekten scheitern Antipatterns beschreiben Lösungen mit negativen Folgen gefolgt von notwendigen Änderungen Kontext Vorteile Antipatterns Antipattern-Lösung Ursachen Symptome & Konsequenzen Nach dem Refactoring / Modifizierte Lösung Konsequenzen Verwandte Patterns & Antipatterns 6/35

Kontext Vorteile Antipatterns Antipattern-Lösung Ursachen Symptome &

7 Das Antipatterns - Referenzmodell Das Referenzmodell nach Brown, Malveau, McCormick III, Mowbray 1. Hauptursachen 2. Grundlegende Einflüsse (Urkräfte) 3. Software Design-Level-Modell Software- Projekt 7/35

8 Referenzmodell: 1. Hauptursachen Unangebrachte Hast Desinteresse Engstirnigkeit Faulheit Geiz Ignoranz Stolz Software- Software- Projekt Projekt 8/35

9 Referenzmodell: 1. Hauptursachen Unangebrachte Hast knappe Zeitplanung Desinteresse Engstirnigkeit Faulheit Geiz Ignoranz Stolz Software- Software- Projekt Projekt 9/35

10 Referenzmodell: 1. Hauptursachen Unangebrachte Hast Desinteresse Nicht nach für hilfreichen Lösungs-Konzepte suchen Engstirnigkeit Faulheit Geiz Ignoranz Stolz Software- Software- Projekt Projekt 10/35

11 Referenzmodell: 1. Hauptursachen Unangebrachte Hast Desinteresse Engstirnigkeit Trotz Erfolgen andere Lösung ablehnen Software- Software- Projekt Projekt Faulheit Geiz Ignoranz Stolz 11/35

12 Referenzmodell: 1. Hauptursachen Unangebrachte Hast Desinteresse Engstirnigkeit Faulheit Software- Software- Automatische Generierungen nutzen Projekt Projekt Geiz Ignoranz Stolz 12/35

13 Referenzmodell: 1. Hauptursachen Unangebrachte Hast Desinteresse Engstirnigkeit Faulheit Geiz Tests streichen Ignoranz Stolz Software- Software- Projekt Projekt 13/35

14 Referenzmodell: 1. Hauptursachen Unangebrachte Hast Desinteresse Engstirnigkeit Faulheit Geiz Ignoranz Software- Software- Projekt Projekt Mangelndes Streben nach Erkenntnis Stolz 14/35

15 Referenzmodell: 1. Hauptursachen Unangebrachte Hast Desinteresse Engstirnigkeit Faulheit Geiz Ignoranz Stolz Neues statt Bewährtem Software- Software- Projekt Projekt 15/35

16 Referenzmodell: 2. Grundlegende Einflüsse (Urkräfte) Funktionsmanagement Performancemanagement Komplexitätsmanagement Changemanagement Management der IT Management des Technologietransfers 16/35

17 Referenzmodell: 3. Software Design-Level-Modell Zerlegung der Architektur in Ebenen (Unternehmen, System, Anwendung, etc.) Antipatterns der Softwareentwicklung Anwendungsebene Untersuchung der Auswirkungen der grundlegenden Einflüsse (Urkräfte) auf die einzelnen Ebenen 17/35

18 Referenzmodell und Antipatterns Die im Referenzmodell beschriebenen Einflüsse finden sich in den Beschreibungen der einzelnen Antipatterns wieder Antipatterns der Softwareentwicklung beschreiben Situationen auf die Entwickler bei der Umsetzung von Lösungen stoßen Beispiele 18/35

Antipatterns wieder Antipatterns der Softwareentwicklung beschreiben

19 Antipatternbeispiel: Poltergeist Poltergeister lösen plötzlich etwas aus Klasse(n) die kurz auftauchen um in einer anderen Klasse etwas auszulösen Hauptursachen: Ignoranz Nicht ausbalancierte Einflüsse: Funktionsmanagement, Komplexitätsmanagement 19/35

Klasse etwas auszulösen Hauptursachen: Ignoranz Nicht

20 Symptome und Konsequenzen Redundante Navigationspfade Temporäre Objekte und Klassen mit kurzer Lebensdauer Klassen mit einer Operation temporäre Verbindung zu anderer Klasse Klassennamen wie Start_process_A oder _controller 20/35

Klassen mit einer Operation temporäre Verbindung zu

21 Ein Poltergeist in der Pfirsichdosenfabrik Prozess_Timer Pfirsich_ Pfirsiche Wäscher Schäler Dosenfüllungs_ Kessel Dosenfüller Controller Kalender 21/35

22 Typische Ursachen Die Designer haben Schwierigkeiten mit der Objektorientierten Architektur Flasche Herangehensweise gewählt Architektonische Vorgaben durchs Management 22/35

23 Der Weg zur Refactoring-Lösung Poltergeister aus der Klassenhierarchie entfernen Funktionalität ersetzen Den Klassen, die durch steuernde Aktionen aus einer Poltergeistklasse aufgerufen wurden Aktionen hinzufügen 23/35

24 Nach dem Refactoring Unverarbeitete PfirsicheBehälter Pfirsich_ Dosenfüllungs_ System Pfirsichdosenbehälter Maschinen Kalender Wäscher Schäler Kessel Dosenfüller 24/35

25 Antipatternbeispiel: Functional Decomposition In einer prozeduralen Programmierumgebung gut Direkt in eine Klassenhierarchie übertragen Problem Hauptursachen: Geiz, Faulheit Nicht ausbalancierte Einflüsse: Changemanagement, Komplexitätsmanagement 25/35

26 Symptome und Konsequenzen Klassen mit Funktionsnamen z.b. Dispaly_Table Alle Klassenattribute sind privat und werden nur in der Klasse verwendet Objektorientierter Ansatz fehlt, keine Vererbungen Keine Hoffnung auf Wiederverwendung 26/35

27 Functional Decomposition in einem Kundenkreditsystem Finanziellen Status ändern Kunden hinzufügen Kreditberechnung Tilgungsplan berechnen Adresse aktualisieren Zinsberechnung Tilgungsplan ändern 27/35

28 Typische Ursachen Die Architektur wird nur mangelhaft realisiert Spezifikation und Anforderungen festgelegt ohne Erfahrung mit Objektorientierten Systemen 28/35

29 Der Weg zur Refactoring-Lösung Analysemodell (original Anforderungen) Designmodell (Ist-Zustand) Richtlinien zur Behebung: 1. Ein-Methoden - Klassen zu Basisklassen zusammenführen 2. Mehrere Klassen zu einer neuen Klasse vereinigen Bsp.: Gerätezugriff (Steuerung, Information vom/fürs Gerät Controller-Klasse) 3. Klasse ohne Statusinformationen als Funktion 29/35

30 Objektorientiertes Modell eines Kundenkreditsystems Kunde Finanziellen Status ändern Kunden hinzufügen Adresse aktualisieren Kundenkredit Kredit Kreditberechnung Zinsberechnung Kundenzahlungen Zahlungsarten Tilgung Tilgungsplan berechen Tilgungsplan ändern 30/35

31 Antipatternbeispiele als - Kurzvorstellungen - The Blob Ein Objekt mit zahlreichen Verantwortlichkeiten, übrige Objekte enthalten nur Daten Lava Flow Nicht benutzte Codeelement befinden sich in einem geänderten Design Continuous Obsolence Technologien verändern sich so schnell, dass es schwierig wird Schritt zu halten 31/35

32 Antipatternbeispiele als - Kurzvorstellungen - Der goldene Hammer Bekanntes Konzept wird ohne weitere Überlegungen auf viele Probleme angewandet Dead End Eingriff in fremde Software führt zu Problemen bei der Pflege Input Cludge Selbstprogrammierte Eingabealgorithmen enthalten Fehler 32/35

33 Zusammenfassung Verhindern das Softwareprojekte wieder und wieder an den gleichen Fehlern scheitern, ist unverzichtbar Antipatterns sind ein Weg zu besserer, fehlerfreierer, leistungsfähigerer Software 1. Antipatterns ermöglichen schlechte Softwareprojekte zu verbessern 2. Sie zu kennen, ist die Basis um diese Entwurfsfehler zu vermeiden sie können Entwicklern, Architekten und Managern, ihre Arbeit erleichtern 33/35

34 ... Danke für eure Aufmerksamkeit Habt ihr noch Fragen? 34/35

35 Quellen Brown, Malveau, McCormick, Mowbray: AntiPatterns Entwurfsfehler erkennen und vermeiden, mitp 2007 Brown, Malveau, McCormick, Mowbray: AntiPatterns Refactoring Software, Architectures and Projects in Crisis, Wiley Computer Publishing did= ion#definitionen_.28antipatterns.29 35/35

Ähnliche Dokumente

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java Objektorientierte Programmierung mit Java Eine praxisnahe Einführung mit BlueJ Klassenentwurf Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? 1.0 Zentrale Konzepte