3.7.2009

Theorie und Abstraktion (9)

Themenanfang

For every problem, there is a solution that is simple, elegant, and wrong.

H.L. Mencken

Wenn jede Theorie darauf basiert, daß sie von Realität abstrahiert und diese somit vereinfacht, dann wird es letztlich immer darauf hinauslaufen, daß man nicht die komplette Realität erklären kann, sondern nur bestimmte Teilbereiche. Eine gute Theorie zeichnet sich dadurch aus, daß sie verhältnismäßig einfach ist, dennoch aber eine große Anzahl verschiedener Dinge erklären kann. Dabei widersprechen sich diese beiden Forderungen natürlich, und man muß aufpassen, nur die eine zu erfüllen, und die andere darüber zu vernachlässigen. Es gibt zahlreiche schlechte Theorien, die wortreich und komplex daherkommen, und letztlich bei der Erklärung simpelster Dinge scheitern. Es gibt aber auch Theorien, die verblüffend einfach und elegant gestrickt sind, die aber dennoch einen Fehler haben: sie sind falsch.

Im Softwaredesign gibt es ein Modell, in dem zunächst Use-Cases gesammelt werden, bevor das eigentliche Programm entworfen wird. Use-Cases sind jene Operationen, die zum Schluß der User des Programmes durchführen wird. Dabei geht man „von oben nach unten” vor - man startet bei den allgemeinen Zielen eines Programms, und geht immer weiter in die Details. Der User soll z.B. in der Lage sein, seine Stimme bei einer Online-Petition abzugeben. Dazu muß er sich registrieren. Dafür braucht es eine Feld, in den er seinen Namen eintragen kann. Es braucht einen Button, mit dem er die Registrierung verschickt. Er soll eine E-Mail bekommen, mit der er die Richtigkeit der Registrierung bestätigt. - Usf.

Erst nachdem man relativ detailliert den „Workflow” - also die Arbeitsabläufe des anvisierten Users - untersucht hat, beginnt man, Bereiche zu benennen, in denen am Code gearbeitet werden muß (z.B. das GUI für das Webinterface bei der Anmeldung), und entwirft dafür konkrete Designs (z.B. bestimmte Hierarchien von Classes, mit denen die GUI-Elemente konkret realisiert werden). In der Designphase dienen die Use-Cases als Rückbezug: man kann stets kontrollieren, ob man durch ein bestimmtes Design bestimmten Anforderungen an die einzelnen Use-Cases tatsächlich näher kommt, oder ob man sich in Abstraktionen verheddert, die überhaupt keinen Bezug mehr zum Ausgangsproblem haben (wenn man z.B. ein komplettes GUI inklusive Fenster- und Menuverwaltung entwirft, für das es konkret keine Verwendung gibt). Ebenso aber kann man sie immer wieder durchspielen mit Blick darauf, ob im Programmdesign gerade Weichen gestellt werden, die bestimmte Use-Cases unrealisierbar zu machen drohen (wenn man z.B. im Design von Widgets und Controls vergißt, daß die manchmal auch einen editierbaren Text haben müssen). In beiden Fällen muß man dann durch Redesign umsteuern.

Mir scheint das ein ganz brauchbares Modell zu sein, an dem man sich auch beim Theoriedesign orientieren könnte. Die Use-Cases sind hier die Fragen, auf die eine Theorie die Antworten geben soll. Während man ein theoretisches Modell entwickelt, kann man die Liste der Fragen immer wieder gegentesten, um sicherzustellen, daß man nicht dabei ist, in irgendwelche Metasphären abzudriften. Ebenso kann man so vermeiden, eine Theorie immer weiter einzudampfen und abstrakter zu machen, bis sie zwar noch elegant und stringent ist, aber nichts mehr erklärt.

(Kommentarfunktion z.Zt. deaktiviert.)