The Blog

Antwort: „It is all design – really?“

In seinem Blogpost „It is all design – really?“ argumentiert Ralf Westphal, dass Quellcode etwas Konkretes ist, aber der eigentliche Entwurf in einer höheren Abstraktionsebene geschehen soll. Als Lösung wird Flow-Based-Entwicklung dargestellt.

Ich stehe dem Post kritisch gegenüber:

1: Softwareentwürfe sind sehr unterschiedlich und auch wenn ich klare Präferenzen für Flow-Based habe, scheinen mir verschiedenste Entwurfstechniken und Vorgehensweisen nützlich zu sein. Die Bandbreite geht hier von Anforderungsbeschreibung in Word, mit wenigen Illustrationen, bis hin zum vollständigen Entwurf in UML.

Am häufigsten genutzt zu werden und am effektivsten scheint mir eine Mischform, die in verschiedenen Projektphasen für verschiedene Zielgruppen verschiedenste Artefakte erzeugt: Word-Dokumente, unterschiedliche Diagrammtypen, ausführbare Spezifikationen. Das Entwurfsvorgehen passt sich an die Projekteigenschaften an.

2: Entwurf kann sehr wohl im Quelltext geschehen. Hierum geht es ja gerade in TDD, das von Kent Beck als Entwurfstechnik beschrieben wird. Die TDD-Idee, in der Tests die Entwicklung tatsächlich treiben, muss man nicht mögen, aber sie sollte auch keine Zielscheibe sein. Es ist durchaus pragmatisch, innerhalb eines Arbeitstages ein Teilproblem vormittags Flow-Based zu modellieren und zu implementieren und nachmittags eine  API testgetrieben  zu modellieren und implementieren.

3: Interne DSL als Entwurfstechnik möchte ich nicht so schnell abtun. Auch Flow-Based hat das Potential, mit DSLs betrieben zu werden. Warum sollen (einfache) Prozesse nicht gleich in der IDE textuell beschrieben sein? Für einige Anwendungsfälle sehe ich hier großes Potential. Kommt die DSL als Bibliothek, stellt sich das auch nicht mehr als: Meta-DSL(DSL(C#(IL-Code(Maschinencode)))) dar, sondern als C# (Maschinencode).

Zusammenfassung:

Soll es über der Implementierung weitere Entwurfsabstraktionsebenen gebenl? Ohne Frage! (Auch Robert Martin sieht das vermutlich nicht anders.) Dass Denken, Entwerfen, Modellieren, Implementieren in Prozessen (Flow-Based, flußorientiert, etc.) ein natürlicher und einfacher Weg für die Herangehensweise an Softwareentwicklung ist, diese Ansicht Teile ich auch – aber warum kann Flow-Based sich nicht einfügen, mitmachen und Teil eines Ökosystems von Denkideen sein? Warum wird UML nicht also ein Werkzeug unter vielen akzeptiert? Warum muss man sich von der TDD-Perspektive, die Robert Martin vertritt, abgrenzen? Warum kann nicht das eine oder andere OOAD-Konzept Flow-Based ergänzen? Hier würde ich mir mehr Offenheit wünschen und auch eine Perspektive, die einer Koexistenz von eingeführten Ideen und Flow-Based wohlwollend und positiv gegenübersteht, sodass auch individuelle inkrementelle Veränderung unterstützt und begünstigt wird.


Kick It auf dotnet-kicks.de

2 Awesome Comments So Far

Don't be a stranger, join the discussion by leaving your own comment
  1. Ralf Westphal
    März 19, 2011 at 16:06 #

    „[…] aber warum kann Flow-Based sich nicht einfügen, mitmachen und Teil eines Ökosystems von Denkideen sein? Warum wird UML nicht also ein Werkzeug unter vielen akzeptiert? Warum muss man sich von der TDD-Perspektive, die Robert Martin vertritt, abgrenzen? Warum kann nicht das eine oder andere OOAD-Konzept Flow-Based ergänzen?“

    Aber Flow-Orientation fügt sich ein. Sie ersetzt nicht. Und das habe ich deutlich gemacht und sage es immer wieder.

    Wem UML nützt, der soll UML benutzen – ich kenne nur leider niemanden. Wer mit TDD Gutes bewirkt, der tue das – es fällt vielen nur leider schwer. Wer mit OOAD wartbare Softwaresysteme erschafft, der schaffe weiter – leider kenne ich kein solches System.

    UML, TDD, OOAD waren zu ihrer Zeit Silverbullets. „Mach endlich UML und deine Software entsteht leicht und ist wartbar!“ – das war ein Versprechen, das sich nie erfüllt hat. „Mache TDD und deine Software ist wunderbar designt!“ – das ist immer noch ein Versprechen, mit dem sich im Kleinen gute Erfolge erzielen lassen, wenn man sich doll konzentriert; nur leider skaliert TDD nicht. Wer als Aufgabe „Warenwirtschaft“ vorgesetzt bekommt, kann mit TDD allein wenig anfangen. Mit UML und OOAD übrigens auch, wie die real existierenden Systeme zeigen.

    Warum das nicht anders sein konnte, bin ich gern bereit zu erklären. Aber nicht in so einem Kommentar.

    Und nun Flow-Orientation? Auch eine Silverbullet? In gewisser Weise schon. Mit Flow-Orientation werden gezielt Lücken anderer Ansätze geschlossen.

    Aber Flow-Orientation ersetzt eben nicht per anderes. Deshalb keine Silverbullet per se. Bei der Übersetzung von Flow-Designs arbeite ich natürlich mit OO-Sprachen. Für Datenstrukturen in Flow-Designs benutze ich u.a. Klassendiagramme. Manche Bauteile in Flow-Designs modelliere ich näher mit Zustandsautomaten.

    Flow-Orientation spannt insofern einen Rahmen auf, in dem anderes einen Platz findet. Flow-Orientation fokussiert andere Ansätze. Das halte ich für einen Wert.

  2. Robert
    März 19, 2011 at 17:49 #

    @Ralf, vieles was Du schreibst klingt sehr gut. Sensibel bin ich bei Aussagen die beschreiben, dass UML, OOAD, TDD niemanden nützt oder genutzt hat. Ich war nie dogmatischer Verwender dieser Techniken, mit Ausnahme vielleicht von TDD, aber das ist schon lange her, jedoch haben all diese Techniken mir geholfen wartbare Softwaresysteme zu entwickeln. Da kann ich auch gerne was zeigen.

    Ich kann mir nicht vorstellen, dass Du keine Projekte kennst wo durch OOAD und UML Einflüsse Nutzen entstanden ist. Zumindest ist bei (mit Hinblick auf Qualität) erfolgreichen Projekten, schwer das Gegenteil zu belegen, denn mein Eindruck ist, dass eigentlich fast kein Projekt ohne OOAD Einflüsse entwickelt wird. Nur eine verschwindend geringe Menge von Projekten dürfte klassisch Prozedural sein.

    Ich glaube also, dass viele Projekte von OOAD(DDD), TDD und UML profitieren und profitiert haben. Die Welt besteht nicht nur aus schlechter Software! Nun wird die Qualität von Techniken und Vorgehensmodellen kontinuierlich und evolutionär besser. So ist das mit dem Fortschritt. Deswegen trifft Flussorientierung nicht ohne Grund bei mir einen Nerv und beeinflusst aktuelle Projekte sehr stark und wie ich finde sehr positiv. Das heißt aber nicht, dass TDD, OOAD(DDD), UML nun passé sind. Sie haben nur eine andere, weitaus geringere Bedeutung.

    Analog dazu sind vielleicht ausführbare Specs (Specification by Example/BDD): Ein evolutionärer Schritt, der meine Nutzung von TDD stark reduziert und eingegrenzt hat, der aber TDD nicht ersetzt oder hinfällig gemacht hat.