Design by Demut

ix.0909.092-095

10.08.2009

9:53 Uhr

Seite 92

REPORT

Softwarearchitekturen

Die Auswirkungen von Entwurfsentscheidungen

Design by Demut Daniel Mölle Gutes Design ist etwas Grundsätzliches, unabhängig von konkreten Lösungswerkzeugen und Technologien.

Jede Modellierung, jede Software sollte genau das leisten, was ihre Bestimmung ist, und der Komplexität einer Aufgabe angepasst sein. Die Realität sieht aber meist anders aus.

I

n einem modellverliebten Betätigungsfeld wie der Informatik spielen Designentscheidungen eine zentrale Rolle. Ob es um die formale Repräsentation eines Problems, die Abbildung von Informationen in Datenstrukturen, den Entwurf einer Architektur oder gar die Formalisierung ganzer Entwicklungsprozesse geht – stets gilt es, ein Design zu finden, das dem Wesen der zu lösenden Aufgabe möglichst nahe kommt. Ergebnisse, die der Natur des Sachverhalts zuwiderlaufen, werden üblicherweise bestraft – im schlimmsten Fall spät.

Die Grundregeln guten Designs sind, wie alle anderen Mengen von Prinzipien, zunächst Gegenstand einer subjektiven Wertung. Als solcher unterliegen sie einem Zeitgeist, sind regio-

92

nalen Moden ausgesetzt und erfahren individuelle Neubewertungen aufgrund konkreter Erfahrungen Einzelner. Trotzdem lässt sich erfreulicherweise feststellen, dass die Softwaretechnik seit Jahrzehnten von einer fruchtbaren Diskussion über nützliche Designprinzipien und Entwurfsregeln begleitet wird. Ungeachtet aller Differenzen kristallisieren sich dabei Konzepte heraus, die es ermöglichen, Softwaresysteme steigender Komplexität elegant zu realisieren.

In Anbetracht des Aufwandes und der Leidenschaft, mit denen die diversen Grundregeln guten Designs erörtert und unterrichtet wurden, könnte man leicht zu der Erwartung gelangen, die in der Realität eingesetzte Software müsse heute besonders klug strukturiert

sein. Eine genauere Betrachtung des IT-gestützten Alltags zeigt jedoch, dass es gerade die grundsätzlichen und am weitesten akzeptierten Designprinzipien sind, die fortwährend verletzt werden. Betrachtet man etwa das Konzept der „Separation of Concerns“, stellt man mit Verwunderung fest, dass es ausgerechnet von den der Verbreitung nach erfolgreichsten Programmen mit Füßen getreten wird – und dies auf allen erdenklichen Ebenen.

Bei den populären grafischen E-MailClients etwa lassen sich gleich mehrere Fälle unglücklicher Vermengungen und Verwechslungen beobachten. Da werden die lokalen Daten von E-Mails nicht etwa in einem zentralen Verzeichnis des Benutzers gespeichert, der dann jederzeit mit einem E-Mail-Client seiner Wahl darauf zugreifen könnte, sondern in einer für den eingesetzten Client spezifischen Weise. Die E-Mails gehören in diesem Modell nicht dem Empfänger, sondern vielmehr dem Programm, über das der Anwender sie erhalten oder verschickt hat. Ebenso wenig gibt es eine Entkopplung der verschiedenen Aufgaben wie Empfang, Filterung, Darstellung, Verwaltung, Nachbereitung oder Versand. Wer auf einen neuen E-Mail-Client umsteigen und seine bewährten Filterdefinitionen nicht verlieren will, hat Pech gehabt.

Ein noch gravierenderes Beispiel für eklatante Designfehler stellt die aus dem Büroalltag nicht mehr wegzudenkende WYSIWYG-Textverarbeitung dar. Sie beruht auf der vollständigen Aushebelung einer Rollenteilung, die sich in der Erstellung von Schriftstücken seit Jahrhunderten bewährt hat: Der Autor als Inhaltsexperte, der Textsetzer als Formexperte, der Leser als Konsument. Bei WYSIWYG befinden sich Dokumente in einem permanenten Mischzustand zwischen Erstellung, Drucklegung und Lektüre.

Die hiermit einhergehende Verwischung der Verantwortlichkeiten wird naturgemäß direkt bestraft: Der Autor – stellenweise sogar der Leser – muss auch über das Layout entscheiden, obwohl er nie gelernt hat, was etwa Punzen, Ligaturen und Durchschüsse sind. Das Ergebnis ist ein laienhaft gesetztes Dokument. Weil Form und Inhalt nicht getrennt sind, bereiten die Versionierung und die parallele Bearbeitung von Dokumenten große Schwierigkeiten. Da es außerdem keinen klar definierten Zeitpunkt der Drucklegung gibt, kämpft der Leser permanent mit veralteten Metadaten, inkonsistenten iX 9/2009

©

Copyright by Heise Zeitschriften Verlag GmbH & Co. KG. Veröffentlichung und Vervielfältigung nur mit Genehmigung des Heise Zeitschriften Verlags.

ix.0909.092-095

10.08.2009

9:53 Uhr

Seite 93

Inhaltsverzeichnissen und bedeutungsfreien Indices.

Der IT-gestützte Alltag steckt voller derartiger Beispiele für ungünstiges Design, das den natürlichen Arbeitsabläufen, Zuständigkeiten und Intentionen widerspricht. Unter den zum Teil verheerenden Fehlentscheidungen, die sich in diesem Zusammenhang beobachten lassen, haben nicht selten Millionen von Anwendern zu leiden. So werden allen Ernstes Versionierungswerkzeuge verkauft und eingesetzt, die den Zustand von Dateien nicht an den Dateien selbst, sondern an Metadaten festmachen, die sich beliebig weit von der Realität entfernen können. Andere betreiben ganze Serverfarmen mit Desktop-Betriebssystemen. Nicht weniger häufig trifft man auf behördenartige Informationssysteme, die ursprünglich zur Unterstützung von Business-Prozessen gedacht waren, in Wirklichkeit jedoch bewirken, dass die Geschäftsvorgänge in einer der Software gefälligen Weise abzuwickeln sind.

Höher, schneller, weiter und komplexer Eine gängige ideelle Vorstellung von Anforderungen ist die, dass sie vorgeben, was eine Software leisten soll, aber keine Aussage darüber treffen, wie das zu geschehen hat. Angesichts dieser Trennung könnte man sogar zu der Annahme verleitet sein, Requirements wohnten noch keine Designentscheidungen inne. Dies ist jedoch aus mehreren Gründen falsch: Erstens können insbesondere nichtfunktionale Anforderungen bereits sehr enge Rahmenbedingungen für das Wie setzen, und zweitens kann schon das Was beliebig gravierende Verstöße gegen die Natur der jeweiligen Domäne enthalten.

Der Umstand, dass im Lauf der Zeit immer komplexere Softwaresysteme realisierbar werden, führt naturgemäß

zu neuen Wünschen: Hochintegrierte Systeme sollen immer umfassendere Vorgänge abbilden, begleiten und steuern. Die Verlockung ist leicht nachvollziehbar. Um ein Beispiel aus der Geschäftswelt zu bemühen: Es nimmt wenig Wunder, dass die tiefgreifende Erfassung sämtlicher Business-Prozesse der Traum manchen Controllers ist.

Allerdings gilt im Arbeitsalltag dasselbe wie in der Physik: Wenn man noch die kleinsten Details erfassen will, gerät man in eine Situation, in der schon die Messung selbst das Messobjekt massiv beeinflusst. Der anforderungsinhärente Designfehler – die Etablierung schwerfälliger Erfassungsprozesse bis hinunter auf die Ebene der leichtfüßigsten Geschäftsvorgänge – verhindert von Anfang an den Erfolg des Systems.

Mit der wachsenden Komplexität von Software-Systemen nimmt die Bedeutung von Software-Architektur rapide zu

Beispiele für derartigen Übereifer finden sich in beinahe allen Bereichen. So gibt es heute Automobilhersteller, in deren Werkstätten ein Mechaniker ein gutes Drittel seiner Arbeitszeit darauf verwendet, Auftragsdetails und interne Lagerbewegungen zu verbuchen – wobei seine Performance minutiös dokumentiert wird. Bei Trivialreparaturen liegt der Overhead für die detaillierte Verbuchung besonders hoch. Erfasst wird somit aber offenkundig nicht mehr die Dauer der eigentlichen Leistung, sondern vielmehr die des Erfassungsvorgangs. Der Erkenntnisgewinn für den Controller ist dementsprechend gering, um – anlässlich der durch die persönliche Distanz provozierten Fehlinterpretationen – nicht von einem Erkenntnisverlust zu sprechen.

x-TRACT ●

In der IT gibt es unzählige Beispiele für Software mit ungünstigem Design, das den gewünschten Arbeitsabläufen eher entgegenwirkt.

●

Der Versuch, alle denkbaren Fälle abzudecken, kann zu unangemessener Komplexität führen, die die Ausführung der eigentlichen Aufgaben behindert.

●

Elegante Lösungen lassen sich nur dann finden, wenn ein Projektteam die Natur der gestellten Aufgabe verstanden hat und sich nicht von Modeerscheinungen beeinflussen lässt.

Ähnlich bezeichnend ist das folgende Zitat eines höheren Bankangestellten: „Mit unserer neuen Software kann man – da bin ich absolut sicher – eine Mondlandung vollständig durchplanen; für die Eröffnung von Konten jedoch ist sie nicht geeignet.“ Es bezieht sich auf ein Softwaresystem, das nach seiner Einführung als Gesamtlösung die einzig verbleibende Möglichkeit darstellte, Geschäftsvorgänge abzuwickeln – insbesondere also die Eröffnung neuer Konten, die seitdem eben nicht mehr fünf, sondern tatsächlich dreißig Minuten dauert.

Rechtzeitig rettend eingreifen Die gute Nachricht lautet: Wer für derartige Auswüchse von Informationssystemen sensibilisiert ist, hat gute Chancen, bereits bei der Erfassung der Anforderungen für eine neue Software rettend einzugreifen. Fordert etwa ein Kunde eine Oberfläche, die die Abwicklung des darzustellenden Vorgangs falsch wiedergibt, muss man sich trauen, unbequem zu sein. Möchte jemand zwei grundsätzlich verschiedene Dinge auf gleiche Weise darstellen, sollte man über die Konsequenzen nachdenken und sie auf konstruktive Weise darlegen. Wer eine Überspreizung zwischen der tatsächlichen und der anforderungsinduzierten Komplexität eines Vorgangs spürt, sollte den Unterschied messen.

Nebenbei bemerkt können ausufernde Anforderungen auch ein ethisches Problem darstellen [1]. Computer wecken allein durch ihre Verfügbarkeit Begehrlichkeiten, weil sie die systematische Erfassung und die zügige Verarbeitung immenser Datenmengen gestatten. Diese Verarbeitung wiederum erfolgt anhand eines in Software gegossenen Modells; über die Sinnhaftigkeit oder gar die Vertretbarkeit dieses Modells ist damit allerdings nichts gesagt.

In vielen Fällen lässt sich die Frage, aus welchem Grund eine bestimmte Software gewünscht wird, erstaunlich einfach beantworten: weil man sie schreiben kann.

So lassen sich auch die hartnäckigen politischen Bestrebungen der letzten Jahre, die eine zunehmende Überwachung privater Kommunikation zum Ziel haben, mühelos erklären. Tatsache ist: Die hierfür benötigten Informationen sind verfügbar, und Massenspeicher ist heute so billig und schnell, dass es mittlerweile schlichtweg plausibel 93

iX 9/2009

©

Copyright by Heise Zeitschriften Verlag GmbH & Co. KG. Veröffentlichung und Vervielfältigung nur mit Genehmigung des Heise Zeitschriften Verlags.

ix.0909.092-095

10.08.2009

9:53 Uhr

Seite 94

REPORT

ist, Verbindungsdaten aus der Festnetzund Mobiltelefonie sowie von InternetProvidern systematisch und langfristig zu archivieren. Die nächsten denkbaren Schritte, etwa die GSM-Ortung oder die Kennzeichenerfassung, sind technisch ebenfalls bewältigt. Zweitrangig ist dabei die konkrete Begründung für ihren Einsatz, und sie lässt sich leicht den aktuellen Trendthemen anpassen; psychologisch entscheidend ist wie so oft die Emotion, hier also der Reiz hinter der Idee, eine akribische Erfassung dieser Daten durchzuführen.

Spannend allein bleibt die Frage, wie das Datengebirge tatsächlich genutzt werden wird, wenn es erst mal da ist – und die nächsten Begehrlichkeiten nach sich gezogen hat. Unter anderem könnte man sich mit der Frage beschäftigen, ob nicht gerade die Nation, deren erste Anwendung maschineller Informationssysteme unter anderem der Judenverfolgung diente, heute bei der systematischen Erfassung und Verwahrung persönlicher Daten durch außergewöhnliche Zurückhaltung und Besonnenheit glänzen sollte.

Vorsicht mit dem Coolness-Faktor Bereits 1972 hat Edsger Dijkstra in aller Deutlichkeit festgestellt, dass Bescheidenheit und Demut in der Welt der Softwareentwicklung ausgesprochen wünschenswerte Eigenschaften sind [2]. Gemeint hat er damit vor allem den Verzicht auf den kryptischen Einsatz verfügbarer Sprachmittel. Es mag möglich und reizvoll sein, ein gewünschtes Verhalten unter Ausnutzung erstaunlich komprimierter Anweisungen oder gar undokumentierter Seiteneffekte zu realisieren, aber in fast allen Fällen ist es in erster Linie eins: bei der Fehlersuche und Wartung so hinderlich, dass einigen gesparten Codezeilen und Taktzyklen unverhältnismäßige Folgekosten gegenüberstehen.

Selbstverständlich gibt es Ausnahmen vom Coolness-Verbot – beispielsweise extrem effiziente Verfahren aus der Welt des „bit fiddling“, die zum Teil ansprechend dokumentiert sind [3], deren Einsatz aber nur an wirklich performancekritischen Stellen zu empfehlen ist. Man bedenke in diesem Zusammenhang immer, was die Vordenker der Zunft über „premature optimization“ gesagt haben. Genauso klar ist aber auch, dass eine übertriebene Ausformulierung trivialer Programmstücke unbe94

Softwarearchitekturen holfen wirkt und irgendwann wieder Fehler provoziert, weil einfache Sachverhalte ins Unübersichtliche ausgedehnt werden. Das Gebot der Bescheidenheit impliziert keinen Verzicht auf Sachverstand oder Intuition. Kurzum, die eleganteste Lösung ist einmal mehr diejenige, die der Natur des Problems am nächsten kommt.

Die Grundregeln guten Designs sind, wie alle anderen Mengen von Prinzipien, zunächst Gegenstand einer subjektiven Wertung

Heute, mehr als dreieinhalb Jahrzehnte nach Dijkstras wohlbekanntem Vortrag, zeigt sich bezüglich der von ihm angeführten Tugenden ein geteiltes Bild – wenn auch in einem etwas anderen Zusammenhang, der durch die technologische Entwicklung und den Zuwachs an Komplexität in Softwaresystemen bedingt ist.

Einerseits lässt sich in puncto CodeQualität viel Gutes berichten. Mit Standards wie MISRA-C existieren wohldurchdachte und breit akzeptierte Vereinbarungen darüber, welche berüchtigten Fälle von fehleranfälliger und wartungsfeindlicher Programmformulierung zu unterlassen sind. Statische Analysewerkzeuge wie PC-Lint unterstützen das disziplinierte Coding.

Neuere Programmiersprachen werden bewusst darauf ausgerichtet, möglichst frei von Einladungen zu Zeigerakrobatik oder zu Zugriffen auf interne Repräsentationen zu sein. Überhaupt herrscht unter vielen Entwicklern ein ausgeprägtes Bewusstsein für den hohen Wert lesbarer Quelltexte.

Sich nicht der Mode unterwerfen Andererseits lässt sich häufig beobachten, dass es mit der demütigen Zurücknahme des Egos schnell vorbei ist, wenn es um übergeordnete Designentscheidungen geht. Während früher zum Beispiel die Ausnutzung spezieller technischer Eigenheiten eines Prozessors als schick galt, trifft dies heute nicht selten auf den Einsatz mächtiger Frameworks und betonierter Abstraktionsmechanismen zu. Allzu häufig werden mit einer umwerfenden Leichtfertigkeit Entscheidungen für schwergewichtige Techniken

getroffen, weil man diese gerade als modern einstuft. Dabei gilt heute wie damals: Die Unterwerfung unter eine Mode ist nur dann nützlich, wenn sie dem eigentlichen Zweck dient. Der Zweck jedoch ist schlichtweg die Lösung eines Problems, nicht das Abhaken von Buzzwords.

Je mehr Aufgaben eine Technik dem Entwickler abnimmt, desto stärker muss er sich ihrer Art unterwerfen, Aufgaben darzustellen und zu bearbeiten. In diesem Zusammenhang lohnt es sich, die folgende Frage zu stellen: Bis wohin dient die Infrastruktur dem Entwickler, ab wann dient er ihr? Wer sich für eine schwergewichtige Technik entscheidet, gibt Kontrolle und somit Macht an sie ab. Eine solche Entscheidung ist um so kritischer, wenn die zu lösende Aufgabe ihrer Natur nach eher einfach ist. (In diesem Kontext sind beispielsweise die leidenschaftlich geführten Debatten zwischen den Verfechtern von WS-* und REST interessant.)

Ein typisches Beispiel für eine problematische Technik, die viele verfrüht einsetzen, ist das Multi-Threading. Die parallelisierte Ausführung von Programmen führt extrem schnell an die Grenzen dessen, was der menschliche Verstand intuitiv zu begreifen in der Lage ist, wie aufschlussreiche Anekdoten über fehlerbehaftete Semaphoren in aller Deutlichkeit zeigen [4]. Die Folge sind Race Conditions, die ihrerseits Schutzmechanismen provozieren, deren unbedachter Einsatz wiederum leicht zu Deadlocks führt.

Nicht minder fragwürdig sind übereilte Entscheidungen für komplexe Protokolle und die dafür entworfenen Frameworks. Bei der Abwägung verschiedener Kandidaten werden die jeweiligen Features allzu oft mit Anerkennung überhäuft, während der anfallende Mehraufwand und Risiken kaum Erwähnung finden (wie im „Design by Buzzword“ üblich) und kaum jemand auf die Verhältnismäßigkeit der einzusetzenden Mittel achtet. Der Preis für das Vertrauen in die Hochglanzlösung zeigt sich oft erst später, beispielsweise wenn das halbe Projektteam wochenlang damit beschäftigt ist, eine Infrastruktur zu bändigen, die mit der Lösung des eigentlichen Problems kaum etwas zu tun hat.

Mit der wachsenden Komplexität von Softwaresystemen nimmt die Bedeutung von Softwarearchitektur rapide zu. Das ist kein Wunder: Eine kleine 1000-Zeilen-Anwendung verträgt ein schlechtes Design wesentlich eher als iX 9/2009

©

Copyright by Heise Zeitschriften Verlag GmbH & Co. KG. Veröffentlichung und Vervielfältigung nur mit Genehmigung des Heise Zeitschriften Verlags.

ix.0909.092-095

10.08.2009

9:53 Uhr

Seite 95

ein 100ˇ000-Zeilen-Projekt. Aber auch in diesem Kernbereich der Softwaretechnik gilt, dass elegante Lösungen nur realisierbar sind, wenn das Team die Natur der Aufgabe verstanden hat.

Markante Fehleinschätzungen sind keine Seltenheit.

Nützlich, aber keine Sensation Ein besonders lehrreiches Beispiel sind der Aufstieg und der mittlerweile offen diskutierte Niedergang von SOA (Service-oriented Architecture). Der Gedanke, Modularisierung so weit zu treiben, dass Komponenten unabhängig voneinander installiert und erst zur Laufzeit miteinander verknüpft werden können, ist nützlich, aber keine die Weltordnung auf den Kopf stellende Sensation (zumal sie der seit Jahrzehnten von den UnixUtilities praktizierten Kultur nachkommt). Wartbarkeit oder Wiederverwendbarkeit von Modulen erhöhen sich nicht dadurch, dass man die Komponenten als Services bezeichnet. Schnittstellen bleiben Schnittstellen, und Änderungen an Schnittstellen bleiben unabhängig davon, wie oft man das Wort „interoperabel“ bemüht, schwierig.

Jeder nichttriviale Eingriff in die Außenwirkung eines Moduls bedingt die Anpassung seiner Nachbarn – wenn es keine Abhängigkeiten gäbe, existierte auch kein Zusammenhang. Das große Potenzial entkoppelter Anwendungen liegt eher in solchen Aspekten wie der Testbarkeit, etwa durch den Austausch von Modulen durch Mocks, die Injektion von Ereignissen oder die Beobachtung dadurch ausgelöster Reaktionen.

Diese Stärken lassen sich bei gutem Design allerdings auch in eine zur Laufzeit monolithische Applikation einbringen. Insofern ist SOA im Wesentlichen nichts anderes als eine hilfreiche Metapher, und es wäre mehr als verwunderlich, wenn eine einzige Metapher den steinigen Weg zur nächsten Größenordnung von Systemkomplexität in eine gummierte Rolltreppe verwandeln könnte.

Auf ähnliche Weise wird gerne das Missverständnis bedient, Tugenden wie Modularität, Separation of Concerns, Information Hiding und so weiter seien der Welt der objektorientierten Sprachen vorbehalten. Wer einmal eine in rohem C verfasste Firmware für ein eingebettetes System im Handumdrehen auf einen nagelneuen Mikrocontroller portieren konnte, weil die Firm-

ware so elegant geschnitten war, dass sie neben einer sauberen Kapselung aller Hardwarespezifika die Testbarkeit beliebiger Modulteilmengen garantierte, der begreift, dass gutes Design etwas Grundsätzlicheres ist. Objektorientierung ist (in viel größerem Umfang als die oben erwähnte SOA-Metapher) eine nützliche Art, über Strukturen nachzudenken und passende Modelle in Software abzubilden – aber eben auch nur das.

Eine wesentliche Voraussetzung für gute Architekturen ist und bleibt jenseits aller Strömungen das korrekte Verständnis der Domäne

Eine wesentliche Voraussetzung für gute Architekturen ist und bleibt jenseits aller Strömungen das korrekte Verständnis der Domäne, also einmal mehr das Erkennen der Natur der zu lösenden Aufgabe. So gilt in der Softwarearchitektur genau wie in der Algorithmik, dass die elegantesten Lösungen genau dann entstehen, wenn sie die dem untersuchten Problem zugrunde liegende Struktur präzise erfassen und in der Software ohne künstlichen Ballast wiedergeben. Deshalb kann es jenseits wiederverwendbarer Entwurfsmuster, die sich auf spezielle Teilprobleme beziehen, kein Allheilmittel und keine Einheitslösung für Architekturfragen geben.

Saisonale Modethemen und HypeParadigmen wie SOA, AOP (Aspectoriented Programming), Softwareproduktlinien und so weiter hinken der versprochenen Erlösungswirkung stets hinterher, weil man die entscheidenden Erfolgskriterien des Architekturentwurfs – Intuition, Erfahrung, Domänenverständnis, Vorausahnung kommender Anforderungsänderungen – einfach nicht formalisieren kann.

Ein Schlusswort über Prozesse Die spannende Welt der Entwicklungsprozesse enthält mit dem bekannten Wasserfallmodell eines der skurrilsten Missverständnisse der Softwaretechnik überhaupt: Obwohl es in der Literatur ursprünglich als Negativ-Beispiel aufgeführt und schon bei seiner ersten formalisierten Beschreibung als unbrauchbar herausgestellt wurde [5], ist es in

Tausenden von Projekten zum Einsatz gekommen und selbst Jahrzehnte später noch unterrichtet worden. Der Kern des Problems: Das Wasserfallmodell widerspricht in vielerlei Hinsicht dem Wesen von Softwareprojekten; insbesondere die strenge Sequenzialität der verschiedenen Aufgaben wie Anforderungserfassung, Implementierung oder Test ist nicht zu halten.

Von dem entgegengesetzten Extrem – der Anwendung hochgradig komplexer Prozesse für einfache Projekte – ist selbstverständlich in ähnlicher Vehemenz abzuraten. Wer sein Projektteam zu einer Behörde macht, muss mit behördenartiger Effizienz rechnen.

Als einzig vielversprechender Weg bleibt die Verwendung solcher Prozessmodelle, die sich hinsichtlich ihrer Komplexität auf das jeweilige Projekt zuschneiden lassen, wie es etwa beim RUP-Tailoring (Rational Unified Process) geschieht. Die Kombination aus einem angemessenen Entwicklungsprozess und agilen Methoden ermöglicht eine Balance zwischen strukturierender Systematik und produktiver Dynamik; sie ist wohl die beste derzeit bekannte Art, mit nichttrivialen Aufgaben umzugehen, und wird vermutlich noch Aufstieg und Fall so mancher Modeerscheinung überdauern. (ka)

DR. DANIEL MÖLLE ist bei der Zühlke Engineering GmbH als Software-Ingenieur mit den Schwerpunkten Eingebettete Systeme und .Net tätig.

Literatur [1]ˇJoseph Weizenbaum; Computer Power and Human Reason; From Judgement to Calculation; W. H. Freeman, 1976 [2]ˇEdsger W. Dijkstra; The Humble Programmer; ACM Turing Lecture 1972: www.cs.utexas.edu/~EWD/transcrip tions/EWD03xx/EWD340.html [3]ˇHenry S. Warren; Hacker’s Delight; Addison-Wesley, 2002 [4]ˇGerard J. Holzmann; The SPIN Model Checker; Primer and Reference Manual; Addison-Wesley, 2003 [5]ˇWinston Royce; Managing the Development of Large Software Systems; Proceedings of IEEE WESCON 26, 1970

www.ix.de/ix0909092

95

iX 9/2009

©

x

Copyright by Heise Zeitschriften Verlag GmbH & Co. KG. Veröffentlichung und Vervielfältigung nur mit Genehmigung des Heise Zeitschriften Verlags.