Design Problem Chart

Das Design Problem Chart stellt als leichtgewichtiges und simples Werkzeug eine ideale Ergänzung zur klassischen Top-Down-Analyse dar.

Die Top-Down-Analyse ist eine bewährte und zuverlässig eingesetzte Methode, in der Modelle in Untermodelle (und Untermodelle in weitere Untermodelle) zerteilt werden. Jede Ebene kann dabei unterschiedliche und jeweils passende Formalisierungsgrade besitzen und somit zur Verständlichkeit und Wartbarkeit beitragen.

Jedes Design, selbst das Beste, wirft jedoch Probleme auf, zumindest nicht bedachte Details. Manche sind evtl. so groß, dass diese ein geändertes Top-Down-Modell zur Folge haben. Viele Probleme sind jedoch winzig klein, operative Codings und existieren zusätzlich zur Spezifikation. Ihr Warum ist meist nicht ausreichend dokumentiert, was jedoch auch daran liegt, da dies in textuellen Kommentaren äußerst umständlich und nur bedingt aussagekräftig ist.

Probleme und Abhängigkeiten, die auf diesem Level entstehen, können meist nur durch intensive Selbst-Reflektion des eigenen Designs mit Code-Reviews erkannt werden.

Design-Problem-Charts sind eine strukturierte Darstellung, in welcher die operativen Probleme vermerkt werden. Die Selbstreflektion bzw. Team-Selbstreflektion wird dadurch deutlich vereinfacht (Einstiegshürden) und gleichzeitig qualitativ verbessert (Perzeption).

Das DPC besteht aus Knoten und Kanten. Knoten sind Design-Elemente, also Design Entscheidungen. Diese sind äußerst frei, d.h. Sie kann z.B. eine Nutzeranforderung bzw. ein grobes Feature sein, sie kann eine Klasse, ein Interface, eine Technologie-Auswahl, ein Deployment sein oder einfach nur ein Verhalten dass sich einstellt.

Diese Design-Elemente haben jeweils eingehende Gründe, d.h. Warum wurden diese erstellt und ausgehende Knoten. Hier wird unterschieden zwischen Verfeinerungen und Problemen. Probleme sind ein Nachteil des Designs, der zumeist erst operativ aufgetreten ist und Folge-Designs auslöst. Verfeinerungen sind Details im „Geiste“ des übergeordneten Problems. Die Perzeption von eigentlich ungewollten-Design-Abhängigkeiten ist so äußerst einfach.

DPC sind ein leichtgewichtiges Tool was zunächst mit Stift und Papier erstellt werden sollte. Es ist ein absolutes-Basistool, genauso wie ERDs oder Flow-Charts und kann auf allen Abstraktionsebenen von Requirements bis Entwicklung eingesetzt werden.

A Quick Dive

Starten wir mit einem kleinen Beispiel: In einer Business Applikation benutzen wir sehr häufig TreeViews. Da immer sehr viel trivialer Code zum Rendering und Laden nötig ist, haben wir dies in einer Komponente gekapselt, die die Objektbeziehungen deklarativ und sehr gut wartbar in einer XML Syntax beschreibt. Heute macht das WPF von selbst, aber zu Zeiten von Windows Forms war das noch anders! Die Komponente funktioniert erst einmal gut, doch über die Zeit stellen sich Probleme ein. Diese versuchen wir in einem Design Problem Chart darzustellen:

 

Auf Anhieb sieht man, dass hier keine schönen Grafiken entstehen müssen. Vielmehr ist Gekritzel erwünscht um die Denkbahnen mobil zu halten. Des Weiteren empfehle ich Filzstifte anstatt von Kugelschreibern, besonders für die Kanten.

In diesem Beispiel stellen wir fest, dass der benötige Hauptspeicher für die Observer (es wird für jede Collection des Objektes ein Callback registriert), deutlich größer ist, als die Nutzdaten als solches. Der RAM-Verbrauch ist dadurch enorm hoch. Die direkte Ursache ist das Observer-Model. Man müsste die Anforderung „Self-Refreshing“ anders umsetzen, was jedoch einen enormen Aufwand verursachen könnte (das wäre dann ein weiteres DPC).

Dann stellen wir fest, dass nur Objektbäume anzeigen nicht so sinnvoll ist und wir eine Suche / Filter benötigen. Konform mit der Datenbank-Unabhängigkeit wird dieser Filter Client-seitig implementiert. Das Resultat ist jedoch eine schlechte Performance, wenn die Objekte größer werden (entweder in der Masse oder in der Größe je einzelnes Objekt), da nicht benötigte Objekte trotzdem aus der Datenbank geladen werden:

 

Wenn man einmal angefangen hat, werden einem immer mehr „Rote Verbindungen“ einfallen, also Probleme, die aus bestimmten Designs oder Anforderungen entstanden sind. Für ein komplexes Design kann man schon mal eine A1-Seite benötigen.

Das Resultat ist eine realistische Einschätzung des vorhandenen Systems. Es ist nicht immer möglich, dieses dann sofort zu ändern; die Analyse der Ursachen ist jedoch der 1. Schritt zur zukünftigen Besserung.

Wann sollte es eingesetzt werden?

DPCs sind ein reflektives Mittel. D.h. es dient der Analyse von Design, welches bereits existiert. Wenn Sie neues Design schaffen, werden Sie ja nicht absichtlich negative Seiteneffekte einbauen.

Fangen Sie an es zu nutzen, wenn Sie einen „Code Smell“ in der Nase haben, also das Gefühl, dass hier was in der Software falsch läuft. Gehen Sie den Ursachen mit grünen und roten Stiften auf den Grund.

Wenn Sie das Design nicht selbst verbrochen haben, sticheln Sie den Designer mit den roten Kanten. Geben Sie Feedback, dass die schönen abstrakten Konzepte im Detail riesige Probleme verursachen.

Und los

 Probieren Sie es aus. Nehmen Sie sich ein Blatt Papier, einen schwarzen Stift, einen grünen Filzstift und einen roten Filzstift und 30 Minuten Zeit.

Wenn Ihnen vor Schreck kein Problem einfällt, stöbern Sie mal in Ihrem Bugtracker in der Rubrik „nicht reproduzierbar“.