AntiPatterns
Einleitung
Übersicht
Einleitung
AntiPatterns:








Poltergeist
Swiss Army Knife
Stovepipe Enterprise
Golden Hammer
Reinvent the Wheel
The Blop
Email is Dangerous
Spaghetti Code
Überblick
Identifizieren und kategorisieren der üblichen Fehler in der
Softwareentwicklung.
Wie kommt man von einem Problem zu einer schlechten
Lösung?
Sieht nach einer gute Idee aus, scheitert aber bei der
Anwendung.
Fokus auf häufig auftretende Softwareentwicklungs-Fehler.
Root Causes
Grundübel in der Softwareentwicklung, führen zu BudgetÜberschreitung, Zeitverschiebung und scheiternden
Projekten!







Haste -> Eile
Apathy -> Teilnahmslosigkeit
Narrow-mindedness -> Engstirnigkeit
Sloth -> Faulheit
Avarice -> Gier
Ignorance -> Ignoranz
Pride -> Hochmut/Stolz
Primal Forces
Anforderungen auf die bei der Entscheidungsfindung das
Hauptaugenmerk gerichtet wird





Management of
Management of
Management of
Management of
Management of
functionality
performance
change
IT resources
technology transfer
Einteilung I
Aus der Sicht des Entwicklers:
Beschreiben Fehler die durch den Programmierer beim Lösen
von Problemen verursacht werden.
Aus der Sicht des Software Architekten:
Richten ihren Focus auf Probleme in der System Struktur,
ihren Konsequenzen und die passenden Lösungen.
Aus der Sicht des Software Managers:
Beschreiben Fehler und Lösungen während der Organisation von
Software.
Einteilung II
Development
AntiPatterns
The Blob
Continuous Obsolescence
Lava Flow
Ambiguous Viewpoint
Functional Decomposition
Poltergeist
Boat Anchor
Golden Hammer
Dead End
Spaghetti Code
Input Kludge
Walking through a Minefield
Cut-and-Paste Programming
Mushroom Managment
Architecture
AntiPatterns
Autogenerated Stovepipe
Stovepipe Enterprise
Jumble
Stovepipe System
Cover Your Assets
Vendor Lock-In
Wolf Ticket
Architecture By Implication
Warm Bodies
Design By Committee
Swiss Army Knife
Reinvent The Wheel
The Grand Old Duke of York
Project
Management
AntiPatterns
Blowhard Jamboree
Analysis Paralysis
Viewgraph Engineering
Death By Planning
Fear Of Success
Corncob
Intellectual Violence
Irrational Management
Smoke And Mirrors
Project Mismanagement
Throw It Over The Wall
Fire Drill
The Feud
E-mail is Dangerous
Template
Übersicht




Name
Auch bekannt als
Auftreten
Zitat/Anekdote
Beschreibung


Charakteristik
Konsequenzen
Ursachen und Ausnahmen
Lösung
Beispiel
Poltergeist
Poltergeist
Also Known As: Gypsy, Proliferation of
Classes, Big Dolt Controller Class
„I`m not exactly sure what this class
does, but it sure is important!“
„Gypsy Wagon“ that is there one day
and gone the next.
Software Design Patterns: Anti-Pattern
Helga Mesmer
Ein Poltergeist
PROCESS_TIMER
CANNER
PEACHES
PEACH_CANNER_
CONTROLLER
WASHER
CHOPPER
PEELER
CALENDAR
Software Design Patterns: Anti-Pattern
Helga Mesmer
Poltergeist: Symptome
PROCESS_TIMER
CANNER
PEACHES
PEACH_CANNER_
CONTROLLER
WASHER
CHOPPER
PEELER
Kein Status
Kurze Lebensdauer
CALENDAR
Wenig Verantwortung
Single-operation classes: Aufruf von Methoden oder
anderen Klassen
Controller-Klassen
Suffix: _manager, _controller
Software Design Patterns: Anti-Pattern
Helga Mesmer
Poltergeist: Symptome
Redundante Navigation zwischen den einzelnen
Klassen
Transiente Assoziationen
Unnötige Abstraktion dadurch nur schwer
verständlich
PROCESS_TIMER
CANNER
PEACHES
PEACH_CANNER_
CONTROLLER
WASHER
CHOPPER
PEELER
CALENDAR
Problem: No Exceptions
Software Design Patterns: Anti-Pattern
Helga Mesmer
Poltergeist: Folgerung
Unnötig
Verbraucht zusätzliche Resourcen
Ineffizient
Software Design Patterns: Anti-Pattern
Helga Mesmer
Poltergeist: Ghostbusting
Poltergeist-Klassen aus der Hierarchie entfernen
Fehlende Funktionalität ersetzen indem man die
Architektur korrigiert: die Kontrollfunktionen des
Poltergeists den Klassen übertragen, die sie dann
tatsächlich ausführen.
Software Design Patterns: Anti-Pattern
Helga Mesmer
Poltergeist: Lösungs-Beispiel
RAW_PEACHES_BIN
CALENDAR
CANNED_PEACHES_BIN
PEACH_CANNER_SYSTEM
SortRawPeaches()
ScheduleJob()
AssignTasks()
AlocateRessources()
...
MACHINE
WASHER
Software Design Patterns: Anti-Pattern
PEELER
CHOPPER
CANNER
Helga Mesmer
Poltergeist: Vorsicht!
Die 80%-Lösung des Blob ergibt oft einen Poltergeist:
Coordinator-Class
Fragen?
Software Design Patterns: Anti-Pattern
Helga Mesmer
Swiss Army Knife
(Mini) Anti-Pattern
Übersicht
Software Architektur Mini Anti-Pattern
Auch bekannt als:

Kitchen Sink
Häufigstes Auftreten:

Objekt
SwissArmyKnife
Beschreibung
Charakteristiken und
Konsequenzen:






Überladene Klassen /
Interfaces
Implementation vieler
Interfaces
Schwer zu verstehendes
Design
Genauer Einsatzzweck /
Einsatzweise unklar
Eigentlicher Einsatzzweck oft
unzureichend
Debugging, Dokumentation
und Wartbarkeit wird
erschwert
+oeffneDose() : void
+saegeBaum() : void
+oeffneFlasche() : void
+zieheKorken() : void
+schneideBrot() : void
+dreheSchraube() : void
+schneidePapier() : void
+streicheBrot() : void
+zerlegeFisch() : void
+scheideNaegel() : void
+entferneEssensreste() : void
+entschuppeFisch() : void
+schneideFleisch() : void
+entferneSpreisel() : void
+erstecheAngreifer() : void
+findeWeg() : void
+leseUhrzeit() : void
+schnitzeStock() : void
+naeheStoff() : void
+saegeAst() : void
+schneideStoff() : void
Ursachen und Ausnahmen
Ursachen:
 Designern will alle erdenkbaren Einsatzmöglichkeiten einer
Klasse abdecken ( Eierlegende-Wollmilch-Sau)
 Komplexe Interfaces und Standards wollen eingesetzt
werden
 Mangelnde Abstraktion oder Zweck für Klasse
Ausnahmen:
 Prototypen
Lösung für den Einsatz von
Technologien
Bilden von Profilen:
 Def: Profile = Dokumentierte Konventionen zum Einsatz
einer Technologie
 Teilmenge der Signaturen der ursprünglichen Interfaces
 Konventionen für zulässige Parameter Werte
 Zwei unabhängige Entwickler können die selbe Technologie
verwenden, und dabei eine Interoperabilität ihrer Software
untereinander erreichen
Fazit
Ein Swiss-Army-Knife bringt im Software
Design keinerlei Vorteile, nur Nachteile!
 Vermeiden!
Stovepipe Enterprise
Übersicht
Name

Stovepipe Enterprise
Auch bekannt als:

Inseln der Automation
Auftreten

Architekturpattern
Anekdote
“Kann ich meine eigene Insel (der Automation) haben?“
“Wir sind einzigartig!“
Allgemeine Form
Charakteristik
vielfache Systeme innerhalb eines Unternehmens
werden auf jeder Ebene unabhängig von anderen
bestimmt
- “Inseln der Automation“, isoliert von dem Rest des
Unternehmens
Konsequenzen
inkompatible Technologie
wenig Interoperabilität
– auch bei gleichen Standards
keine (wenig) Dokumentation
geringe Erweiterbarkeit & Widerverwendbarkeit
hohe Kosten
Ursachen

fehlende
– technologische Unternehmensstrategie
– Kooperation zw. Entwicklern
– Kooperation zw. Projekten
– Kompetenz
– horizontale Schnittstellen bei Systemintegration
Ausnahmen
Übernahme oder Fusion des Unternehmens
Gemeinsame Dienste (im Bankwesen:DB2 und
Orakle)
Lösung
Lösung
Definition & Vereinheitlichung von:
1. Standards
2. Betriebsumgebungen (Produkte)
3. System-Profilen (Verwendung der Produkte)
Beispiel
Beispiel
Golden Hammer
Übersicht
Name
Golden Hammer
Auch bekannt als
Old Yellar oder Head in Sand
Auftreten
System / Anwendungsebene
Anekdote
„Wenn das einzige Werkzeug, dass Du kennst ein Hammer
ist, wird alles andere zum Nagel“
Beschreibung
Charakteristik
Ein Team hat besonders viele Erfahrungen mit einem Werkzeug
in einer Lösungsweise oder einem Produkt.
Jedes neue Produkt muss sich mit den Vorzügen eines
Produktes messen. Die Nachteile werden dabei meist außer acht
gelassen.
Jedes Problem wird so angeschaut, als ob es mit diesem
Werkzeug gelöst werden müsste.
 Falsche Anwendung des bevorzugten Werkzeuges.
 Die Befürworter schlagen ein bestimmtes Produkt immer als
Lösung für Probleme vor auch wenn es bessere Produkte für
diesen Zweck gibt.
 Vorausgegangene Ausgaben (z.B. bei einer DB) dienen als
Rechtfertigung für den Einsatz des Werkzeuges.
Beschreibung
Konsequenzen
Für verschiedenste Konzepte wird immer das selbe Werkzeug
verwendet.
Produkte haben geringere Performance, und geringere
Skalierbarkeit gegenüber vergleichbaren Produkten der
Konkurrenz
Die Systemarchitektur ist am besten über das verwendete
Produkt zu beschreiben.
Die Entwickler wollen die Spezifikationen stets so umstellen, das
sie sich einfach mit diesen Werkzeugen verwirklichen lassen.
Die Entwickler wollen aus der Spezifikation alles streichen, wo
das Werkzeug nicht geeignet ist.
Neue Entwicklungen bauen sehr stark auf einem bestimmten
Produkt oder einen bestimmten Hersteller auf.
Beispiel
C(++) ist die einzig wahre Sprache zu was soll Java gut sein
Man kann nur mit Microsoft Office richtig arbeiten.
XML-DB Integration von Microsoft. Was nicht relational ist ist
nicht erlaubt.
Lösung
Ständige Erforschung alternativer Lösungsansätze und
Veranschaulichung der Vor- und Nachteile.
Softwaresysteme müssen mit wohl definierten Grenzen
versehen werden, damit einzelne Teile eigenständig
herausgelöst werden können.
Softwareentwickler müssen immer auf dem neuesten Stand der
Entwicklung sein, sowohl auf Organisationsebene als auch im
Bereich der Software Technologie als ganzes.
Anheuern von Leuten aus fremden Firmen oder anderen
Fachgebieten.
Das Management muss in „Professionelles Softwareentwickeln“
investieren und Mitarbeiter belohnen, die Prozesse verbessern.
Reinvent The Wheel
Anti-Pattern
Übersicht
Software Architektur Anti-Pattern
Auch bekannt als:
 Design in a Vacuum
 Greenfield System
Auftreten:
 System
Zitat:
„Unser Problem ist einzigartig“
Hintergrund
Reinvent  Reuse
Software Reuse <--> Design Reuse:


Software Reuse:
 Erstellung, Verwendung und Integration einer Bibliothek
von wiederverwendbaren Komponenten
 Ergebnis: mäßige Wiederverwendbarkeit,
Entwicklungsaufwand für Integration nötig
Design Reuse:
 Wiederverwendung einer Architektur und Software
Interfaces
 Erfordert Identifikation von horizontaler Komponenten
 Ergebnis: gute Wiederverwendbarkeit, kein
Entwicklungsaufwand für Integration nötig
Beschreibung
Charakteristiken und Konsequenzen:
 „Closed System“ Architektur
 Funktionen vorhandener kommerzieller Software wird
repliziert
 Architektur ging durch viele Entwicklungs-Zyklen, bevor sie
einsatzfähig wurde
 Unausgereifte und instabile Architekturen
 Hoher Aufwand
 Gewünschte Funktionalität kann u.U. an den Kunden nicht
geliefert werden (oder nicht rechzeitig)
Ursachen und Ausnahmen
Ursachen:
 Top-Down Analyse und Design führen zu neuen
Architekturen und Individual-Software
 Annahme eines „Greenfields“:
 Keine „legacy systems“
 Software von Grund auf entwickeln
 Isoliertes Einzel-System



Keine Kommunikation und Technologie-Transfer zwischen
einzelnen Entwicklungs-Teams bzw. Abteilungen
Fehlen eines expliziten Architektur Prozesses
Schlechte Risiko- und Kosten-Analyse
Ursachen und Ausnahmen
Ausnahmen:
 In einer Forschungs-Umgebung
 In der allgemeinen Software-Entwicklung, um die
Koordinations-Kosten zu minimieren, wenn Entwickler mit
unterschiedlichen Fähigkeiten an unterschiedlichen Orten
arbeiten
Lösungen
Architecture Mining:
 Extrahieren von Design Informationen vorhandener Designs
und Verwendung dieser Informationen in der eigenen OOArchitektur
 Bottom-Up Design Prozess
 OO Architekturen werden robust, Hersteller-Unabhängig,
Wiederverwendbar und Erweiterbar
Architecture Farming:
 Erstellen eines Design aus den Anforderungen, im
Entwicklungsprozesse Design spiralförmig erweitern und
verändern
 Top-Down Design Prozess
  „Reinvent“ der Design Informationen
Fazit
Das Reinvent the Wheel für zu erhöhten
Kosten und schlechteren Designs
 Vermeiden!
The Blob
Übersicht
Name

The Blop
Auch bekannt als:

Winnebago, Klasse des Gottes
Auftreten

Softwarepattern
Anekdote
“Das ist die Klasse, die
das Herz unserer
Architektur ist.”
Allgemeine Form
Beschreibung
Charakteristik



Einzelne Klasse mit einer großen Zahl von
Attributen, Operationen, oder beiden
Eine ungleiche Sammlung von Attributen ohne
Beziehung und in einer einzelnen Klasse kurz
zusammengefassten Operationen
A single controller class with associated simple,
data−object classes.
Beschreibung
Konsequenzen






unvereinbare Fachsprache, Annäherungen, und
Technologien zwischen Unternehmenssystemen
Spröde, monolithische System-Architekturen und
undokumentierte Architekturen
Unfähigkeit, Systeme zu erweitern, um
Geschäftsbedürfnisse zu unterstützen
Falscher Gebrauch eines Technologiestandards.
Unfähigkeit von Systemen sich sogar bei der Verwendung
der gleichen Standards zu verstehen
Übermäßige Wartungskosten wegen sich ändernden
Geschäftsvoraussetzungen
Email is Dangerous
Übersicht
Name:
Email is Dangerous
Auch bekannt als:
Blame-Storming
Auftreten
In allen Bereichen
Beschreibung
Charakteristik
E-Mail hat eine außerordentlich starke Bedeutung in der
betrieblichen Kommunikation
In E-Mails steht alles von Scherzen über allgemeine
Information und normaler betrieblicher Kommunikation bis
hin geheimen Daten.
E-Mail hat keinerlei Sicherungsfunktion. Durch das Store and
Foreward Prinzip erhält jeder Mailserver eine unverschlüsselte
Kopie zum weiterleiten.
Beschreibung
Konsequenzen
Eine vertrauliche Nachricht endet oft bei dem Empfänger, den man am
wenigsten wünscht (Boss, Konkurrenz)
Eine E-Mail kann permanent gespeichert werden. Jemand kann einen
leicht darauf festnageln.
Eine E-Mail kann komplett falsch interpretiert werden, viel stärker als
bei persönlichem oder telefonischem Kontakt
Eine E-Mail kann an sehr viele Leute gleichzeitig weitergeleitet werden.
Email eignet sich nicht um komplizierte Sachverhalte zu erörtern. Da oft
Fehlinterpretationen auftreten
Beispiel
Beschwerde über Chef landet bei ihm selber
Kontoaufstellung von Kunden per Email kann potentiell von
jedem Mail Server gelesen und weiterverbreitet werden.
Ironie in Mail wird ernst genommen.
Lösung
Generell sollte E-Mail im betrieblichen Umfeld mit Vorsicht
behandelt
werden.
Emails sollten nicht für folgende Themen verwendet werden:
Kritik
Vertrauliche Daten
Politisch Inkorrekte Themen
Strafbare Äußerungen
Ausnahmen können gemacht werden, wenn die E-Mails
verschlüsselt und signiert werden.
Spaghetti Code
Spaghetti Code
Name
Spaghetti Code
Auftreten
Application
Zitat
„Oh je! Was für ein Durcheinander!“
„Da schreib ich den Code lieber noch mal neu bevor ich den
abändere“
Spaghetti Code
Charakteristik
Lange Methoden Rümpfe
Eigentlichem Entwickler fällt es schwer den Überblick zu bewahren
Was passiert wenn der Entwickler das Projekt verlässt?
Wenig Objekte mit lang implementierten Methoden
Konsequenzen
Schwer zu warten
Objekte eigenen sich nicht zur Wiederverwertung
Vorteile der OO Sprachen gehen verloren
Kosten für die Wartung des Codes sind größer als die Kosten die
Software neu zu entwickeln
Spaghetti Code
Ursachen
Keine Erfahrung in OO Entwicklung
Kein Design vor der Implementierung
Resultat von Isolation des Entwicklers
Ausnahmen
Schlüssige Interfaces, nur die Implementierung ist Spaghetti
Lebenszeit ist kurz und die Komponente ist klar vom Rest des Systems
getrennt
Spaghetti Code
Lösung
Umstrukturieren
Neu entwickeln
Am besten nicht aufkommen lassen
Mitwirkende
Marianna Tatova
Helga Debora Messmer
Mirko Bleyh
Daniel Haag
Fabian Mielke

AntiPatterns Einleitung