AntiPatterns

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 functionality Management of performance Management of change Management of IT resources Management of 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 IIDevelopment AntiPatterns

Architecture AntiPatterns

Project Management AntiPatterns

The BlobContinuous ObsolescenceLava FlowAmbiguous ViewpointFunctional DecompositionPoltergeistBoat AnchorGolden HammerDead EndSpaghetti CodeInput KludgeWalking through a

MinefieldCut-and-Paste

ProgrammingMushroom Managment

Autogenerated StovepipeStovepipe EnterpriseJumbleStovepipe SystemCover Your AssetsVendor Lock-InWolf TicketArchitecture By

ImplicationWarm BodiesDesign By CommitteeSwiss Army KnifeReinvent The WheelThe Grand Old Duke of

York

Blowhard JamboreeAnalysis ParalysisViewgraph EngineeringDeath By PlanningFear Of SuccessCorncobIntellectual ViolenceIrrational ManagementSmoke And MirrorsProject MismanagementThrow It Over The WallFire DrillThe FeudE-mail is Dangerous

TemplateÜbersicht

Name Auch bekannt als Auftreten Zitat/Anekdote

Beschreibung Charakteristik Konsequenzen

Ursachen und AusnahmenLösungBeispiel

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!“

Software Design Patterns: Anti-Pattern Helga Mesmer

„Gypsy Wagon“ that is there one day and gone the next.

Ein Poltergeist

PROCESS_TIMERPROCESS_TIMER

PEACHESPEACHES

CHOPPERCHOPPER

PEELERPEELER

WASHERWASHER

CANNERCANNER

PEACH_CANNER_CONTROLLER


CALENDARCALENDAR

Software Design Patterns: Anti-Pattern Helga MesmerSoftware Design Patterns: Anti-Pattern Helga Mesmer

Poltergeist: Symptome

Kein Status

Kurze Lebensdauer

Wenig Verantwortung

Single-operation classes: Aufruf von Methoden oder anderen Klassen

Controller-Klassen

Suffix: _manager, _controller


PEACHESPEACHES

CHOPPERCHOPPER

PEELERPEELER

WASHERWASHER

CANNERCANNER



CALENDARCALENDAR


Poltergeist: SymptomeRedundante Navigation zwischen den einzelnen KlassenTransiente AssoziationenUnnötige Abstraktion dadurch nur schwer verständlich

Problem: No Exceptions


PEACHESPEACHES

CHOPPERCHOPPER

PEELERPEELER

WASHERWASHER

CANNERCANNERPEACH_CANNER_

CONTROLLERPEACH_CANNER_

CONTROLLER

CALENDARCALENDAR


Poltergeist: Folgerung

UnnötigVerbraucht zusätzliche ResourcenIneffizient


Poltergeist: Ghostbusting

Poltergeist-Klassen aus der Hierarchie entfernenFehlende Funktionalität ersetzen indem man die Architektur korrigiert: die Kontrollfunktionen des Poltergeists den Klassen übertragen, die sie dann tatsächlich ausführen.


Poltergeist: Lösungs-Beispiel

RAW_PEACHES_BINRAW_PEACHES_BIN CALENDARCALENDAR CANNED_PEACHES_BINCANNED_PEACHES_BIN

PEACH_CANNER_SYSTEMPEACH_CANNER_SYSTEM

MACHINEMACHINE

PEELERPEELERWASHERWASHER CHOPPERCHOPPER CANNERCANNER

SortRawPeaches()ScheduleJob()AssignTasks()AlocateRessources()...

SortRawPeaches()ScheduleJob()AssignTasks()AlocateRessources()...


Poltergeist: Vorsicht!

Die 80%-Lösung des Blob ergibt oft einen Poltergeist: Coordinator-Class


Fragen?

Swiss Army Knife(Mini) Anti-Pattern

Übersicht

Software Architektur Mini Anti-Pattern

Auch bekannt als: Kitchen Sink

Häufigstes Auftreten: Objekt

+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

SwissArmyKnife

BeschreibungCharakteristiken 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

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

NameGolden Hammer

Auch bekannt alsOld 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

CharakteristikEin 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

KonsequenzenFür verschiedenste Konzepte wird immer das selbe Werkzeug verwendet.Produkte haben geringere Performance, und geringere Skalierbarkeit gegenüber vergleichbaren Produkten der KonkurrenzDie 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 WheelAnti-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: 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


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 OO-Architektur

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

CharakteristikE-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

KonsequenzenEine 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:KritikVertrauliche DatenPolitisch Inkorrekte ThemenStrafbare Äußerungen

Ausnahmen können gemacht werden, wenn die E-Mails verschlüsselt und signiert werden.

Spaghetti Code

Spaghetti Code

NameSpaghetti Code

AuftretenApplication

Zitat„Oh je! Was für ein Durcheinander!“„Da schreib ich den Code lieber noch mal neu bevor ich

den abändere“

Spaghetti Code

CharakteristikLange Methoden RümpfeEigentlichem Entwickler fällt es schwer den Überblick zu bewahrenWas passiert wenn der Entwickler das Projekt verlässt?Wenig Objekte mit lang implementierten Methoden

KonsequenzenSchwer zu wartenObjekte eigenen sich nicht zur WiederverwertungVorteile der OO Sprachen gehen verlorenKosten für die Wartung des Codes sind größer als die Kosten die Software neu zu entwickeln

Spaghetti Code

UrsachenKeine Erfahrung in OO EntwicklungKein Design vor der ImplementierungResultat von Isolation des Entwicklers

AusnahmenSchlüssige Interfaces, nur die Implementierung ist SpaghettiLebenszeit 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 TatovaHelga Debora MessmerMirko BleyhDaniel HaagFabian Mielke

Documents

AntiPatterns